我正在尝试将持续集成实施到我们的日常工作中。在我们的团队中，我们正在从仅仅在我们的工作站上的 Visual Studio 中构建我们的代码并进行部署，到使用 MSBuild.exe 并在我们的构建服务器（即 Jenkins）上自动化而不使用 Visual Studio。
在我们的项目中，我们对引用（例如 Automap）有外部依赖关系。因为自动映射（例如）dll 不在构建服务器上，所以 msbuild 执行失败，原因很明显。还有其他 dll 我需要成为构建的一部分，我只是使用 automap 作为示例。
那么，作为自动构建的一部分，在构建服务器上获取任何依赖项的最佳方式是什么？我已经看到对使用“lib”文件夹的引用，但我真的不明白我应该把它放在哪里（在我的项目、文件系统、SVN ...？），以及构建服务器将如何到达它。我还读到 NuGet 可以对依赖项做一些事情，但是我的构建服务器没有连接到互联网，我不明白如何让我的构建拉取我可能创建的 NuGet 包，以及它是如何实现的一起工作。
编辑：我正在使用颠覆，我们不能使用 TeamCity，因为我们必须购买它，而且获得资金的机会为零。
我们运行 SVN + CCNet。我们有一个用于 3rd 方库的 SVN 存储库，如下所示：
/foo/foo-1.2.3
/foo/foo-1.4.0
/bar/bar-1.0.0
也就是说，每个库都有一个目录，每个可用版本都有子目录。
一条规则是目录必须包含原始库 - 即您解压缩并提交，不允许修改。
当您在项目中需要一个库时，您可以添加一个 lib 目录并在其中填充指向第 3 方存储库中的库的链接 (svn:externals)。这里重要的是，您不要在本地目录名称中包含版本号。如果您需要 foo-1.4.0，您的 lib 目录上的 svn:externals 链接将如下所示：
foo https://svn-server/3rdparty/foo/foo-1.4.0
即它最终在/lib/foo 中。这样升级版本就变得容易多了，因为您所要做的就是更改 svn:externals 链接以指向新版本，并且（只要文件名没有更改）所有项目都会自动获取它并可以编译.
至于 NuGet .. 麻烦多于其价值，但意见不同 :)
希望有帮助
我喜欢 stmax 的解决方案，但在这一点上对你来说可能工作量太大了。
最简单的做法是在您的存储库中创建一个 lib 目录并将所有第三方程序集添加到该目录。 更新您的所有项目以引用此 lib 目录中的第三方程序集。检查所有内容。当构建服务器唤醒以进行下一次构建时，它将拉取最新更改，其中包括新的 lib 目录和项目引用更改。绿色建筑！
您应该详细阅读 NuGet，因为它允许您设置内部包存储库，
无论您的系统多么优雅，您的首要目标应该是运行 CI。在构建系统时，“lib 目录”选项通常是最简单的。您将二进制文件检入 Subversion。这很丑，但它可以让你开始，你的构建级别将是可重现的，这是必须的。在这工作之后，研究并选择适合您需求的外部依赖版本控制系统（可能是 Nuget）。
作为旁注，请详细检查 TeamCity 的免费部署是否不适合您。最后我检查了你必须有大量的协调项目或大量的构建代理才能需要许可证。