.NET:将程序集绑定到引用程序集的新版本,无需重新编译

发布于 2024-09-28 05:28:28 字数 789 浏览 3 评论 0原文


我有一个强名称的 .NET 程序集 PluginHost,它使用 Assembly.LoadFrom() 动态加载插件程序集。它的程序集和文件版本为 1.0.0.0。每个插件程序集都引用 PluginHost,因为在 PluginHost 中定义了一个接口,每个插件都必须实现。

现在,我想部署更新但完全向后兼容的 PluginHost 版本,其程序集和文件版本为 1.0.0.1。但现在旧的插件程序集无法加载,因为它们通过包含版本号的强名称引用 PluginHost。

如何在不破坏旧插件的情况下部署新版本的 PluginHost?

我发现的一种解决方案是将 PluginHost 的 Assembly-version 设置为 1.0,并且即使在更新版本中也将其保持在 1.0。我仅在每次新更新时将文件版本从 1.0.0.0 更改为 1.0.0.1 等。这样旧的插件程序集加载就不会出现问题。 但这是要走的路吗?有更好的办法吗?我认为将程序集版本保留为恒定值是不正确的。

可能感兴趣的其他背景信息:PluginHost 在 VB6 应用程序中与 COM Interop 一起使用。这就是它有一个响亮名字的原因。 PluginHost 和插件都不在 GAC 中。 PluginHost 已使用 RegAsm.exe 注册。

谢谢。

更新

感谢您的回答。由于似乎没有合理的方法将应用程序配置文件与 COM Interop 一起使用,我想我坚持冻结程序集版本,并且仅在新版本的 PluginHost 中更改文件版本。

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 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 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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

溺深海 2024-10-05 05:28:28

我希望我能理解你正在尝试正确做的事情。如果是这样,一种方法是使用 bindingRedirect 元素< /a> 在应用程序配置文件中。有关重定向程序集的详细信息,请参阅 MSDN

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.

我一向站在原地 2024-10-05 05:28:28

我个人将 AssemblyVersion 保留为固定状态,除非我知道我正在进行重大更改。在您的情况下,由于您没有部署到 GAC,因此无论如何您都无法获得并行部署的好处,那么更改 AssemblyVersion 有什么好处呢?

如果您确实必须更新 AssemblyVersion,则有两个选择:

  1. 在使用者的 app.config 文件中添加一个 bindingRedirect 元素。
  2. 使用您的服务器部署发布商策略文件集会。

鉴于您的使用者是 VB,因此排除了使用 app.config。这样您就可以将 PluginHost 部署到 GAC 并使用发布者策略文件。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文