issues on load .net assembly in application

[royceking]

we use a .net dll in the project, it works fine in develop environment.

after built into application, the application popup a diaglog to select the dll, means it can't load this dll in the data folder automatically.

we have searched the forum about loading .net dlls,  and tried something, but it doesn't works.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAm6SAG&l=zh-CN

https://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/configuring_clr_version/

[royceking]

actually, i find  a thread that matches this issues most, but it seems no good answers..

https://lavag.org/topic/18992-application-requires-manually-specifying-net-dll-location/

[rolfk]

Well, your DLL depends on other DLLs. LabVIEW doesn't and can't know about such secondary dependencies and Windows will only search for them in two location by default:

1) The directory where the exe file resides that started the process (your mybuildapp.exe)

2) The Windows GAC

That's a Windows "feature" that you have to live with. Find those secondary dependencies and put them in the same directory than your exe file. Problem solved.

Alternatively the software from which your main DLL comes should really have a full featured installer that puts all the assemblies in the GAC or other appropriate locations. Without that it is not a product, just a prototype driver.

[royceking]

thanks for the reply.

but this .net assembly (PLCCommLibrary.dll displayed in dependency) has no other dependency. this is a single, stand-alone assembly, we have used this dll in different projects, no problem at all. In all projects we used, this dll is located in the \data folder generated by the build process.

the difference between this new project and the ones we used before is, we use classes to load specific instance, similar to HAL, but the base class and all specific classes(here the SiemensS7 and OmronFinsTCP) are all loaded statically, i think there is no path issues.

[rolfk]

It's obviously not! LabVIEW does not try and also shouldn't try to track down secondary dependencies, so even if there are no other dependencies visible in the project view, that means absolutely nothing about if your assembly has such dependencies!

It may be also maybe a mixed mode assembly that also contains compiled C++/CLI code and then it would depend on the Microsoft C++ Runtime library. This Runtime library depends on the version of the Visual Studio compiler used to compile the assembly. While most Windows systems may have had the necessary C Runtime installed, that doesn't have to be the case. Each Windows version comes with one or more versions of this C Runtime installed but which depends on the Visual Studio versions used to create the different tools included in Windows. Also other applications you install in Windows will also come with their own version of this Runtime so it may have been installed by one of these application installers on the other computers.

Basically your PLCCommLibrary.dll should have come with a full featured installer that takes care about installing ANY necessary dependency it has onto a system!

[Kyle97330]

Instead of making a separate "data" directory, try making both the EXE and the data directory point to the same folder.  Like, on the "Destinations" tab in the build properties, set the "Support directory" to be "ProjectApplication\Builds\MainApp", by getting rid of the "data" on the end.

[royceking]

thanks, got what you mean.

just now we have a computer that can generate an application without this issue(using this assembly without class).

we put this source code to the computer so all the .net environments are exactly the same. but the application built still have the same issue.

[royceking]

tried this, but makes no difference.

[royceking]

it's done, the issue is solved.

we just place one constructor node of this assembly on the block diagram of the plc base class.

then all things works fine. don't know why. maybe the method of loading classes, but all classes are loaded static.

thanks for all reply.

[rolfk]

Glad you solved it but your last three messages contain none or bad information. 

The first two are just empty claims without any useful informations as to what you really did nor what doesn’t still works. Putting the sources on the computer?Which sources? Did you write this assembly yourself?

And inthe last you talk about adding a constructor node on the diagram but there is nowhere a constructor node on the image you show. Also you claim that all classes in the assembly are static but if that was the case you couldn’t use a constructor node since LabVIEW would have nothing in the assembly that could be instantiated.