Using .NET DLLs leads to missing NationalInstruments.Common.dll version 8.0.20.270

[YohanShminge]

Hi Everyone,

I have a strange problem here... I'm working on a bit of code which utilizes a single .NET DLL.  On one computer, the code runs without problem.  But on another, at random property and/or invoke nodes, I get the following error:

Error accessing property PlugIn.XAnalogStream.TimeRange of ObjectId handle: 0xB751158 for obj 0x135567F[X_Device_Blackfin.AnalogStream] in domain [LabVIEW Domain for Run] and thread 2592, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
    Inner Exception: System.IO.FileNotFoundException: Could not load file or assembly 'NationalInstruments.Common, Version=8.0.20.270, Culture=neutral, PublicKeyToken=4544464cdeaab541' or one of its dependencies. The system cannot find the file specified.
) in Test_Analog_Stream.vi

I don't have this particular version of NationalInstruments.Common on either computer, but I do have a different version (8.1.20.168 and 8.1.20.237).  On the working computer, it looks like there's some kindof alternate version reference in the GAC, but I have no idea how to work with these.  Has anybody heard of this sort of error before?  My apologies for the limited information, but I'm not part of the original group that developed this DLL I'm using.  Thanks!

-Yohan

[Aashish_M]

Hi Yohan,

More info on this issue will definitely help. Could you tell me what version of LabVIEW you are using and what exactly does the application do?

Also, what version(s) of NationalInstruments.Common show(s) up in the GAC of the development machine?

There are versioning issues when deploying a .net application to a target machine when the development machine has multiple versions of the NationalInstruments.Common assembly.

For example, suppose the development system has versions 165 and 168 of the Common assembly and your application indicates that you have included 168 of the Common assembly. If the UI assembly was built against 165, it will automatically be routed to the 168 assembly via the policy files found in the GAC. If you deploy your application, then when loading up your application, the CLR will try and load the 165 version of the Common assembly and not the 168 version since there is no policy files to use.

[YohanShminge]

Hi Aashish,

Thanks for your reply.  My version of LabVIEW is 8.20.  The goal of this application is to interface with some .NET device drivers.

On the machine where the code fails to run, there are no versions of NationalInstruments.Common in the GAC.  I have one version (not the one asked for, but a later version) within the VIs execution folder only.  The only NI-related object I can see in the GAC is NationalInstruments.CVI.Reflector.  On the working machine (the development machine), there were several version listings, some of which I think are references, or something similar.  I'm waiting to hear back from the owner of that machine for more information.  Will let you know as soon as I find out...

[JonathanN]

Hi Yohan,

We discuss the versioning issues that you will encounter when building against our Common assembly in the Measurement Studio .NET Class Library Versioning for Development and Deployment help topic in the NI Measurement Studio Help.  Now, I know you may not have Measurment Studio installed but since you mentioned the Common assembly, this tells me that you installed one of our .NET APIs (i.e. DAQ, VISA, GPIB, SCOPE, etc) on that development machine.  Because of this, you will have the help topic on that machine.

This topic discusses both development and deployment scenarios.

Also, if you are unsure of what assemblies your assembly is built against, you can always look in the assembly manifest. There are tools like .NET Reflector and ILDASM which help with this.

Best Regards,

[YohanShminge]

Thanks for the info Jonathan.  I myself do not have Measurement Studio, but now that you mention it, I believe the development computer (the one without the version issues) has it installed.  I'll check out the other link you mentioned and let you know what happens.  In the meanwhile, I've attached a screenshot of the assembly versions present on the development machine.  Note the policies listed for NationalInstruments.Common.  I have a feeling this is what I need on my target computers, but I'm not sure how to make that happen.  Please let me know what you think.  Thanks so much!

[JonathanN]

Hi Yohan,

Whenever you are building .NET assemblies and are planning on using those assemblies on a different machine, its best practice to create an installer that would install your assemblies along with its dependencies.  When you create an installer in Visual Studio, the setup project will automatically check your project output for dependencies and include those dependencies for you. In this case, Visual Studio should include the MStudioCommon.2005.msm merge module (if you are using Visual Studio 2005).  The NationalInstruments.Common class library merge module default setting causes the NationalInstruments.Common class library to install to the GAC along with a policy file that redirects all references to NationalInstruments.Common to the latest version of NationalInstruments.Common installed on the system. This means that by default, applications that reference NationalInstruments.Common use the latest version of NationalInstruments.Common installed on the system.  NationalInstruments.Common is designed to be backward compatible with all prior versions.

Hope this helps

P.S. Its also best to look at the Measurement Studio Merge Module and Deployment Files help topic.

Best Regards,