更新 GAC 中的 DLL

发布于 2024-09-16 02:06:43 字数 364 浏览 3 评论 0原文

我有一个 API DLL,多个第三方应用程序引用了它。

其中一些应用程序需要两种方式进行更新。

  1. 我想要最新的东西
  2. 不要经常更新我的直接二进制文件

曾经考虑过将 DLL 移动到 GAC 中并编写另一个 DLL,它只是 GAC 中 DLL 的包装器(然后第 3 方应用程序将引用它) )。这允许在 GAC 中更新业务逻辑(经常更改的部分),并且仅在新功能可用时才需要更新包装器 DLL。

GAC 旨在保留版本化的 DLL。因此,包装器 DLL 将引用特定版本的 API DLL。更新 GAC DLL 以便对其的引用不会中断但二进制内容不同有多困难?

这就像更新时不更改 GAC DLL 版本那么简单吗?

I have an API DLL that several third party applications reference.

Some of these applications want things two ways in terms of updates.

  1. I want the latest stuff
  2. Don't update my direct binaries that often

There has been the thought of moving the DLL into the GAC and writing another DLL that is simply the wrapper for the DLL in the GAC (which the 3rd party apps would then reference). This allows the business logic (the part that would change frequently) to be updated in the GAC and the wrapper DLL would only need to be updated when new functions were made available.

The GAC is intended to keep versioned DLLs. So the wrapper DLL would have a reference to a specific version of the API DLL. How difficult is it to update the GAC DLL so that the references to it don't break but the binary contents differs?

Is this as simple as not changing GAC DLL versions when updating?

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

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

发布评论

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

评论(4

白云悠悠 2024-09-23 02:06:43

更新 GAC DLL 以便对其的引用不会中断但二进制内容不同有多困难?

你不能直接这样做。您只能将签名的 DLL 放入 GAC 中。当您针对签名的 DLL 构建应用程序时,编译器会获取 DLL 内容的哈希值并将其放入应用程序中。当 .NET 运行时加载应用程序时,它会根据 DLL 的真实副本检查此哈希值。如果此 DLL 与您构建的 DLL 不匹配,.NET 将引发异常。

解决此问题的方法是:

  1. 为 GAC DLL 制定版本编号方案。这可以像在构建时总是增加版本号一样简单。
  2. 在您的 app.config 中,添加 元素

实际上,绑定重定向表示“如果您正在寻找版本号在 1.x 到 1.y 范围内的 DLL,请改为查看版本 1.z”。

编辑:方法绕过 .NET 强名称完整性检查,但我建议在尝试规避它之前围绕标准强名称机制设计应用程序。

How difficult is it to update the GAC DLL so that the references to it don't break but the binary contents differs?

You can't do it directly. You can only put signed DLLs into the GAC. When you build your app against a signed DLL, the compiler takes a hash of the contents of the DLL and puts it in the app. When the .NET runtime loads the app, it checks this hash against the real copy of the DLL. If this DLL doesn't match the one you built with, .NET throws an exception.

The way to work around this is to:

  1. Put in place a version numbering scheme for your GAC DLL. This can be as straightforward as always incrementing the version number when you do a build.
  2. In your app.config, add a <bindingRedirect> element

In effect a binding redirect says, "if you're looking for a DLL with version numbers in the range 1.x to 1.y, look at version 1.z instead".

Edit: There are ways round the .NET strong name integrity check, but I recommend designing your application around the standard strong name mechanism before trying to circumvent it.

燕归巢 2024-09-23 02:06:43

您可以创建更新的程序集,对其进行签名并将其推送到 GAC,以便引用此程序集的应用程序不会注意到差异。您需要指定版本号的所有部分(即,AasemblyInfo.cs 文件中的版本号为 1.2.3.4 而不是 1.2.3.*)并使用相同的 sn 密钥。那么特定于版本的引用就不会被破坏。您将能够根据需要更新 DLL。

You can create an updated assembly, sign it and push it to the GAC so that the applications, which reference this assembly, won't notice the difference. You need to specify all parts of the version number (i.e. have the version number as 1.2.3.4 and not 1.2.3.* in AasemblyInfo.cs file) and use the same sn key. Then the version-specific reference won't be broken. And you'll be able to update your DLL as you need.

久隐师 2024-09-23 02:06:43

我使用 Windows Installer 将程序集部署到 GAC。从服务的角度来看,了解以下之间的区别很重要:

[AssemblyVersion]

[AssemblyFileVersion]

前者被视为强名称合同/绑定的一部分,而后者则不是。此外,Windows Installer 在决定升级期间是否覆盖文件时会考虑后者。

底线:如果对程序集的更改不会破坏接口或导致任何行为回归,则可以保持 AssemblyVersion 相同并增加 AssemblyFileVersion 并重新部署。

这就是 .NET Framework Service Pack 的工作方式,因为 Microsoft 必须能够在不破坏具有现有 SN 引用的应用程序的情况下为基类库提供服务。

I use Windows Installer to deploy my assemblies to the GAC. From a servicing perspective it's important to understand the difference between:

[AssemblyVersion]

and

[AssemblyFileVersion]

The former is considered as part of the strong name contract / binding while the latter is not. Additionally the latter is considered by Windows Installer in terms of deciding to overwrite the file or not during an upgrade.

Botton line: If your changes to the assembly doesn't break interfaces or cause any behavior regressions, you can keep the AssemblyVersion the same and increment AssemblyFileVersion and redeploy.

This is how .NET Framework Service Packs work as Microsoft has to be able to service the base class libraries without breaking applications that have existing SN references.

泪意 2024-09-23 02:06:43

引用可以包括版本信息或引用任何可用版本。这是由引用您的 DLL 的应用程序的作者决定的。当然,您可以将更新后的 DLL 发送为与 GAC 中具有相同版本的版本,但版本控制的全部目的是让各方正确处理更新。因此,您可能需要完善您的任务。

References can include version information or reference whatever version is available. This is determined by the author of the application that references your DLL. Of course, you can ship your updated DLL as having the same version as in the GAC, but the whole point of versioning stuff is to let all parties handle updates correctly. So you might need to refine your task.

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