这是对 GAC 的有效使用吗？
我们有一个大型 winform 应用程序，安装在用户磁盘上。 我们希望第三方能够编写使用我们的一些应用程序功能的应用程序。因此，我们编写了 API.dll，它通过从注册表解析安装目录来与其他一些程序集进行交互。我们将 API.dll 作为 SDK 发送给第三方。对于第三方应用程序的实际部署，有几个选项：
它们“复制本地”API.dll 并随其一起发布。缺点：我们无法在 API.dll 中进行更改（当然不会破坏），因为客户应用程序已复制它。如果我们更改它交互的其他程序集（我们可能会这样做），我们可能需要更改它。
第三方不附带 API.dll，但我们将 API.dll 放在 GAC 中。缺点：GAC 和签名的麻烦。
与 #1 相同，但 API.dll 只有抽象 + 一个工厂来从我们的 /bin 加载它们。缺点：结果可能并不总是微不足道的，有些工作。
我不喜欢 GAC，并试图避免它，但团队中的一些人喜欢它，并且这里有一个观点。你怎么认为？
We have a big winform application which we install on the users disk.
We want third parties to be able to write applications that use some of our app capabilities. So we have written API.dll which interacts with some of the others assemblies by resolving the installation dir from the registry. We send API.dll to third parties as an SDK. There are a few options as for how an actual deployment of a third party app will look like:
They "copy local" API.dll and ship with it. Cons: We cannot make a change (non breaking of course) in API.dll since customer apps have it copied. We might need to change it if we change other assemblies it interacts is (which we will probably).
Third parties don't ship with API.dll but instead we put API.dll in GAC. Cons: the hussle of GAC, signing.
same as #1 but API.dll only has abstractions + a factory to load them from our /bin. Cons: may not always turn out trivial, some work.
I don't like the GAC and try to avoid it but some people in the team do and have a point here. What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，作为潜在客户，我会不惜一切代价避开 GAC。
关于第一点，我认为您的客户应用程序（和开发团队）更有可能在自己的闲暇和测试周期部署您的更新，而不是依赖您的更新。这样他们就会在准备好时接受您的更新 - 如果他们已经规避了您刚刚修复的“错误”怎么办？
关于第 2 点，除了您自己的文档中显示的约定之外，您将很难让每个人实际使用此机制。当然，无论如何，我仍然总是使用第三方程序集的本地复制部署。
关于第 3 点，你可以这样做......但这可能会惹恼你的客户。如果您要付出如此巨大的努力来保持第三方供应商软件的更新，也许您应该质疑您是否发布了您的库有点太早了。
另外，从您的角度来看，我宁愿保留进行重大更改的权利（当然还要记录下来）。如果您的升级模型不允许您正确重构和弃用旧代码，那么您将很难让您的产品变得更好。
我的两分钱。
In general, and as a potential customer, I would avoid the GAC at all costs.
Regarding point 1, I think your customer apps (and dev teams) would more likely rather deploy your updates at their own leisure and testing cycles rather than relying on yours. That way they take your updates when their ready - what if they've already circumvented the "bug" that you just fixed?
Regarding point 2, you'll have a tough time getting everyone to actually use this mechanism except by the convention shown in your own docs. Certainly, I'd still always use copy-local deployments of third party assemblies anyway.
Regarding point 3, you could do this... But it might annoy your customers. If you are going to such large efforts to keep third party vendor software updated perhaps you should question whether you've released your library a little too soon.
Plus from your perspective, I would rather reserve the right to make a breaking change (and document it of course). If your upgrade model doesn't allow you to properly refactor and deprecate old code then you're going to have a tough time making your product better.
My two cents.