Installation error: Could not load assembly WindowsForms

[AlbertJ]

Hi James

I try to install Visa 4.0, and it gave me an error.  After that this started hapening.

The version of NationalInstruments.Common.dll in C:\Program Files\National Instruments\MeasurementStudioVS2005\DotNET\Assemblies\Current is 8.0.20.274

I have two verions of this dll in "c:\windows\assembly\"  8.0.20.274 and 8.0.20.270

I am thinking that it might be due to the fact the VISA 4.0 did not install correctly.  But if this is the case, then the sample program would not work, but it does, the sample in the following folder..

C:\Program Files\National Instruments\MeasurementStudioVS2003\DotNET\Examples\Visa\VisaicNS\CS\bin\Debug\VisaicNS.exe

I am waiting for somebody to help me with the VISA installation problem too.  The engineer in charge of this problem is Krista Schone.

Thanks for your help.

[James M]

Hi AJ,

It is very likely that the VISA installation error is at the heart of this issue, so I will stay in communication with Krista in regards to that. In the mean time, try removing and then adding all the national instruments references to your project.

Regards,

[bilalD]

Hi Albert

Is there an app.config file in your project? By default, if you build our examples with VS2005, you get the following warning

Consider app.config remapping of assembly "NationalInstruments.Common, Culture=neutral, PublicKeyToken=4544464cdeaab541" from Version "8.0.20.274" [C:\WINDOWS\assembly\GAC_MSIL\NationalInstruments.Common\8.0.20.274__4544464cdeaab541\NationalInstruments.Common.dll] to Version "8.1.20.166" [C:\Program Files\National Instruments\MeasurementStudioVS2005\DotNET\Assemblies\Current\NationalInstruments.Common.dll] to solve conflict and get rid of warning.

THis happens in the case where we installed a policy file in the GAC so that VISA will be able to use the newest version of Common on the system. VS2003 did not report this as a warning, but VS2005 was because it detect that the version of Common in the project is different from the version of Common the visa assembly is expecting. The Common assembly is shared by various products so it is possible for it to get upgraded by running the installer of another NI product. We always install a policy file so that applications built against an older version of VISA will continue to run. The .NET Runtime will redirect the binding to the newest version of VISA automatically based on the policy file in the GAC.

But coming back to the issue at hand,

If you click on this warning, VS2005 will create an app config file for your project by showing you the following message

---------------------------
Microsoft Visual Studio
---------------------------
One or more dependent assemblies have version conflicts.

Do you want to fix these conflicts by adding binding redirect records in the app.config file?
---------------------------
Yes   No  
---------------------------

If you click Yes, VS 2005 adds an app config file which binds our executable with a specific version of Common and overrides the policy file we install in the GAC for the Common assembly. This gets rid of the warning and the application will continue to function.
What this means is that if you now have a newer version of Common on your system becasue you upgraded to a newer version of VISA (we uninstall the older Common DLL, Common is designed to be backwards compatible), since you are now bound with a specific older version of Common that is no longer present on your system, your application will throw runtime errors reporting it cannot find the version of Common it is bound with.

If this is what happened, try removing the app config file from the solution, rebuild it and rerun the app.

Let me know if this helped.

[jsytniak]

I am seeing the same problem. The NI merge modules are defined in my VS2008 set up package as they were defined by the dependencies determined by VS2008.However when the setup is run on a target machine the NI components are not installed and none of the files are anywhere to be found on the target machine. I prefer not to install these files into application directory. My expectation is that the merge modules would copy the files to the target machine and register them in the GAC.

I hope I am misinterpretting the suggested solution.

Am I to understand that a manual GAC registration step is required in order to deploy a windows forms application that uses NI components? That I cannot simply include the apporpriate merge modules in my installer and count on the reuired assemblies to be deployed properly on the target machine?

[JonathanN]

The default behavior of our merge modules is to install the assemblies and any necessary components into the application directory. However, we do allow you to override this setting for our merge modules and install these components into whatever directory you so chose. However, you must remember that the .NET CLR requires that assemblies live either in the GAC or the same directory, or subdirectory of the application so that it can locate them at run-time. I'm simply pointing this out so you don't start dumping the assemblies into random locations that the CLR doesn't look in.  Enough talk, so how do you configure this setting...

1. In the File System tab, right-click the pane and select Add Special Folder >> Global Assembly Cache Folder
2. Select an NI merge module in your Setup project.
3. In the Properties Windows, expand the MergeModuleProperties section.
4. Now simply change the location of the Module Retargetable Folder property. You will only be allow to choose a directory you have specified in your File System viewer. That's why I had you add the GAC directory earlier.
5. Repeat steps 2-4 for any other NI merge module you wish to override.

Best Regards,

[jsytniak]

Results made easy as pie.

Clear, concise, not condescending, prompt, and most of all... correct.

Thanks for the assistance and for teaching me a little about VS setup projects.

Joe

[AlbertJ]

Thanks a lot guys for all your responses.

Kudos to all of you.

AJ.

[jsytniak]

There is one last piece of this puzzle that I may as well follow up on here.

VS will detect all possible dependencies. This makes sense. The thing is, when I make use of only a small subset of the entire functionality of a component, I can probably get away with distributing far less (less merge modules). For instance, VS identifies mstudiodesign.2008.msm as a dependency. I am pretty certain I can safely eliminate this merge module from my install package. Is there a cross reference document someplace that shows the relationship between functionality and merge module? I suppose I could just use a build and test method for determining the least necessary distributable, but I prefer to work smarter rather than harder.

Joe

[JonathanN]

Take a look at the Measurement Studio .NET Merge Modules and Measurement Studio .NET XCOPY Deployment Files help topics in the NI Measurement Studio Help. These topics are both found under the Deploying Applications >> Merge Modules and Deployment Files category in the table of contents.

Best Regards,