Library breaks when added to a project

[dmaidman]

Hi,

I have developed a LabVIEW library that acts as a wrapper around a .NET library. The LabVIEW library has two classes and a dependant DLL, and was developed in a LabVIEW project. As part of the development I created a simple test application. In the test program the library works as expected and without error. 

I then added the library to another project (where it will finally be used) and for some reason the library breaks. The error list indicates that there are no valid methods for the .NET assembly. When I open the other project the code runs fine. The library is in the same physical location and there are no code changes. The only difference seams to be the project that the library is run from. There are no other dependencies that should have broken things. 

Any thoughts?

[paul_cardinale]

Perhaps the 2nd project is loading a conflicting DLL.

[JimB.]

---

@dmaidman wrote:

The library is in the same physical location and there are no code changes. The only difference seams to be the project that the library is run from. 

---

Where are the projects located?

Perhaps LabVIEW is having difficulty locating the assembly.

[Jjohnn]

Not really an answer, but I have also been fighting some .Net problems.

I wrapped some .Net calls in VIs and made them into an lvlib, and used a project to test the code.

I created another project and was able to use the .Net code written with the first project.

It is not clear to me how the VIs in the lvlib associate themselves with a particular .Net dll.  Is it only through the project?  If this is true then it makes reusing the VIs in other places a bit of a pain.

I opened one of the VIs without the project and LabVIEW searched for the dll.

I think when I started the second project I opened the first project and its VIs before starting the new project, with the notion that the VIs had already resolved the dll location and the new project would acquire the same associations (not sure it works this way).

I think if you change the project to file view it will show the dll locations (not sure this is true if it is the GAC).  I am not sure when LabVIEW uses absolute or relative paths for the dlls.

Loading the project file (XML) into notepad will show the expected path to the dll also.

[JÞB]

---

@dmaidman wrote:

Hi,

I have developed a LabVIEW library that acts as a wrapper around a .NET library. The LabVIEW library has two classes and a dependant DLL, and was developed in a LabVIEW project. As part of the development I created a simple test application. In the test program the library works as expected and without error. 

I then added the library to another project (where it will finally be used) and for some reason the library breaks. The error list indicates that there are no valid methods for the .NET assembly. When I open the other project the code runs fine. The library is in the same physical location and there are no code changes. The only difference seams to be the project that the library is run from. There are no other dependencies that should have broken things. 

Any thoughts?

---

Did you add the dll to the lvlib?  If so the dll is part of the lvlib and runs in the lvlib context.  If you left it in the dependencies if your lvlib dev project it runs under the context of that project and may not be able to run when loaded from another context if your lvlib members are scoped private ( private methods use private resources although that is an oversimplification) 

Since your error is a lack of public accessors ( no methods) I suspect moving your .NET Assebly into the lvlib will resolve the conflict when you use the lvlib in another context.

Another possible reason you might get to this is a path name or fully qualified name that just got too darn long. 

General answer: put library resources in the library.  Would you like to travel all over town after finding a book in your library just to find the Librarian that will check out your book?

[dmaidman]

thanks for the reply. I don't think that this is the case. I tried to add the library to an empty project and had the same issue. 

[dmaidman]

thanks for the reply JÞB. Just to confirm that the DLL was included in the library - this is why I was confused as to why it wasn't working. Code in same place, all paths store in the library - only difference was the project the library was added too.

[dmaidman · Accepted solution]

UPDATE: not a solution I like but I rewrote the library. I removed the DLL from the library and ensured that it was installed to Program Files rather than alongside the library. Seems to work now wherever I run the library. I have tested in an executable too.

[JÞB]

---

@dmaidman wrote:

UPDATE: not a solution I like but I rewrote the library. I removed the DLL from the library and ensured that it was installed to Program Files rather than alongside the library. Seems to work now wherever I run the library. I have tested in an executable too.

---

OK, so the Global Assembly Cashe (GAC) works but not the lvlib namespace in the context of LargeProject.  It is a valid fix and the OS does like to look in GAC.  I still suspect that you ran into a longer than expected path name.