在您的编码/ svn /开发工作流程中使用GACUtil被认为是不良实践？

Question

在 部署 / <中使用GACUtil， NOT 上有大量的信息/博客/ msdn文章em> 发布 方案，MSI或其他Windows安装程序技术是一个更好的选择。

但是，在 开发 工作流程中使用GACUtil仍然是合适的。

我们有许多名为＆amp;强大的DLL。从GAC引用。为了使开发团队保持同步，一旦生成了新版本的GAC-able DLL，它就会自动添加到所有其他开发人员GAC中，作为其每日中继检查的一部分。工作流程如下：

• 开发人员对我们的一个GAC程序集进行更改，在本地测试，一旦签名，编译DLL的发行版本
• 从\ Project_DIR \ bin \ Release * .dll - ＆gt;复制发布版本\ COMPANY_GAC \当前* .DLL
• 其他开发人员运行我们的源代码管理检出批处理脚本：
  • 查看最新版本的COMPANY_GAC \ Current * .dll
  • 在每个DLL上运行GacUtil.exe

到目前为止，这对我们有用，但是它变得更复杂了：   - 更大的团队，更严格的GAC变更管理。   - CLR2.0＆amp; CLR4.0编译了需要不同版本GACUtil.exe的Company_Gac程序集   - 在具有多个功能分支的构建/集成服务器上管理程序集（因此必须热交换不同的GAC Dll）

我们是否应该关注更强大的GACUtil＆amp;脚本来管理这个？

一个考虑因素是在powershell中使用自己的东西来检查程序集类型并将程序集添加到正确的GAC中。有没有人这样做过？

欢迎任何有关开发人员如何管理其GAC工作流程的其他建议。

Answer 1

在部署期间不使用gacutil.exe很简单：它在目标计算机上不可用，因为它是Windows SDK实用程序，并且它不是可重新分发的组件。

在开发过程中使用它当然不受欢迎。最常见的是，您将使用包含相关项目的解决方案，以便您可以使用本地部署自动获取最新版本，而无需GAC。这很顺利，构建时间可能需要在解决方案变得太大时开始分发剑。

在此之后没有神奇的解决方案，GAC肯定有助于再次缩短构建时间。一般来说，基础组件中的搅动应该从零下1000点开始，它们会引起很多痛苦。仅保留它们，例如每周发布更新。另外，还有核心需要将所有这些东西正确安装在客户端机器上。如果没有人专注于此，也许现在是获得这种可靠性的好时机。当每个人都使用它来获取他们所需的程序集时，会自动调试。