4

Approach

I'm trying to get up and running with TFS 2013. This is my priority order for implementing it.

  1. Start using it for existing Git Repo projects.
  2. Then get automated builds working from check ins (CI?)
  3. Start to use for Work Items and backlog etc, when more comfortable with it.

Is that a good phased approach, so that we aren't trying to build Rome in a day?

Dependent libraries

After setting up a repository for our first solution in it, I got the team and git version control etc setup up. The difficulty came when I tried to do a build, but had dependant library issues.

My initial research suggested that creating a local nuget share/server was a good way to tackle this. So I created a separate repository in TFS for the shared library, it has no other dependencies, so a default build worked fine.

I assume then the intention is to get the build definition to automatically create a nuget package and dropped into the appropriate nuget share. Then that nuget package is now used for functionality in the first original project, rather than a project reference to the shared library?

Then when the first original project is checked in, and a build triggered, that build can use the local nuget share for its dependency (somehow!)?

Is this the best way to tackle this?

  • I personally use TeamCity for builds and it has it's own nuget server which you can publish to to handle dependencies. I never bother with the tfs build server. – Zonder Apr 14 '15 at 10:42
1

if you want to stick to just Team Foundation Server and Team Build, then NuGet is indeed the way to go. The ALM Rangers have written a guide explaining how to handle this scenario.

Indeed adding a little powershell script or integrating the nuget generation as part of your MsBuild project structure to create a nuget package and then pushing that package to a local NuGet server (or simply copying it to a file share) will get you started.

You can use Visual Studio Team Services, MyGet or ProGet or another NuGet server implementation. A fileshare with nuget files can serve as a nuget server. Team Foundation Server 2013 and 2015 do not ship with that capability in the box unfortunately.

As mentioned by Zonder, other build servers, such as JetBrains TeamCity include a built-in dependency system between builds, but they come at a price when you are using TFS. Some features from Microsoft Test Management rely on the Team Build infrastructure. It's possible to have TeamCity generate the correct database records in TFS, but as far as I know it doesn't do so by default.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.