System.IO.fileloadException: Could not load file or assembly NationalInstruments.Common, Version=13.0.40.188 The located assembly's manifest definition does not match the assembly reference.

[Chris.Dickerson]

I should have mentioned, the app in question is in WPF. I reviewed the XCOPY information again, and I have all the required associated files copied to the client machine.

[kevins33]

Hi,

It does seem like the problem is caused because version 13.0.40.188 was not found in the GAC, but version 13.0.40.190 was found and used instead. Due to this mismatch, the setup is unsuccessful. In reality, version 13.0.40.190 can be used, but we need to include a configuration file with our installation that specfically states that it is ok to use version 13.0.40.190 in place of 13.0.40.188 when NationalInstruments.UI is loaded.

To add the configuration file, right-click on your project in the Solution Explorer in Visual Studio. Select Add >> New Item >> Application Configuration File >> Add. Open the configuration file after you create it. Locate the publisher policy file for NationalInstruments.Common Version 13.0.40.188 in the GAC - C:\Windows\Microsoft.NET\assembly\GAC_MSIL\policy.13.0.NationalInstruments.Common. Open the "policy.13.0.NationalInstruments.Common" folder and choose the most recent version of the assembly. Inside the folder you will see a publisher policy assembly and config file. Open this config file in a text editor and you should see several "bindingRedirect" elements inside a "dependentAssembly" element which is nested inside a top-level "configuration" element. Copy everything within the "configuration" element and paste the contents into the "configuration" element for your project's new configuration file in Visual Studio. The end result should look some thing like the example in the link below:

http://msdn.microsoft.com/en-us/library/0ash1ksb

Please try what is outlined above!

[Chris.Dickerson]

Thanks Kevin, but that's one of the first things I tried. When you do a redirect like that, you get a flat error "Cannot load assembly".

[TBirkulosis]

A configuration file to redirect to the latest version sounds like the correct solution since you cannot create an installer. Could you post your configuration file? I would like to see how you are redirecting NationalInstruments.Common to use version 13.0.40.190.

Also, could you post the Fusion Logs generated when you use the configuration file? This will provide more debugging information about the failure to load the assembly.

[Chris.Dickerson]

Files attached:

initial-error.png - the error you receive when there's no config defined - TDMS is looking for the NationalInstruments.Common assembly that doesn't exist.

redirect-error.png - the error that you receive when you use the included config with binding redirects that point you to the current NationalInstruments.Common assembly.

NiTdmsCommon.zip - a simple example that connects to a Tdms file and dumps the names of the groups when you click the button.

I included code in the App.xaml.cs to handle unhandled exceptions and display them in a MessageBox. There is a file in the bin\Debug directory -- files.txt -- lists the assemblies that I copied to that directory for testing on the machine that has no other traces of National Instrument products installed.

[D-Cubed]

Hey Chris,

Would you mind posting your current config file contents?

[Chris.Dickerson]

Daniel:

The attachment in my previous post -- the one I use is in that example in the bin/Debug directory (NiTdmsCommon.zip).

[TBirkulosis]

Thanks for posting the example files and error images. Is the Fusion Log posted in your earlier message here from the deployment with or without the configuration file?

I did a search on stackoverflow for the error message in redirect-error.png: "Unhandled exception - Exception: An attempt was made to load a program with an incorrect format . (Exception from HRESULT: 0x8007000B)." 

It looks like this error can occur with bitness mismatch (32-bit or 64-bit). For example, it can happen when the assembly (DLL) is 32-bit and the executable is 64-bit. There is a 32-bit version and a 64-bit version of NationalInstruments.Common. Step 2 of Measurement Studio .NET XCOPY Deployment Files lists the locations of the two versions of NationalInstruments.Common.

What is the bitness of the computer that gives the error? What is the Target CPU of the project (Project  > Project Properties > Compile)? Which version of NationalInstruments.Common is included in the XCOPY deployment?

Stackoverflow forums:

1. An attempt was made to load a program with an incorrect format

2. Loading a 32-bit dll in a 64-bit process [duplicate]

3. .net Framework Error (HRESULT 0x8007000B)

---

 As for the configuration file (if the bitness turns out to not be the issue), the main difference I see between NationalInstruments.Common.config (that Kevin mentions) and the example NiTdmsCommon.exe.config is:

NationalInstruments.Common.config

<bindingRedirect oldVersion="13.0.40.100-13.0.40.189"
newVersion="13.0.40.190" />

NiTdmsCommon.exe.config

<bindingRedirect oldVersion="13.0.40.100-13.0.40.999"
newVersion="13.0.40.190"/>

I'm not sure what the consequence is having the newVersion be within the range of the oldVersion.

[TBirkulosis]

Looking back the your post here, it looks like the 32-bit version of NationalInstruments.Common is being copied over in the deployment. If the project's Target CPU is set to "Any CPU" or "x64" and run on a 64-bit computer, then the application will be unable to load the 32-bit DLL.

[Chris.Dickerson]

I've been through all this before as well.  The "Could not load file or assembly" error is usually a difference in platform (x86 vs x64) and that's where I looked when it first occured. If you set my sample project to x86, it doesn't help -- same error occurs.

As far as the version filter -- you can use a specific version or a range to include all possible octets, you get the same results.