4

I have some projects that rely on external .Net assemblies to operate. These are installed externally from my program so I do not have direct control over what version is being used. Furthermore, updates are expected to be installed as a matter of course.

For example, in one case I am accessing a hardware device that provides a .Net interface to control it. When the user initially installs the device, they install the driver that is included. This driver when I wrote the program may have been 3.0.4.0. The latest version might be 3.1.8.0.

My program fails to load the assembly when this happens complaining that the manifest definition is incorrect. A specific exception message is show below.

Another example is a labeling program. They provide a .Net interface to allow my program to print labels through their system. Installing an updated version of the program is fatal.

Here is the specific exception message:

Could not load file or assembly 'SDK.NET.Interface, Version=17.1.0.0,
Culture=neutral, PublicKeyToken=865eaf3445b2ea56' or one of its
dependencies. The located assembly's manifest definition does not match
the assembly reference.

If I install this version of the application on my computer, then reference the updated version of the assembly and compile, I’m good to go . . . for now.

But, it’s only a matter of time before I will have the issue again.

I’ve tried setting the Specific Version property of the referenced assemblies to False but that didn’t affect the problem.

What is the proper way to address the issue?

Rich Shealer
  • 3,362
  • 1
  • 34
  • 59

1 Answers1

1

You are able to "Plug and Play" as long as method signatures don't change.

If those change, then you'll need to fix your base code.

Look at Microsoft's documentation on Redirecting Assembly Versions: http://msdn.microsoft.com/en-us/library/7wd6ex19%28VS.71%29.aspx

Another option is If these libraries are somehow controlled by you or your company, you might have some wiggle room with reflection by loading them up by their base type/interface and using common methods... but you'll need to have access to the base types.

This is also a duplicate question:

Upgrade a reference dll in a C# project without recompiling the project

Upgrading dependent DLL without recompiling the whole application

Community
  • 1
  • 1
Ryan Ternier
  • 8,714
  • 4
  • 46
  • 69
  • Doesn't this require editing the configuration of the application's configuration file? So when the label app is updated and the version changes my application is out of commission until the new program's version number in entered into the binding statement or did I miss an ignore version option? – Rich Shealer Apr 28 '17 at 21:56
  • We do not control the third-party libraries or the machines they are running. We have app that uses them. As far as I've seen all of the signatures remain the same for the items we use. New Interfaces may be added but what is previously there are set in stone. – Rich Shealer Apr 28 '17 at 22:00
  • Then it just comes down to probably modifying the config file if needed. – Ryan Ternier May 02 '17 at 16:35
  • The bindingRedirect eventually worked for me. The New Version references the third-party's assembly version that I used. The redirect went into the main application App.Config rather than the project that uses the assembly. I think the reason is that the main application loads my project and as part of the dependency loads the third-party assembly. The sub project doesn't load it itself. – Rich Shealer May 23 '17 at 20:58