我刚刚对我的存储库提交了一些代码更改,并且突然之间(经过数周的罚款)。TC 构建开始失败,因为它无法下载 Microsoft.Bcl.Build.1.0.6 的 NuGet 包。
我最终不得不手动将包目录的内容复制到 TC 构建位置,这完全违背了 NuGet 的意义。
我可以检查什么来解决这个问题的根本原因?
在获取包的解决方案中启用了有关 NuGet 的所有内容。
我在http://sedodream.com/2012/12/24/SlowCheetahBuildServerSupportUpdated.aspx上写了一篇关于这个问题的博客。总结 NuGet 包还原(2.7 之前的版本)是作为 MSBuild 构建过程的一部分实现的。当 MSBuild 开始构建时,它将评估项目文件和导入其他文件的任何 Import 声明。这发生在任何目标被执行之前。
由于 NuGet pkg restore 是构建过程的一部分,因此 .targets 文件会在某个时间点恢复,此时 Import 语句无法产生任何影响。
您可以按照您的说明签入 .targets 文件,或者在构建过程之前调用 pkg restore 来解决此问题。我创建了一个 NuGet 包PackageRestore,它可以帮助使用后一种方法。
要使用 PackageRestore,只需将 NuGet 包添加到您的项目中,这将在您的项目目录中自动创建一个名为 packageRestore.proj 的文件。配置构建时,您需要在 .sln/.csproj 文件之前构建该项目。
好的这是一个有点讨厌的问题。
如果你遇到这个问题,你需要对你的存储库做一些相当丑陋的事情。
确保您正在签入packages\repositories.config
文件。
然后,如果您的构建因未解决的对 Microsoft.Bcl.Build 的引用而失败,您还需要签入.targets
此包的文件。例如:
package\Microsoft.Bcl.Build.x.x.x\tools\Microsoft.Bcl.Build.targets
丑陋的...
这篇博文是我所见过的最详尽的解释变通方法选项的博文:
http://blogs.msdn.com/b/dotnet/archive/2013/06/12/nuget-package-restore-issues.aspx
没有一个是伟大的 IMO - 这个问题仍然需要更好的解决方案。
但就目前而言,最好的推荐选项是将 Bcl.Build .targets 文件检查到源代码管理中 - 这意味着当 Bcl.Build 的版本更新时,您需要添加新的 .targets 文件,并删除旧的。
我认为(但不确定,所以我创建了这个 SO 问题:Microsoft.Bcl.Build NuGet 包做什么?)Microsoft.Bcl.Build 仅用于开发,而不需要在构建服务器上。因此,我有一个仅存在于构建环境中的 Builder.targets 文件,它被间接<import>
编入我们所有的项目中,其中包括以下 MSBuild xml:
<!-- Skip Microsoft.Bcl.Build functionality when building only from Source. Presumably Microsoft.BclBuild is only needed for development. -->
<PropertyGroup>
<BclBuildImported>Ignore</BclBuildImported>
</PropertyGroup>
由于 Bcl.Build nuget 包插入到您的项目中的 MSBuild 逻辑块依赖于BclBuildImported
为空的属性,这有效地回避了我的构建环境中的问题 - Microsoft.Bcl.Build 步骤被跳过,它不再中断我的 CI 构建。
请注意,由于此包似乎在您的 app.config 中管理绑定重定向,并确保在您的项目中包含传递依赖项,因此留待开发非常重要。但我目前不知道在构建服务器环境中需要它。