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

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

  •  1
  • Eoin Campbell  · 技术社区  · 12 年前

    上有很多信息/博客/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 回复  |  直到 12 年前
        1
  •  2
  •   Hans Passant    12 年前

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

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

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