我有一个自定义构建过程，它使用NAnt，Maven Ivy，CruiseControl.Net和其他一些组合来管理依赖项并处理项目的持续集成构建过程。诚然，它很有效。
对我们来说，一个相对重要的部分是，我们能够从我们的共享Ivy存储库中获取任何给定依赖项（.dll，.xml .whatever）的确切版本对我们的工作绝对至关重要。因不同的原因/目的而需要不同版本的特定库的不同应用程序。
然而 - 我目前正在研究Visual Studio团队服务（http://visualstudio.com）并正在尝试我的代码签入/自动构建过程，除了我无法看到我在哪里或如何管理我的外部/第三方依赖。
使用Maven的常春藤依赖管理/配置工具，这个过程非常完美无瑕，并且对它充满信心 - 团队服务与此相当于什么？
我在网上经过数小时的搜索后得到的最佳结果似乎建议将NuGet用于此，并为每个依赖项制作自定义程序包，然后由Team Services持续集成构建过程存储和访问这些程序包的位置/方式？我可以将我的包存储在Azure中的NuGet服务器中吗？我可以确定这只是我自己使用的吗？
到目前为止我发现的最好的SO帖子是：
...但是这些仍然没有得到答案，也许我正好偏离这一点，但需要了解TFS将遵循的依赖管理流程。
答案 0 :(得分：2)
很多人只是将他们的依赖关系签入他们的TFS源代码库（lib文件夹中的二进制文件）。
更好的方法是使用您建议的包管理器。在.Net世界中最常用的是NuGet。你有正确的想法，TFS Build只会与任何可以在任何地方托管的NuGet服务器进行对话。阅读此博客文章了解更多详情：http://blogs.msdn.com/b/dotnet/archive/2013/08/27/nuget-package-restore-with-team-foundation-build.aspx
答案 1 :(得分：1)
TFS和Visual Studio没有内置的依赖管理工具，如Maven Ivy。 NuGet确实是你得到的最接近的，但它都是在解决方案级别配置并检查到源代码控制。您甚至需要运行自己的NuGet服务器，因为TFS不附带一个（除非您想将它们推送到公共存储库，这通常是您不想要的）。
有许多第三方解决方案，但开箱即用的功能简单归结为：
.12.xaml版本非常简单直接，但您可以更改模板以执行您想要的任何操作。从任何地方获取特定的依赖关系当然可以是其中一个选项。如果您愿意，也可以将Build Process模板集成到Maven Ivy中。至于第三方选项，TeamCity被提及，虽然它增加了一个NuGet服务器，这很容易自己托管。和其他人一样，但讨论哪个第三方解决方案可能比其他解决方案更好是针对StackOverflow策略。
答案 2 :(得分：0)
一个可能的答案可能是TeamCity：
将TeamCity用作NuGet服务器
如果由于某种原因你不想 将包发布到公共Feed，例如你正在生产包裹 旨在内部使用;您可以将TeamCity用作本机 NuGet Server而不是设置您自己的存储库。开始使用 TeamCity作为NuGet Server，您需要启用TeamCity服务器 通过单击Administration |中的相应按钮来NuGet服务器 NuGet设置| NuGet Server页面。将有两个不同的链接 显示在同一页面上：for public（带有guestAuth前缀）和 private（带有httpAuth前缀）feed。如果公共网址不可用， 您需要在管理中启用TeamCity中的Guest用户登录 |全局设置页面。
我不能说我已经使用过它，但这可能会帮助你解决问题。
答案 3 :(得分：0)
是的，您应该使用包管理器来管理内部依赖项。我们使用Nuget作为包管理器，并为我们的内部依赖项提供内部Nuget服务器，但我很确定你可以在azure上托管它。我们的CI版本会在运行时自动下载软件包，这应该不是问题。 @dylan提到的链接是用于此的链接。
我没有使用它，但你也可以看看ProGet，它基本上是Nuget for Enterprise。