.Net程序集/dll共享和部署
我们有 3 个软件产品使用相同的 .net dll（代码 + 旧版）。
所有这些都使用 3/4 dll 中存在的通用功能。
我想知道如何以及在哪里部署这些 dll。
这是最标准的方法。
S1] 连同其安装目录中的每个产品 - 可能是最简单的方法。 （但是如果共享 dll 中发生任何更新..必须对所有 3 个 dll 进行更新。）
S2]将其放在公共文件夹中吗？
S3] System GAC 对此有帮助吗？
（将所有 3 个放入 GAC 中，代码是共享的。但我担心版本控制？）
另外，如何为此类项目构建可部署的设置：
D1]将所有 dll 打包在一个设置中。每个设置都有自己的副本。
但假设如果有人安装了软件 A，那么对于软件 B，共享文件已经存在于系统中。
D2]在单独的设置中部署常用文件并打包。尝试检测文件是否已经存在，如果是则不部署。（这仍然对设置大小没有帮助）
公共文件夹 - 应该是 GAC 还是系统上的某个文件夹？ 涉及复杂的设置，因为它需要检查不同共享文件的版本控制。
还假设如果要发布软件的新版本并且它必须与旧版本共存..
如何保持多个版本的兼容性？
We have 3 software products which use the same .net dlls(code + legacy).
All these use common functionality present across 3/4 dlls.
i wanted to know how and where to deploy these dlls.
And which is the most standard way of doing this.
S1] Along with each product in its install dir -- probably easiest way to do.
(but if any updates are to happen in the shared dll ..it has to be done for all 3 dlls.)
S2]Put it in common files folder?
S3] Does System GAC help in this?
(Put all 3 in GAC and the code is shared.but im worried about versioning?)
Also how to build a deployable setup for such projects:
D1]pack all dlls in one setup.each setup has its own copy.
but suppose if someone installs software A, then for software B the shared files are already present in the system.
D2]deploy common files in a separate setup and pack with each.try to detect if files are already present if yes dont deploy.(this still doesnt help setup size)
Common folder - should it be GAC or some folder on system?
Involves complex setup as it will require check versioning of different shared files.
Also suppose if newer version of the software is to be released and it has to coexist with older version..
how to maintain compatabilty across multiple versions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
S1 + D1 当然。关于“如果有更新……”：这是一个好处而不是一个问题。如果更改程序集，则必须重建使用的项目。 S1 场景允许您逐个项目地执行此操作，它们之间没有不必要的依赖关系。
小型图书馆不要使用GAC，这很麻烦。
S1 + D1 for sure. About the "if any updates..." : this is a benefit rather than a problem. If you change an assembly you will have to rebuild the using projects. The S1 scenario lets you do that project-by-project, no unneeded dependencies between them.
Do not use the GAC for small libraries, and it is a hassle.
如果您的发布计划良好，那么将 dll 放入 GAC 中是一个不错的选择。与此事实相反，如果您添加任何小功能，然后发布您的产品，那么 GAC 根本无法扩展，因为您必须并行发布所有产品，我认为这是不可能的。此外，GAC 用于存储具有通用功能的 dll，适用于使用这些 dll 的所有产品。因此，您必须确定为所有产品提供的功能。为每个产品添加不同的功能并将 dll 存储在 GAC 中是完全不可取的。为此，您必须非常精确地了解您的版本系统和版本。
If your releases are well planned then putting dlls in GAC is a good option. Contradictory to this fact, if you are adding any small feature and then releasing your product, then GAC is not at all scalable because then you have to make parallel releases of all your products, which I guess not possible. Also, GAC is used to store dlls having common functionality for all the products which are making use of these dlls. So you have to be sure about the functionality you are providing for all the products. This is not at all advisable to add different functionality for every product and storing dlls in GAC. For this you have to be very precise about your version system and releases.
我会选择“S1”+“D1”，或“S1”+ClickOnce；它使部署和版本控制变得简单，并且与 ClickOnce 部署、xcopy 部署、MSI 部署、Web 等兼容。在我看来，GAC 不合适。重新更新；好吧，您会想单独测试/发布它们，不是吗？我在构建服务器上配置了级联构建，因此，如果我更新库 dll，它会向上流动并重建使用该 dll 的所有内容（在有人说之前：是的，它会检测并消除循环）。
“公共文件夹”方法存在 dll 解析问题，因此它本身就是一个真正的 PITA。
GAC 方法可行，但需要大量不必要的工作，并且保存一些重复的 dll 非常痛苦。如果您需要部署到非管理员，这也是一件痛苦的事情。
I would go "S1"+"D1", or "S1"+ClickOnce; it makes for simple deployment and versioning, and is compatible with ClickOnce deployment, xcopy deployment, MSI deployment, web, etc. GAC is not appropriate IMO. Re updates; well, you'll want to test/release them individually, no? I have a cascading build configured on my build server, so if I update a library dll it trickles up and rebuilds everything that uses that dll, and upwards (before anyone says: yes, it detects and eliminates cycles).
The "common folder" approach has issues with dll resolution, so by itself is a real PITA.
The GAC approach would work, but is lots of unnecessary effort, and pretty painful to save a few duplicated dlls. It is also a pain if you need to deploy to a non-admin.
将所有内容放入您的应用程序文件夹中。仅当您确实有大量代码需要共享且不会一直更新时才放入 GAC。
Put everything in your application folder. Putting in GAC only if you really have a large number of code to share, and doesn't update all the time.
GAC 是您希望代码所在的地方，以确保每个版本只有一份副本。不必担心 GAC 的版本控制，因为它可以为您存储多个版本的库。
但一般来说，除非该库将被大量使用，否则我倾向于同意 Ngu 的答案并将它们放入您的应用程序文件夹中。这也将使部署变得更加容易。
The GAC is the place you want the code to ensure that there is only one copy of each version. Don't worry about versioning with the GAC because it handles storing multiple versions of libraries for you.
But generally unless the library is going to be used a lot I would tend to agree with Ngu's answer and put them in your application folder. This will make deployment a fair bit easier too.