.net configuration files in LV 2013

[Michael_Wise]

So I'm looking for one of a few various solutions...

Creating a packed library that has .net calls that link to a specific path for the .net dll... the problem being when you build it relinks to the local copy it creates...

It'll eventually find the dll in the original path you specified but depending on how you call the LV VI this may or may not work (when calling from various forms of test stand)...

Can I create a .net config file for the lvlibp file that points it to a set dll?

I tried using the .net config files and couldn't get them to work in the basic functionality even on a built executable... I have two versions of the dll I would install into the GAC and then have the config file have a binding redirect such as in the documentation to the new version... the executable when the old version was installed into the gac would work fine no matter what you put into the config... I'm fine with that... but when I installed the new version of the dll and removed the old, the executable would break not being able to find the dll even with the correct redirect syntax in the application name.exe.conf file residing in the same directory.

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/net_specifying_assembly_version/

Anyone have any further thoughts/info/etc on using .net dlls and being able to update them independently of your TS or LV code and being able to link them to a given path vs having LV builds suck them into obliviion..

I have to do builds because the system will normally be running LVRT.

Thanks,

Michael

[Michael_Wise]

system will be running lv runtime (not realtime if I added any confusion)

[JÞB]

A fun question!

From What I gathered you a deploying a plvlib that is a dependancy of code modules in a TestStand Sequence and you want to know where to put the configuration file.

The easy answer is "In the same folder as the calling application"

Which means we need to look at the heirarchy view to find the application instance that the vi runs in.  It may be the lvproj of the LabVIEW module that calls the library member that uses the .net assembly if you call through the project.  It may be the UI if you call the .net assembly with a .net adapter or without specifying the project in a TS LabVIEW Step.  Again Heirarchy View will aid you in resolving this 

A word of caution:  do try to call all of your .net dependant code though the same context for any particular assembly  (Or your headaches will get worse and you may suffer hair loss resolving the various assemblies loading from a bunch of different places)

[Michael_Wise]

If it were only that simple....  What all I'm trying to do is this:

system runs TS and LV runtimes...

test stand calls .net DLLs

also LV calls a few of the same DLLs using LV wrappers for the said DLLs

Then lastly...

System calls LV wrappers to use said DLLs on a remote system that also runs LV runtime and has a dummy exe running for vi server to be open...

What I would like is the ability to all of these items to point to the SAME dll and have that DLL have the ability to be updated...

I had that working with a given version of a DLL if I registered said DLL to the GAC...

The test stand calls to that DLL if I update the GAC with a new version still work... but show a warning/message about wanting to be updated to link to the new version in the GAC.

The LV code on the other hand gets broken.

Ideally all of this code could point to a DLL in a set location that they all know/use.  But I'm also OK with them using the GAC copy, but want them to be able to some how work with new versions of the said dll without having to touch the TS or LV code.

The plvlib files are being generated because of running in LV runtime vs just having the vi on disk to eliminate having to jump through hoops to relink all of the vilib files to a compiled secondary location/version...

[JÞB]

Yup its not going to be that simple.  without really digging into your teststand I can't say what the "Application instance" context is going to be or haw many of them there are.  You may need several .net config files to point all of the modules to the same dll.

It may be easier to set the CLR configuration (Now I'm getting out of my depth)

What you did not answer was wether you call your LabVIEW modules with the project specified in the step configuration.  This would greatly ease your burden but, just one step config setting wrong could ruin your whole day! and I know of no easy way to enforce calling with the lvproj specified.  Its one of those "Style" things you just have to do and pay attention to.

[Michael_Wise]

So, the solution I think I'm going with is to use GAC.  If you reference a .net DLL from the GAC it no longer re-links when you do a build.

So, I'll be making packed lvlibs as my builds (to include vi.lib files/etc to run in the run-time enviroment).

The GAC installed DLL can also be called from test stand.

If the version of the DLL installed changes... Test Stand will tell you if you hover over a step, but seems to not care (wether this is good or bad is debateable, it even doesn't care if you're using an older version!)  Teststand will just run the available DLL.

LabVIEW on the other hand is what breaks... Two solutions do work for getting around this...

Solution 1)  aplication.exe.config files with redirects... this has to be in whatever directory and filename of whatever application instance is calling the VIs... wether that be test stand, labview, an OI, or an executable to run VI server...

Solution 2) which I think I'm going to use is to take similar configuration files and create policies which also get installed into the GAC.  The installed policy will affect any calls to the dll no matter where their executable lies on a given machine.

In regards to your question...

Does calling LV modules with the project specified fix runtime issues when using vi.lib files and running in LV runtime?  Specifically when you call those said VIs from TS to run on a remote PC?

Thanks and hope this info may help someone else in the future too!