3

由于我们构建/维护的产品数量众多，我们有一个相当复杂的 dll 结构（>100 个程序集）。我们正在安装 TFS 2012。我们目前使用 NuGet 来管理对外部 dll 的引用。

Nuget 似乎可以成为管理我们内部 dll 的解决方案。

这是我们的结构示例：

  • 框架.dll
  • 业务.dll
    • 参考：Framework.dll
  • 业务.X.dll
    • 参考：Framework.dll
    • 参考：Business.dll
  • 应用程序.X.dll
    • 参考：Framework.dll
    • 参考：Business.X.dll
    • 参考：Business.dll

为了使用 NuGet 完成此任务，我为每个程序集创建了一个 nuget 规范/包。然后每个包都包括其依赖包。

  • 框架.1.0.nupkg
  • Business.1.0.nupkg
    • 取决于：框架
  • Business.X.1.0.nupkg
    • 取决于：框架、业务
  • 应用程序.X.1.0.nupkg
    • 取决于：框架、业务、Business.X

1）我创建了Framework VS项目，构建它，并将其打包到Framework.1.0.nupkg 2）我打开了Business VS项目并通过安装Framework.1.0.nupkg添加了对Framework.dll的引用3）然后我构建并将Business VS项目打包为Business.1.0.nupkg 4）我为每个程序集重复了这个过程（仅供参考，我使用NuGetter来自动化这个）

我无法协调本地开发人员机器和构建服务器之间的差异。

以下是我的理解：

  1. 由于 NuGet 的包还原功能，我不需要将最终程序集存储在 TFS 中。
  2. 不是引用程序集，而是使用 NuGet 添加引用。例如，在 Business VS 项目中，框架程序集是从 Nuget Framework.1.0 包中添加的。

但是，这使得程序集开发人员难以构建/测试新功能。开发 Business 和 Business.X 程序集的开发人员应该如何在不删除/读取引用的情况下在本地（在他们自己的机器上）测试功能。这是必要的，因为 Business.X 引用的是打包的 Business，而不是本地构建的 Business.dll。

我的目标：

  1. 使用构建服务器生成版本化的共享程序集
  2. 允许消费者应用程序添加对这些程序集的引用
  3. 允许共享程序集的开发人员在需要服务器构建之前轻松地在本地编译/测试

我认为 Nuget 适用于 #1 和 #2，但我似乎无法完成 #3。有一个更好的方法吗？

感谢您提供任何信息/指针！

4

1 回答 1

0

每个程序集（DLL）一个单独的 NuGet 包是多余的 - 我希望您的大多数内部 NuGet 包包含一组程序集，这些程序集提供了一个基本上独立于其他程序集组的功能“块”。

所以这不是正确的模式：

为了使用 NuGet 完成此任务，我为每个程序集创建了一个 nuget 规范/包。

相反，您可能希望为每个解决方案 (.sln) 创建一个或两个 NuGet 包，假设您的解决方案已合理分组。

于 2013-08-16T20:48:35.843 回答