Dependency management with TFS 2010

问题:

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).

回答1:

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="&quot;$(SolutionDir)Tools\nuget&quot; install &quot;$(ProjectDir)packages.config&quot; -o &quot;$(SolutionDir)Packages&quot;" 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 ;).

回答2:

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.

回答3:

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.