代码之家 › 专栏 › 技术社区 › Eoin Campbell

在您的编码/svn/开发工作流程中使用GACUtil是否被视为不良做法?

gacutil gac .net-4.0 version-control

1

Eoin Campbell · 技术社区 · 13 年前

上有很多信息/博客/msdn文章不是使用GACUtil 部署 / 释放以及MSI或其他windows安装程序技术是一个更好的选择。

然而,在您的发展工作流程。

我们有许多强名称的DLL&引用自GAC。为了保持开发团队的同步,一旦生成了GAC able DLL的新版本,它就会自动添加到GAC的所有其他开发人员中,作为他们日常干线检查的一部分。工作流类似于:

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

到目前为止,这一直对我们有效,但它变得有点复杂: -团队规模越大,对广汽变革的管理就越严格。 -CLR2.0&CLR4.0编译的Company_Gac程序集需要不同版本的GACUtil.exe -管理具有多个功能分支的生成/集成服务器上的程序集(因此必须热交换不同的GAC DLL)

我们是否应该考虑更稳健的GACUtil&管理这个的脚本?

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

欢迎就开发人员如何管理他们的GAC工作流程提出任何其他建议。

1 回复 | 直到 13 年前

1

2

Hans Passant 13 年前

在部署期间不使用gautil.exe很容易:它在目标计算机上不可用,因为它是一个Windows SDK实用程序,并且不是可重新分发的组件。

在开发过程中使用它当然不受欢迎。最常见的情况是,您会使用包含依赖项目的解决方案,这样您就可以通过本地部署自动获得最新版本,而不需要GAC。在某种程度上,当解决方案变得过于庞大时,构建时间可能需要开始分发剑。

在这一点之后,没有任何神奇的解决方案,广汽无疑有助于再次缩短建造时间。一般来说,基础组件中的搅拌应该从负1000点开始,这可能会造成很大的痛苦。把它们保存起来,只用于每周发布更新。此外,还需要将所有这些东西正确安装在客户端机器上。如果还没有人关注这一点,也许现在是一个巩固这一点的好时机。当每个人都使用它在自己的机器上获得所需的程序集时,它会自动进行调试。