使用 TFS 2010 进行依赖关系管理

发布于 2024-11-16 02:35:22 字数 165 浏览 3 评论 0原文

使用 TFS 2010 管理依赖关系的最佳方法是什么?

编辑: 我想知道是否有一个系统(例如 Maven 或 NuGet)可以轻松管理 TFS 2010 内的 .dll(外部文件或我们团队创建的)依赖项。 然而,我们面临的问题是我们希望能够修改 dll 的代码并实时测试它们是否有效(无需发布新包)。

What is the best way to manage dependencies with TFS 2010 ?

EDIT:
I would like to know if there is a system such as Maven or NuGet which allows to easily manage dependencies of .dll (externals or created by our team) inside TFS 2010.
However we face the problem that we want to be able to modify the code of our dll and test in real time if they work (without publishing a new package).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

初与友歌 2024-11-23 02:35:22

实际上,调用 NuGet 作为预构建步骤非常容易。您可以使用 NuGet 引用覆盖项目的 *.*proj 文件中的 BeforeBuild 目标。

<Target Name="BeforeBuild">
  <Exec Command=""$(SolutionDir)Tools\nuget" install "$(ProjectDir)packages.config" -o "$(SolutionDir)Packages"" Condition="'$(BuildingInsideVisualStudio)'==''" />
</Target>

正如上面的代码片段所暗示的,您需要下载 NuGet 命令行实用程序 ,将其放在解决方案文件夹下的文件夹中,然后将其签入版本控制。请注意,您下载的可执行文件实际上是一个引导程序,您需要运行一次以下载真正的可执行文件。

接下来,您需要签入项目目录中的packages.config 文件,而不是解决方案目录下的packages 文件夹。请注意,我已经包含了对 $(BuildingInsideVisualStudio) 的检查,以便在上面的预构建步骤中设置。这将导致在使用 TFS 构建服务(或从命令行)构建时在构建时下载并安装软件包。它不会影响您在 Visual Studio 中的 NuGet 体验。

您可以搜索有关使用 TFS 自动创建 NuGet 包的文章 - 很多人都在博客上讨论过它。两者的结合构成了一个非常强大的依赖管理解决方案。现在我们只需要 TFS 中内置的 NuGet 提要;)。

It's actually pretty easy to invoke NuGet as a pre-build step. You can override the BeforeBuild target in your *.*proj file for the project with NuGet references.

<Target Name="BeforeBuild">
  <Exec Command=""$(SolutionDir)Tools\nuget" install "$(ProjectDir)packages.config" -o "$(SolutionDir)Packages"" Condition="'$(BuildingInsideVisualStudio)'==''" />
</Target>

As implied by the snippet above, you'll want to download the NuGet command line utility, place it in a folder beneath your solution folder, and check it into version control. Note that the executable you download is actually a bootstrapper that you'll want to run once to download the real executable.

Next you'll want to check in the packages.config file from your project directory, but not the packages folder beneath your solution directory. Note that I've included a check for $(BuildingInsideVisualStudio) to not be set in the pre-build step above. This will cause the packages to be downloaded and installed at build-time when building with the TFS build service (or from the command line). It won't affect your NuGet experience inside Visual Studio.

You can search for articles on automating the creation of NuGet packages with TFS - quite a few people have blogged about it. The combination of the two makes for a very capable dependency management solution. Now we just need a NuGet feed built into TFS ;).

风吹短裙飘 2024-11-23 02:35:22

如果您的问题涉及管理您自己构建的公共基础库的外部项目依赖项,有些人将其称为“子系统分支”或“依赖项复制”。

以下是处理此主题的文章的三个链接:

http://geekswithblogs.net/terje/archive/2008/11/02/article-on-subsystem-branching.aspx

http://blog.ehn.nu/2009 /03/implementing-dependency-replication-with-tfs-team-build/

http://blog.ehn.nu/2010/12 /dependency-replication-with-tfs-2010-build/

我恰好手头有这些,因为我现在正在寻找一种方法来自己处理这些东西。

If your question relates to managing external project dependencies of a common base lib you're building yourself, some people call this subsystem branching or dependency replication.

Here's three links to articles that handle this subject:

http://geekswithblogs.net/terje/archive/2008/11/02/article-on-subsystem-branching.aspx

http://blog.ehn.nu/2009/03/implementing-dependency-replication-with-tfs-team-build/

http://blog.ehn.nu/2010/12/dependency-replication-with-tfs-2010-build/

I just happened to have these at hand since I'm looking for a way to handle this stuff myself just now.

泪冰清 2024-11-23 02:35:22

当您在 TFS 2010 中创建持续集成构建时,只要在与为构建定义的工作区匹配的源代码管理文件夹之一中签入某些内容,就会触发构建。您可以尝试为您使用的 DLL 创建源代码管理文件夹,然后将该文件夹包含在需要它们的每个项目的工作区中。

当您定义 CI 构建并签入这些 DLL 之一的新版本时,这将触发使用这些 DLL 的所有项目的 CI 构建。当然,CI 构建不仅会构建代码,还会运行单元测试。

When you create a Continuous Integration build in TFS 2010, the build is triggered whenever something is checked in within one of the source control folders matching the workspace defined for the build. You might try creating a source control folder for the DLLs you use, then including that folder in the workspace of each project that needs them.

When you define CI builds, and check in a new version of one of these DLLs, this would trigger a CI build of all of the projects that use the DLLs. Of course, the CI build would not only build the code, it would also run the unit tests.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文