.Net dll does not load in labVIEW and TestStand when version changes

[sed_y2005]

I am using LabVIEW 8.5, Testand 4.0 and Windows XP.

I have been using LabVIEW Vi's which call .Net dll( created in v2.0, not strongly typed, and not added in GAC) , and Testand sequences that call these Vi's successfully.

As the version of the dll changed,I drag and drop new dll into same location and all hell breaks loose. The already working Vi's break and if I add a new VI and point to the new dll, Constructor node complains "cannot load assembly".

I tried a workaround given at:http://digital.ni.com/public.nsf/allkb/3C5F47E9845C535286257C7100501990

I have tried following steps:

1.  Close LabVIEW and the project
2.  Delete the old dll
3.  Open LabVIEW, open the project, open any VI that tries to use old dll. it cannot find it, so I stop loading the VI
4.  close labVIEW, drag and drop new dll at same location( and some other dll's and exe that are used by this dll, but they stay the same)
5.  Open LabVIEW, open the project, create new VI, add Constructor node and point it to new DLL
6.  close the Vi without saving it, and open existing Vi's and point them to new dll
7.  save and close the project

the problem is, this workaround works sometimes, and does not work many times. Even, if I change step 4 , and drag an drop new dll and its dependencies to new location, ( bring it back later) and repeating other steps, still does not solve the problem in deterministic manner.

I have tried upgrading to Lv2014, but problem still remains. Moreover, if anytime it works, I run the same VI from TS( and I upgraded to Ts 2014, which itself meant doing lot of process model changes and code change), it complains about one of the paths that dll resolves and fails. I go back to LaBVIEW, and now, it cannot load the dll again.

I have lost almost a month in this effort, so any help is appreciated. I cannot believe that NI does not have a permanent fix for this, or if there is, I don't know about it other than the one I cited above.

Either I am doing this incorrectly, or the dll's need to build in VS 2010 in a particular manner or while running LabVIEW/TS .net services seed to be modified while copying new assembly, I don't know.

Urgent help needed.

Thanks

[TBirkulosis]

When you create the Constructor Node, it will be associated with the original version of the DLL. You could use a .NET configuration file to specify the new version. This topic from the LabVIEW 2013 Help describes creating a .NET configuration file: Specifying Which Version of a .NET Assembly to Use. However, since you have LabVIEW 8.5, you may want to consult the LabVIEW 8.5 Help manual for any version-specific instructions. I believe the configuration file will work with LabVIEW 8.5, but it doesn't hurt to check.

Hope this helps,

[sed_y2005]

Hi  Taylor,

   First, this dll is given to be me by a different engineer, so I don't know if he might want to do this.

Anyways, i had tried using this method but  as i reach the step where "publickeytoken " need sto be specified, I noticed that dll is not strongly named.

I tried to do it using tool available, but ran into problems, as it  references one of the dll's, which also was not strongly named, and as it was not added to the project per se, i could not stronglyname it.

Moreover, this dll is used by some other applications, that also prevent it to be strongly named( as told to me by the engineer who gave it to me).

finally, even if i create the configuration file, how does labVIEW recignize it? Do i add it to same location where the dll resides, or a Vi need to load this first?

thanks

sedy

[TBirkulosis]

There is a link in the article that I posted ".NET configuration file" that goes to another topic explaining what to name the configuration file and where to put it.

As for the public key token, according to the MSDN article about <assemblyIdentity>, "publicKeyToken" is an optional attribute. Only "name" is required.

[sed_y2005]

Fo Now, we have changed how we use the dll for firmware download,( using .Exe), and other Vi;s are able to use updated dll(although I cannot add constructors or modify these VI's).

 So, I am able to use new dll, and once we are able to ship the software, I will come back to using the solutions you suggested.