Creating drivers using an unsigned .NET framework and distributing through VIPM

[Cal27]

Hi all,

I have been trying to use VIPM to distribute drivers that rely on a .NET framework that is unsigned (i.e not in the global assembly cache). My issue is that after the package is installed, none of the VIs will work because LabVIEW cannot locate the .net assembly. However, if I launch labview by opening the library VIPM installed, all of the VIs will work, and LabVIEW is able to locate the the .Net framework and it appears in the main application instance. I need to be able to use the installed vis all the time, not just when LabVIEW is launched in this particular way. If anyone knows how this could be done it would be greatly appreciated.

Here is a link the all the files I used:

https://www.dropbox.com/sh/yjt2a0t8msxhgfn/AAC4VVW-hPawwXtGMrZ6wuIra?dl=0

Here are the steps I went through:

1) We put all the .NET dlls and the LabVIEW.exe.config file in the Labview directory.

2) We installed the package on our computer.

3)We closed everything and relaunched Labview from the start menu. Then accessed the BioRobotics/Vicon palette.

4)We placed the Get Ref subVI on the block diagram, opened it up, and ran it it.

5) We got the following error:

We also get a similar error for any VI that uses a method associated with the .NET dll.

6) However, if we again start with everything closed and launch Labview by clicking on the VICON.lvlib located in the vi.lib

7) Then repeat steps 3 and 4. We do not get any errors in the VIs on the palette, and the .Net assembly loads fine. We can even close the library and everything still works. Somehow opening the library first makes LabVIEW know to load the ViconDataStreamSDK_DotNet assembly when using functions on the Vicon palette.

If anyone does attempt to build a new package, it is worth noting that I included the dlls in the source files, and in the same folder as the vipb:

Thanks!

Callan

[TwinTwo]

Hello,

Hey could you review the next link to assure you did everything the right way:

http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/config_net_app/

Maybe this could be causing you issues.

[TwinTwo]

This other links might help too:

http://www.dependencywalker.com/

http://digital.ni.com/public.nsf/allkb/C4EA5ABBEB67AF7C862573F3004D4421?OpenDocument

http://digital.ni.com/public.nsf/allkb/567F6EFFC5669C348625739B003739CD?OpenDocument

[Regulator]

Constructor Node Details When you place this node on the block diagram, LabVIEW displays the Select .NET Constructor dialog box. You also can double-click the node to display the dialog box. Some constructors can contain initialization parameters you can use to create a .NET object in a particular state. Not all constructors have initialization parameters. If you encounter problems loading a particular assembly or accessing objects in an assembly, debug the assembly call or use the .NET Assemblies in Memory dialog box to verify that the correct version of the assembly is in memory. http://zone.ni.com/reference/en-XX/help/371361H-01/lvcomm/constructor_node/ http://zone.ni.com/reference/en-XX/help/371361H-01/lvdialog/assemblies_in_memory/ Path—Indicates the location on disk of the associated assembly. If the path of the assembly does not match the path of the assembly you want LabVIEW to load, remove the displayed assembly from the assembly search path. This forces LabVIEW to locate another version of the assembly. So if you get rid of the path maybe you'll be in business.

[Cal27]

Hi TwinTwo,

You bring up some good points.  I had used a coinfig file named "LabVIEW.exe.config" before:

<?xml version ="1.0" encoding="utf-8" ?>
<configuration>
   <startup useLegacyV2RuntimeActivationPolicy="true">
      <supportedRuntime version="v4.0.30319"/>
   </startup>
</configuration>

and placed it next to the LabVIEW.exe file.  However, as far as I know this is just targetting a specific CLR version, and it really doesn't make a difference if i delete the config file.  I'm not sure what syntax to use in a config file to tell LabVIEW to load an assembly into memory when a library is launched.  However, I will look into this more.