.NET WinForm app can't load NationalInstruments.Common that's in GAC (urgent)

[dtnpsi]

We have a .NET WinForm app that uses DAQmx...   (only using the NationalInstruments.Common and NationalInstruments.DAQmx assemblies... not MeasurementStudio)

Most times it works fine, but on some systems in some situations (?), we get the following error. Once the error begins occurring on a system, it's solid, not intermittent.

"Could not load file or assembly 'NationalInstruments.Common, Version=8.0.11.194, Culture=neutral, PublicKeyToken=4544464cdeaab541' or one of its dependencies."

But that version of that assembly with the correct public key token is in the GAC!

And NationalInstruments.DAQmx (8.0.11.12) is also in the GAC (same token). 

There are also later versions of these same NI  assemblies in the GAC (8.1, 8.3 and 8.5),  but the particular app in question is still bound to the older version (and upgrading at this time isn't an option).

So why can't it find it?   If a given assembly is in the GAC, must all its dependencies also be in the GAC, or can its dependencies be in the app root (~\Program Files\app\bin)?  When the users install the NI-DAQ "drivers" from the CD, is it possible that they are selecting some un-needed NI component that is hosing the GAC? Our documentation tells them to only install MAXX and the .NET framework support. 

===> Is it possible that installing a later version CD might be causing a problem? (this is what I suspect has happened)

Thanks,

DT

[JonathanN]

Hi dtnpsi,

Before I begin, I want to point out that the majority of what I'm about to state is found in the following help topics in the NI Measurement Studio Help:

• Measurement Studio .NET Class Library Versioning for Development and Deployment - Very important to read through since versioning of Common is different than versioning of other NI assemblies. 
• Measurement Studio .NET Merge Modules - Describes dependencies which is important when creating a VS installer to ensure that you installer encompasses all the required components. 

Okay, so because you stated that you found that exact version of Common in the GAC, the only scenario I can think of in which you would receive that error is if you are missing some of NationalInstruments.Common's dependencies like NationalInstruments.Common.Native.  Now, if you created an installer in Visual Studio, you should have included the MStudioCommon.2005.msm merge module which houses the Common and Common.Native assemblies. Visual Studio should have automatically added this merge module and its dependencies for you (i.e. if you added a setup project to your DAQmx project in which the setup project would determine what dependencies your DAQmx program had.). For example, I created a quick DAQmx project and added a setup project to it and as you can see, Visual Studio picked up the needed components (see attached snapshot Setup Project.png). If you are missing one, then you need to add it, otherwise you could run into error on the target systems. 

Now with regards to Common versioning, the NationalInstruments.Common.dll uses a publisher policy file to redirect applications to always use the newest version of NationalInstruments.Common.dll installed on the system. So if you installed a newer driver on your target system (i.e. like for DAQmx), that driver would install a newer version of Common into the GAC. Any .NET applications referencing Common on that system will be routed to this latest version of Common. We go into more detail about this in those help topics I mentioned earlier.

As far as installing later versions of DAQmx on those target machines, this should be fine. The rule of thumb to follow is that you must have the same version or higher of a driver that you built against on any deployment target machine. So if you build against version 8.6 of DAQmx, then you need 8.6 and later on those machines. We have tested this and it works fine. 

So with regards to your exact problem, I'm not sure if any of the information I have said so far really helps, since your scenario really doesn't make sense. So it would be nice if you could give me an exact step-by-step process of your deployment process. What versions of DAQmx were you building against, what versions are on the deployed systems, what steps did it take to reproduce that error, etc.

Best Regards,

Message Edited by Jonathan N on 05-15-2008 12:55 PM

[dtnpsi]

As I stated in the first line of my post: we are not using Measurement Studio.  When we wrote this app a couple of years ago, we only installed (as I recall*) the DAQmx .NET interface components on our dev systems from the 8.0.1 DAQmx CD.    *(and Add/Remove programs only says "National Instruments Software" is installed on my system - with no other details - so I'm not certain exactly what was installed). 

So we don't have the documentation you referenced.  But obviously, it would have been very helpful!   Can I install only the Measurement Studio help... without installing Measurement Studio itself?  (the DAQmx CD seems to try to install a whole boatload of stuff anytime it's used...  But that's another gripe we - and our customers - have with your software).

It sounds like we should be including your merge module into our setup. At present, we're explicitly including only .Common and .DAQmx.  I've never heard of .Common.Native.   Are you sure that it was part of 8.0.1?

Our setup project only detects .Command and .DAQmx as dependencies (that's why we included only those two).  What's required to make our setup project detect the merge module as a dependency?  Where is that merge module located?

Also, I recall that there's a problem with using merge modules if you allow the user to specify an alternate install folder.  Like the merge modules ignore the alternate location, or something like that?

Thanks,

DT

[JonathanN]

Hi dtnspsi,

Even though you might not have Measurement Studio installed, you will still have some of those help topics in the NI-DAQmx help. When you select the .NET Framework x.x Support in the installer tree in the DAQmx installer, this installs the underlying examples, assemblies and documentation for .NET. You can open this documentation by selecting Start >> All Programs >> National Instruments >> NI-DAQ >> NI-DAQmx .NET Framework x.x Help. This will launch and you will notice that some of the help topics say Measurement Studio. So you should have those help topics that I mentioned. 

Yes, its best practice to include the merge modules in your setup project instead of the individual assemblies. There is various custom actions that are associated with those merge modules that we use.  If you wanted to just directly use the assemblies in the setup project, then you should refer to the Measurement Studio .NET XCOPY Deployment Files help toipc which shows you for NationalInstruments.DAQmx, you need the DAQmx.dll, Common.dll and Common.Native.dll. 

If you are using Visual Studio and you created a setup project, if you selected the primary output to be your application output (i.e. where that application was your DAQmx app), it should have automatically added the Common and DAQmx merge modules. As I mentioned earlier, the Common merge module contains both Common and Common.Native.  The merge modules are located in the Program Files\Common File\Merge Modules directory.

As far as the specific folder locations associated with the merge modules, for every msm except Common, the merge module default setting causes assemblies to install to the main Application directory.  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.

Best Regards,

[dtnpsi]

OK, I found the Help and other stuff, but I still don't see Common.Native anywhere. It's not in ~\DotNet\Assemblies\Current (only Common and DAQmx are there), and it doesn't appear in the File table of either the MStudioCommon.msm or MStudioDaqmx.msm (opened with Orca).

Another concern: because we're still using DAQmx 8.0.1, it only has MeasurementStudioVS2003.  But we've transitioned the app dev to VS2005 last year (and from .NET 1.1 to 3.0). So I suppose there's some exposure there. 

What's the current (and most stable) version of DAQmx for VS2005/.NET 3.0 dev:  8.3 or 8.5 or....?

Thanks, we're getting there!

DT

[JonathanN]

Hi dtnpsi,

Yeah, I forgot that you were using VS 2003 and the 1.1 assemblies which didn't have the Common.Native assembly. This assembly was introduced when we started supporting the 2.0 framework. Since you don't have that assembly, the problem must be somewhere else. So in this case, I just need some steps to get into the same state.

The latest version of DAQmx that we have is DAQmx 8.7.1 which provides support for the 2.0 and 1.0 framework.  This has been tested and works fine in VS 2005. 

Best Regards,

[dtnpsi]

We'll migrate our app to 8.7.1 and change our setup to use the provided merge-modules. 

The field user who was having the urgent problem (and who was in the jungles of Belize) was able to restore their system and get it operational again. So the need for an immediate fix has been somewhat reduced.

I think our not using the merge modules was the root cause, since we thus didn't have the proper GAC assembly versioning policies in-place.  And thus when the field user took it upon themself to install the latest DAQmx CD they happened to have, things got a little screwy....

Thanks for the help!

DT

[JonathanN]

No problem. Just sorry you ran into that much trouble. The merge modules should reduce these headaches for you.

Best Regards,

[dtnpsi]

A couple of follow-up questions:

1) While we were trouble-shooting this problem, we noticed that our field user's GAC contained not only several versions of NationalInstruments.Common (as one would expect) but also several versions of NationalInstruments.DAQmx (8.0, 8.3 and 8.5), as well as various other NationalInstruments assemblies, such as .Design, .Net, .UI, .UI.Styles3D, .UI. WebForms and .UI.WindowsForms.

Based on my understanding of your explanation of where the assemblies should be installed, I don't understand why are there copies of .DAQmx in the GAC

I know that our .msi didn't put them in the GAC. And there are no other apps using NI-DAQmx. 

Is there anyway that could have been put DAQmx into the GAC when the "drivers" CD was run?   

My concern is that even after we change our .msi to use your merge modules (and thus install .DAQmx into our local app's bin), there will still be some other mechanism (the NI drivers CD?) that we're not aware of that's putting .DAQmx into the GAC, which will prevent the CLR's search from finding DAQmx in the app's bin.

2) How can we completely eliminate the need to use the NI drivers CD?  (actually, I've asked this question in another thread more than a year back).  How can we include everything that's needed to access the NI device into our app's .msi ?  What exactly must get installed on a system (in addition to .Common and its dependents and .DAQmx) in order to access the hardware? Requiring the field users to run a separate install from the NI drivers CD is, I'm afraid, contributing to the problems we're having (and the users absolutely hate running the NI drivers CD...  so much that they question why we can't use some other vendor's DAQ hardware!).   

Thanks,

DT

[dtnpsi]

Jonathan,

On 3-14-2008 Paul C. replied to my thread titled "NI-DAQ installation is intolerably slow"... with information about a repackaged 8.5 runtime.

Is there a repackaged 8.7 runtime?

DT