This project is read-only.

TfsSource usage

Feb 23, 2011 at 8:50 AM


I need some help regarding the TfsSource task. I'm trying to do 3  things in my build script. Check out all the AssemblyInfo.cs files in a solution from TFS, alter the AssemblyFileVersion and AssemblyVersion attributes and check in all the AssemblyInfo.cs files in TFS again.

The code for checking out the files looks like this:

<Target Name="AfterGet">
   <MSBuild.ExtensionPack.VisualStudio.TfsSource TaskAction="Checkout"  ItemCol="@(AssemblyInfoFiles)" WorkingDirectory="$(SolutionRoot)"/>

This gives me this error:

Exit Code 100. Nothing Succeeded: TF30063: You are not authorized to access <url_to_tfs>.

OKay, so I need to provide a username and password so that I be authenticated. How should I provide username and password to the TfsSource task? I can't see that the task supports those 2 parameters.

How do I solve this issue?

Best regards,

Feb 24, 2011 at 8:55 AM
Edited Feb 24, 2011 at 8:55 AM


I would not advise performing source control operations in versioning code during builds. I have an old but still valid blog post here

Saying that, I see TFS2010 exposes the /login property. I'll get that in for the next version. Copying this to a workitem....


Feb 24, 2011 at 8:56 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Feb 24, 2011 at 12:56 PM

Hi Mike,

I have some follow up questions. I hope you will be so kind to answer them:)

In the company I'm working for we use VS2010 to develop our products, TFS2008 as source control, Team City to build our solutions and Wix to create our setups.

My goal with this "exercise" was to create a ms build script that does a few things:

1. Builds the solution (obviously)

2. Check out the AssemblyInfo.cs files in the solution, increase the version number and check in the files in TFS. I kind of hoped that this would be a good thing to do. What I had in mind was to increase the version number in the AssemblyInfo.cs files every time we check in and the code gets built on the build server. I was also hoping that this would be a good thing when it comes to create the setup as well. So every time we create a new setup file, the assemblies version numbers are increased. Your saying this is a bad idea because of noise you create on the pending merges table. What if you check in the AssemblyInfo.cs files with a ***NO_CI*** comment? Would that prevent trouble? Or are you thinking on something else? (not sure that I understood the continuous merge issues you talked about in your blog).

2. Another thing I hope you can provide some advice on. We have a server side API solution that contains a few projects. These assemblies are used by various client applications. What I do is that every time I build that server side API, the resulting assemblies are copied to a SharedLibrary folder (I wrote a post build event in each project that copies the assembly to the SharedLibrary folder). This folder is under source control. So I need to check out, update and check in  these assemblies whenever I have updated some files i the API. This is a somewhat tedious process. What I would like to accomplish is that every time I make a change in the API and check in the changeset,  team city builds the server side API solution, the assemblies in the SharedLibrary folder are checked out by the build script, updated and checked in again. The desired result would be that my colleagues can check out the SharedLibrary folder from source control and they have the latest version of the API assemblies to work with without having to check out the API solution and building the assemblies themselves. Do you have any experience/advice on how to achieve that? Will this generate the same noise on the merges tables that you talked about?


Feb 24, 2011 at 2:50 PM


For #2, the no_ci will not prevent you seeing a whole bunch of labels, its simply stops a ci build triggering. I would question the value of having incremented values in source control. You should determine these number at runtime (in TFS we use TFSVersion task, I've not worked with Team City, but you should be able to follow the same logic).

For the second #2, that all sounds fine an easy enough. I'd add that as a post build step in TFSBuild and use the TfsSource task. Again though, I'm not sure how Team City would do this.