当单个解决方案撤回时，使用共享DLL的多个解决方案可能会造成破坏

Question

问题： 当单个解决方案撤回时，使用共享DLL的多个解决方案可能会造成破坏。

例子： 您拥有所有Web零件代码使用的Web部件助手DLL。如果您撤回包含对此DLL的引用的解决方案，则将SafeControl条目从适当的Web应用程序中删除，并且您的所有Web零件都开始失败。甚至更好，将DLL完全从GAC中删除。

解决方案： 我不知道？你告诉我。

Answer 1

当您拥有常见/共享组件（例如您谈论的助手DLL）时，这些组件会在组织内部的多个解决方案中使用。我的建议是将它们作为“框架解决方案”包装，该解决方案被部署到服务器的“基于功能的解决方案”。

这样，您就会开发“特征解决方案”，以了解“框架”始终可用。

SharePoint始终会缩回/删除您在解决方案软件包中添加的内容，而不可避免的是它没有内置的任何内容来检测共享组件。

Answer 2

我使用的方法是 使用ilmerge合并所有组件 作为构建的一部分，包装之前

这使得它的防弹是不可能让某人以某种方式删除依赖的组件。

Answer 3

是的，这是SharePoint部署中的常见问题。我的解决方案是更改助手DLL-S的版本号。因此，即使您在GAC中有多个助手DLL-S，也不应该是一个大问题。小费：解决方案

Answer 4

我们将每个共享组件分配给一个WSP文件。然后，我们使用功能依赖项来描述任何人是否正在使用共享组件，并具有以下规则：如果任何活动功能取决于它，则无法卸载共享依赖项。

困难在于说服每个人遵守规则。

团队倾向于将组件复制到自己的WSP文件中，或者在不关注规则的情况下卸载其部署的任何WSP文件。