项目引用 v NuGet 依赖项答案

【问题标题】：Project references v NuGet dependencies项目引用 v NuGet 依赖项
【发布时间】：2013-06-03 04:23:57
【问题描述】：

我正在将 NuGet 引入我们的软件开发流程，既适用于外部二进制文件（例如 Moq、NUnit），也适用于包含共享功能的内部库项目。

TeamCity 正在从我们的内部库项目中生成 NuGet 包，并将它们发布到本地存储库。我修改后的解决方案文件使用本地存储库来访问 NuGet 包。

考虑以下源代码解决方案：

Company.Interfaces.sln 构建 Company.Interfaces.1.2.3.7654.nupkg。
Company.Common.sln 包含通过其 NuGet 包对 Company.Interfaces 的引用，并使用 Company.Interfaces.1.2 构建 Company.Common.1.1.1.7655.nupkg。 3.7654 作为依赖项包含在内。
Company.DataAccess.sln 使用 Company.Common nupkg 添加 Company.Interfaces 和 Company.Common 作为参考。它建立 Company.DataAccess.1.0.8.7660.nupkg，包括 Company.Common.1.1.1.7655 作为依赖组件。
Company.Product.A 是一个网站解决方案，其中包含对所有三个库项目的引用（通过选择 Company.DataAccess NuGet 包）。

问题：

如果 Company.Interfaces 的源代码发生更改，我是否总是需要重新编号和重建中间包（Company.Common 和 Company.DataAccess）并更新 Company.Product.A 中的包？

或者这取决于源代码是否更改

实际上，我有 8 个级别的依赖库包。是否有工具支持更新整个包树，是否有必要？

我知道语义版本控制。

我们正在使用 VS2012、C#4.0、TeamCity 7.1.5。

【问题讨论】：

【解决方案1】：

最好在每次签到时更新所有内容，以便及早进行测试。

您所描述的内容可以使用工件依赖项 (http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies) 和“完成构建”构建触发器（甚至单独使用“Nuget 依赖触发器”）轻松管理。

【讨论】：

【解决方案2】：

我们在基础项目（在本例中为 Company.Interfaces.sln）编写了自己的构建配置，它一次性构建和更新整个树。它会一路检查更新的 packages.config 文件和 .nuspec 文件。我不能说这最终为我们节省了多少时间，即使一开始听起来有点矫枉过正。

需要注意的一点：我们编写的脚本会检查文件，即使链在两者之间的某处发生故障，以便我们有机会在本地计算机上修复它，检查修复并重新启动发布。

【讨论】：

你的意思是这样的吗？ candordeveloper.com/2012/12/12/…
不幸的是，我们的 NuSpec 文件仍然是手工编辑的，其中包含一些用于自动版本替换的宏。我的意思是自动触发依赖构建配置，更新 NuGet 包，签入生成的更改（通常是 .csproj 和 packages.config 文件）并继续链直到叶项目。