Search code examples
.netc#-2.0gac

.Net dll reference - deployment onto PCs with different versions of 3rd party dll

Could you tell me the best approach for this scenario. I have inherited a new project and have not come across this scenario before.

We have a reference in our C# Windows Forms application to a 3rd party tool for producing documents.

There are two different versions of the 3rd party tool in the deployment environment installed on people's PCs - v1.0 and v2.0.

I can only build our Windows Forms application to work with either v1.0 or v2.0 of the 3rd party tool. To do so I have to install either version on my development PC before building. This is obviously a bad approach as I have to uninstall/reinstall the 3rd party tool each time. If I build with the wrong version on my PC the user receives 

Could not load file or assembly 'Interop.IManage, Version=1.0.0.0, Culture=neutral,     
PublicKeyToken=141424aa94e741g5' or one of its dependencies. The located assembly's 
manifest definition does not match the assembly reference.

There appears to be only one reference to a dll in the project, which is using a GAC reference.

C:\WINDOWS\assembly\GAC\Interop.iManage\1.0.0.0__141424aa94e741g\third.partyTool.dll

Which changes to this of I uninstall v1.0 and install v2.0

C:\WINDOWS\assembly\GAC\Interop.iManage\2.0.0.0__141424aa94e741g\third.partyTool.dll

In terms of deployment of our application, we do a simple XCOPY of the files, there is no installer.

Is there a way I can hold both references in our application and then have it use the correct reference once deployed? Or is there a deployment method I could use to get around this?

Thanks

Solution

  • You can build always against the 1.0.0 3rd party assembly and then do a binding redirect (in your app config) to use the 2.0.0 version, if available.

    See here: http://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.100).aspx for more details.

    Some more samples here: http://blogs.msdn.com/b/thottams/archive/2007/01/30/introduction-to-versioning-and-bindingredirect.aspx?Redirected=true.

    A SO post also describes a common problem when setting up binding redirection: Assembly binding redirect does not work.