0

Just wondering on the recommended process of checking in an output of a project or solution post a successful build.

For example the Build relates to a common library. Post a change I want that to be checked in to a known location so other solutions can reference.

Some examples might be

  • Custom Workflow activities
  • Invoking TF exe directly
Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
merbla
  • 537
  • 6
  • 14
  • One of the targets in a modern CI-environment is/should be that each build can be repeated at any time. If each build checks something in, this would defeat the purpose. See also if this post is helpful: http://stackoverflow.com/a/8578128/728929 – pantelif Feb 16 '12 at 12:45

3 Answers3

2

I would not check an output in. Instead, I would move it to a well-known location, probably a file share.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 1
    File shares have the common problem of being untrusted by .NET by default. You can solve this by running CasPol to explicitly trust the share. See: http://thebackroomtech.com/2009/04/01/using-caspolexe-to-grant-net-applications-rights-to-a-remote-network-share/ – jessehouwing Feb 16 '12 at 12:24
1

I don't do this currently but plan to investigate NuGet as a solution to this scenario. MSDN has some articles showing how to incorporate NuGet into your projects and host a private gallery of your own NuGet packages. MSDN has examples of a build that compiles your common code and then packages it and updates it into your private NuGet gallery. Then in your projects you would consume the NuGet package of the common library you wish to use.

Main MSDN article describing this: http://msdn.microsoft.com/en-us/magazine/hh781026.aspx

Other resources:

http://nuget.org/

http://nugetter.codeplex.com/

Matt Cofer
  • 2,972
  • 1
  • 20
  • 18
0

Have a look at this post from Ewald Hofman, it updates certain files and checks them in using a custom activity. You could use the same process. But this involves customizing the build process template and deploying custom build activities to all build agents.

But you might also want to investigate the free AIT Dependency Manager which can download the latest specific version (can filter on build outcome or quality) of one build from the buildserver as reference to another build (also inside Visual Studio). This is a lot more flexible than constantly checking in the build output and allows you to have your dev branch to always get the latest (unstable) version, but your release branch to always get the latest well tested and approved version.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • Thanks jesse I did stumble over that. We have a situation in which we are using TFS2010 but really the TFS2008 build process – merbla Feb 17 '12 at 07:08
  • It shouldn't be too hard to upgrade it to a TFS 2010 template, if you aren't doing too many custom things in msbuild. Otherwise try calling the 2008 proj file from the 2010 workflow, that usually works just fine. – jessehouwing Feb 17 '12 at 19:23