Handling of .Net-Assemblies - Annoying for years

[Nominas]

Hi everyone!

I just want to start a thread about the annoying handling of .Net-Assemblies (dlls).

Hope we can get NI to take care of those problems.

- You can not exclude those dlls.

- You can not choose the path. When building your project, the dlls will be copied to the support-directory but not linked correctly in your application.

  If the dlls are in a directory beneath your app, LabVIEW will redirect them to the project-path...

- VIs in a packed library are ok, but you can't use them in a upper-level project if the dependency changed (This did not help)

Am I wrong?
Do you have the same problems?

Or a solution? A satisfying project- and file structure?

Best regards

Nominas

[rolfk]

My solution is to avoid .Net like the plague and always use Win32 APIs whenever possible. Works great and is much more backwards compatible than .Net with its forceful push to require the latest and greatest of all involved dependencies.

[Kyle97330]

Our solution has been something like this:

C:\Projects\ProjectName\Application\

C:\Projects\ProjectName\Project\ProjectName.lvproj

C:\Projects\ProjectName\Source\...

C:\Libraries\LibraryName\Libraryname.lvclass

C:\Libraries\LibraryName\SomeNet.DLL

C:\Libraries\LibraryName\SomeNetDependency.DLL

For each project:

• All .lvproj files go in C:\Projects\ProjectName\Project
  • Nothing in a subdirectory of this because it will auto-find files, especially DLLs, in here that you might not want to use
• All VI,CTL, VIM, etc. files specific to the project in C:\Projects\ProjectName\Source
• ProjectName builds all EXEs to C:\Projects\ProjectName\Application
  • Important: The "support directory" for the build is the exact same.  It is not "C:\Projects\ProjectName\Application\data" or anything else, it is also "C:\Projects\ProjectName\Application".
• All shared libraries go in a different directory, such as C:\Libraries\LibraryName\
  • This could be in instr.lib, user.lib, or a folder not inside of the LabVIEW 20xx folder and instead on the C drive near the root
• All shared libraries using DLLs go in a class or class hierarchy of some kind
  • All DLLs and their dependencies (important!) need to be added to the .lvclass file as class member

One of the biggest .NET problems LabVIEW has is finding dependencies of DLLs and including them properly.  If you add a DLL and all its dependencies as class members, LabVIEW auto-includes them in the build because LabVIEW always includes all members of a class in a build no matter what build options you choose.

When .NET is being used and searches for dependencies, it pretty much only looks in the folder the EXE is in and the GAC reliably.  Since there is no practical method to install arbitrary DLLs in the GAC with LabVIEW, they need to be build all to the same folder with the EXE file.