.net private assembly location

[DMcAndrew]

Does anyone know if there's a way around the LabVIEW 7.0 requirement of putting private .NET assemblies in the same directory as the calling VI and the top-level VI? With this requirement it seems like I'll need to have multiple copies of the .NET assemblies while developing...

Thanks.

[AnalogKid2DigitalMan]

I do not think there is any way around it for private assemblies.

One method I used to keep just one instance/reference was to establish  the constructor node for the assembly in my top level vi, and pass the reference out so my lower level vi's can access the reference. Keep the reference open as needed and then close it in the top level vi before exiting the appication.

[Lycangeek]

Under LV 7, in order to keep everything working, you MUST keep the assemblies either in the GAC or in the same directory as the top-level VI. This requirement actually matches the requirements of Visual Studio as well - it simply copies the assemblies from their "referenced" location whenever you build your .NET application.

I would recommend creating a Post-Build step in your .NET assembly project to copy itself to the correct VI location(s) whenever you rebuild the assembly, removing the worry of keeping things in sync.

Under LV 8, we added the support to have the private assemblies to be loaded dynamically by the VI through a relative path stored in the VI.

HOWEVER

I strongly recommend that you try to keep your private assemblies together with the LV code, rather than rely on the relative path. The reason is that this support requires us to go around the way .NET wants things to be - and that simply increases the chances of hard to debug problems (I know, I've already had to debug some of them). If you really want to burn your brain, read more about Load vs. LoadFrom contexts in .NET (my blog and other locations, just search for it).

Side note - With the addition of projects in LV 8, we changed the rule about where the assemblies should be copied. With LV 8, the recommended location is the same directory (or subdirectory) of where your project (.lvproj) file is located.

[AndrewAlford]

There is a way for the .NET dll not to be required to be placed in the same directory as the Top level VI as long as the VI does not call the dll. In my application I have had a dll built to access one of our products. I then built a "driver" Sub vi that uses the dll. My top level VI calls this Sub VI, the sub vi and dll MUST be in the same directory, however, when the dll was compiled there is some sort of a COM option under the build menu (not sure about the specifics). When the dll is compiled with this option it only has to be in the directory where the VIs with constructor, property, and involke nodes exist. A top level VI can exist in a different directory.

[Lycangeek]

Are you using the ActiveX or .NET palette to call it? The COM option in the build is whether to expose the .NET class as a COM/ActiveX, and therefore you could assess the .NET component through either of the palette options.

[AndrewAlford]

I am using the .NET palette.

[Lycangeek]

I can't say what is allowing that to work (although I haven't seen the 7.0 code base - I arrived for the 8.0 development), but I wouldn't count on it continuing to work as you upgrade. Managing the complexity of .NET assemblies and keeping the development experience straightforward is an ongoing effort in our group, so I'm always open to suggestions and ideas to improve the experience. If you'd like to comment, please check out this posting

http://detritus.blogs.com/lycangeek/2006/01/no_more_loadfro.html

Message Edited by Lycangeek on 02-03-2006 09:48 AM

[DMcAndrew]

Here's a strange one. I have a .NET dll that I call from one directory and it works fine. When I copy it and a calling VI to another directory, it still runs fine but it copies the .NET dll to this temporary directory:

C:\Documents and Settings\dmcandrew\Local Settings\Application Data\assembly\dl3\05DZ5ZBO.Z0H\3MKO5NL3.YET\a72347dc

That would be fine except one of our methods reads from a file in the same directory as the calling VI so when copied, it returns an error. Anyone know what would cause the .NET dll to get copied?

Note that I have tried changing the pointers in ".NET Assembly References..." to no avail.

[Lycangeek]

When you run the VI, we create what is known as a Shadow Copy (see http://blogs.msdn.com/junfeng/archive/2004/02/09/69919.aspx). If your assembly needs to access files that are in it's "home" directory, you need to use the Assembly.CodeBase. If you use Assembly.Location, as MSDN says, it will be the location after the Shadow Copy.

[DMcAndrew]

Thanks Brian, that fixed our problem. Now we have another one... Our .NET objects are going to  be called about every 10 minutes in one piece of test code. They work correctly when called every minute but when the time between calls increases to 10 minutes I get the following error:

Code: 1172, Source: Object '/cedb92b5_d31f_4bfe_8030_c76284d10fcc/dfgxshpaa2kx6+lrhxddlhod_18.rem' has been disconnected or does not exist at the server.

It seems like a reference that has been destroyed may be being pointed to? I have tried calling our methods two ways: calling a constructor and releasing each time, and calling the constructor and releasing only once at the beginning and end. Both ways caused the same error. Any suggestions?

Thanks.