Q: How to handle new releases of third-party .Net assemblies without recompiling? 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?

A: 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
