画地为牢的NuGet库构建

期间，我们在那里，因为他们的测试和评估各种α-包的情况并不少见他们的工作区中开发设置本地资源库的环境中工作。通常情况下，他们的nuget.configs会与他们的代码更改一起检查，这些更改会破坏我们的CI构建。更糟糕的是，当这样的构建被提交到黄金构建服务器时，它会产生更多的问题，因为构建会在那里破坏，或者如果开发人员使用黄金构建服务器可见的仓库，alpha包将包含在黄金构建中。画地为牢的NuGet库构建

有没有把在部队的NuGet忽略一个比％APPDATA％以外的任何配置文件的替代办法？或者可以有一种方法来定制NuGEt电动工具包中的msbuild目标来实现这个目标？

我们致力于TFS 2010和VS 2010/2012环境，并且可以修改默认构建工作流程，以便在构建过程中可能需要进行任何自定义设置。

来源

2013-01-13 Nikhil

你最好的解决办法是停止使用的NuGet。 nuget客户端工具不是为可靠的构建环境而设计的。 –

是什么让你说Greg？ – Nikhil

因为工具只是不适合非平凡或多个人项目的工作：http://www.postsharp.net/blog/post/Done28099t-let-NuGet-break-your-build-with-the-upcoming -PostSharp-3-release.aspx和https://www.simple-talk.com/dotnet/.net-framework/taking-nuget-to-the-enterprise/。对于一个任意的第三方（或许你甚至没有意识到你依赖于某个人）来打破你是太容易了。 Nuget的基本设计不是为您创建一个稳定的依赖关系平台。（如果你犯了我犯的错误，上帝会帮助你，打开Package Restore。） –

有点晚了这里的聚会，但希望它是使用的人的...

我已经在类似的环境工作，来解决这个问题，我们增加了一个本地存储库（如c：\本地软件包）除nuget.config外，还有远程共享的（包括构建服务器）。这个本地存储库可以被任何开发者用来添加他们正在处理的（或者想测试的）软件包。

这意味着nuget.config文件永远不会需要改变。尽管如此，这并没有完全解决问题，因为开发人员可以提交引用从本地存储库安装的软件包（通常会破坏构建）的项目文件。为了解决这个问题，我们必须改变我们的代码审查过程来检查这个实例。

来源

2014-01-28 13:02:39 CarllDev

按照documentation，你应该能够通过明确指定他们限制的存储库。以下仅应使官方包源代码处于活动状态。

<packageSources> 
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" /> 
    <add key="TestSource" value="C:\Temp" /> 
</packageSources> 
<disabledPackageSources /> 
<activePackageSource> 
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" /> 
</activePackageSource>

来源

2014-06-24 07:59:37 bloudraak

您可以：

禁用的NuGet在您的解决方案通过启用的NuGet还原源控制集成。
为您的构建使用一个MsBuild proj文件，并添加一个预构建阶段，从给定源代码列表中恢复解决方案中的包。 nuget.org +内部稳定的NuGet软件包源码（command line reference）。如果始终有一个版本至少高于packages.config文件中列出的预发布版本，这应该可以工作。

来源

2014-08-05 22:57:45

画地为牢的NuGet库构建

回答

相关问题