.Net程序集/dll共享和部署

我们有3种软件产品使用相同的.net DLL（代码+传统）。
所有这些都使用3/4 DLL中的通用功能

我想知道如何以及在何处部署这些DLL。
这是最标准的方法

S1]以及安装目录中的每个产品--这可能是最简单的方法。 （但如果要在共享dll中进行任何更新，则必须对所有3个dll进行更新。）

S2]是否将其放入公共文件文件夹

S3]系统GAC对此有帮助吗？
（将所有3个都放在GAC中，代码是共享的。但我担心版本控制？）

另外，如何为此类项目构建可部署的设置：

D1]在一个设置中打包所有DLL。每个设置都有自己的副本。
但是假设有人安装了软件A，那么对于软件B，共享文件已经存在于系统中

D2]在单独的设置中部署常用文件，并将每个文件打包。如果是，请尝试检测文件是否已经存在。不要部署。（这仍然无助于设置大小）
公用文件夹-应该是GAC还是系统上的某个文件夹？ 涉及复杂的设置，因为它需要检查不同共享文件的版本控制

另外，假设要发布较新版本的软件，并且必须与较旧版本共存。

---

如何在多个版本之间保持兼容性？

将所有内容放在应用程序文件夹中。只有当你真的有大量代码要共享，并且不会一直更新时，才加入GAC。

我会选择“S1”+“D1”或“S1”+单击一次；它有利于简单的部署和版本控制，并与ClickOnce部署、xcopy部署、MSI部署、web等兼容。GAC不适合IMO。重新更新；嗯，你会想单独测试/发布它们，不是吗？我在构建服务器上配置了一个级联构建，所以如果我更新一个库dll，它会逐步更新并重建使用该dll的所有内容，然后再更新（在任何人说：是的，它会检测并消除周期之前）

“公共文件夹”方法在dll解析方面存在问题，因此它本身就是一个真正的PITA

---

GAC方法是可行的，但需要做很多不必要的工作，而且保存一些重复的DLL非常痛苦。如果您需要部署到非管理员，这也是一个难题。

GAC是您希望代码确保每个版本只有一个副本的地方。不用担心GAC的版本控制，因为它可以为您存储多个版本的库

---

但一般来说，除非图书馆被大量使用，否则我倾向于同意Ngu的答案，并将它们放在你的应用文件夹中。这也将使部署更加容易。

S1+D1。关于“如果有更新…”：这是一个好处而不是问题。如果更改部件，则必须使用项目重新生成部件。S1场景允许您逐个项目地完成该任务，它们之间没有不必要的依赖关系

---

不要将GAC用于小型库，这是一个麻烦。

如果您的发布计划良好，那么将DLL放在GAC中是一个不错的选择。与此相矛盾的是，如果您添加了任何小功能，然后发布您的产品，那么GAC是完全不可伸缩的，因为这样您就必须并行发布所有产品，我想这是不可能的。此外，GAC还用于存储具有所有使用这些DLL的产品的通用功能的DLL。因此，您必须确定为所有产品提供的功能。为每种产品添加不同的功能并在GAC中存储DLL，这一点都不可取。为此，您必须非常精确地描述您的版本系统和发行版

目前面临的问题包括很少的bug修复和版本控制问题。目前正在使用GAC处理常见文件，并在每个产品中打包所有DLL。部署到GAC令人头痛。哪个应用程序文件夹？这里的问题是，他有3个应用程序都使用相同的DLL…其中一个库相当大…所有许可的东西等，但问题是许可条款不断变化，经常通过。这三种产品。