I have a strong-named .NET assembly PluginHost which dynamically loads plugin-assemblies using
Assembly.LoadFrom(). It has an Assembly- and File-version of 126.96.36.199. Every plugin-assembly references PluginHost because in PluginHost there is an interface defined, every plugin has to implement.
Now I want to deploy an updated but fully backward-compatible version of PluginHost with Assembly- and File-version 188.8.131.52. But now the old plugin-assemblies fail to load since they reference PluginHost thru its strong name which includes the version number.
How can I deploy a new version of PluginHost without breaking old plugins?
One solution I found is to set the Assembly-version of PluginHost to 1.0 and keep it at 1.0 even in updated version. I only change the File-version from 184.108.40.206 to 220.127.116.11 and so on with each new update. That way old plugin-assemblies load without problems.
But is this the way to go? Is there a better way? I don’t think leaving the Assembly-version on a constant value is right.
Additional background information that might be of interest: PluginHost is used with COM Interop in a VB6 app. Thats the reason it has a strong name. Neither PluginHost nor the plugins are in the GAC. PluginHost is registered with RegAsm.exe.
Thanks for your answers. Since there seems not to be a reasonable way to use an application configuration file with COM Interop I guess I stick with freezing the Assembly-version and only change the File-version in new versions of PluginHost.
I hope I’m understanding what you’re trying to do correctly. If so, one way is to use the
bindingRedirect element in the application configuration file. For details on redirecting assemblies, see MSDN.
I personally leave the AssemblyVersion fixed unless I know I’m making breaking changes. And in your case, since you don’t deploy to the GAC, you don’t get the benefit of side-by-side deployment anyway so what would be the benefit to changing your AssemblyVersion?
If you do have to update the AssemblyVersion, you have two options:
- Adding a bindingRedirect element in the consumer’s app.config file.
- Deploying a Publisher Policy file with your assembly.
Given that your consumer is VB, that rules out using the app.config. That leaves you with deploying your PluginHost to the GAC and using a Publisher Policy file.