开发者

.NET: Binding of assembly to an new version of referenced assembly without recompile

开发者 https://www.devze.com 2023-01-20 21:40 出处:网络
I have a strong-named .NET assembly PluginHost which dynamically loads plugin-assemblies using Assembly.LoadFrom(). It has an Assembly- and File-version of 1.0.0.0. Every plugin-assembly references P

I have a strong-named .NET assembly PluginHost which dynamically loads plugin-assemblies using Assembly.LoadFrom(). It has an Assembly- and File-version of 1.0.0.0. Every plugin-assembly references PluginHost because in PluginHost there is an interface de开发者_运维技巧fined, every plugin has to implement.

Now I want to deploy an updated but fully backward-compatible version of PluginHost with Assembly- and File-version 1.0.0.1. 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 1.0.0.0 to 1.0.0.1 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.

Thank you.

Update

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:

  1. Adding a bindingRedirect element in the consumer's app.config file.
  2. 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.

0

精彩评论

暂无评论...
验证码 换一张
取 消