1

有大量关于在部署/发布方案中不使用 GACUtil的信息/博客/msdn 文章，并且 MSI 或其他 Windows 安装程序技术是更好的选择。

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

我们有许多强命名并从 GAC 引用的 DLL。为了使开发团队保持同步，一旦生成了支持 GAC 的 DLL 的新版本，它就会自动添加到所有其他开发人员 GAC 中，作为他们日常主干检查的一部分。工作流程类似于：

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

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

我们是否应该寻找比 GACUtil & Scripts 更强大的东西来管理它？

一个考虑是我们自己在 powershell 中滚动一些东西来检查程序集类型并将程序集添加到正确的 GAC。有人做过吗？

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

4

1 回答 1

2

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

在开发过程中使用它当然不受欢迎。大多数情况下，您会使用包含相关项目的解决方案，这样您就可以自动获得具有本地部署的最新版本，而无需 GAC。这在一定程度上很好，当解决方案变得太大时，构建时间可能需要开始分发剑。

在那之后没有什么神奇的解决方案，GAC 肯定有助于再次缩短构建时间。一般来说，基础组件的流失应该从负 1000 分开始，它们会引起很多痛苦。仅将它们保存起来，例如每周发布更新。顺便说一句，还需要将所有这些东西正确安装在客户端机器上。如果还没有人专注于这一点，也许现在是巩固这一点的好时机。当每个人都使用它在他们的机器上获取他们需要的程序集时，它会自动得到调试。

于 2012-08-13T18:51:23.933 回答