2

我负责开发和维护一组用于构建我们的产品应用程序的通用框架程序集。这些组件相对较新,并且随着新功能的实现等而处于不断变化的状态。因此,它们经常被重建和重新分配并不罕见。我希望随着大会的稳定,这种情况会减少,但这就是今天的情况。

现在,这些程序集被放置在一个 Common 文件夹中,开发项目可以在其中引用相同的程序集。应用更新就像替换文件一样简单,开发项目会在下次加载和构建时自动获取更改。

我遇到的问题是我们可能有几个构建在框架上的程序集“层”——例如,我们有一个由所有应用程序共享的核心库和一个引用核心并由所有服务器应用程序共享的服务器库。每次更新框架程序集时,还必须重新构建所有依赖项,这使得这是一项非常庞大的任务。我不相信我可以使用 GAC,因为这将要求所有开发人员在每次发布新版本时更新他们的系统。

我调查了发布商政策,但出于以下几个原因,我怀疑这是否能解决我的问题:

  • 一方面,我不想在每次重建框架程序集时都重新创建文件——有没有办法让这个过程自动化?

  • 我不清楚它是否要求程序集进入 GAC。正如我所说,我不想在每次发布新版本的程序集时强迫我的开发人员重新安装、更新等。

  • 我对网络设置和配置没有任何控制权,因此有必要通过将文件放在网络共享中来避免整个“信任”问题。此外,我们的许多开发人员以有时连接的方式工作,我们希望文件在断开连接时可供他们使用。

目标是使更新这些程序集对我们正在使用它们的应用程序开发人员透明。毫无疑问,我们会在安装应用程序时将这些程序集安装到目标机器上的 GAC 中,但出于开发目的,我们不想这样做。将项目包含在每个应用程序的解决方案中也是不合理的,因为它们是由不同的团队开发的。

我无法想象只有我一个人在这些要求中,希望有人可以分享他们的经验和智慧来指导我找到解决方案。谢谢!

4

2 回答 2

1

您不一定需要将程序集安装到 GAC 中 - 您的设置中不需要这样做。

这里的主要问题是确保程序集强制重建其所有依赖项,并且所有这些依赖项都放置在共享位置。

这里最简单的选择可能是拥有一个构建服务器,只要其中一个共享程序集被更新,它就会重新构建所有内容。这还具有潜在地在构建上运行其他“脚本”的优势,例如在签入构建时执行代码度量、静态代码分析等。

然后,您可以让构建服务器将所有内容复制到共享位置。如果项目从共享位置引用,并明确表示不限于特定版本,那么一切都应该正常工作。

于 2009-09-14T17:33:22.603 回答
0

NuGet 解决了这个问题。通过将共享程序集、框架等作为 NuGet 包从我们网络上的私有存储库分发,我们可以轻松发布更新并将它们适当地应用于客户端代码。

于 2011-11-17T15:18:18.383 回答