This project is read-only.

how to set the tfs workspace url, etc

Feb 24, 2011 at 3:19 AM

I was running the TFS 'get' task action in the MSBuild.ExtensionPack.VisualStudio.TfsSource namespace.

It produces the following command line: C:\>tf.exe get "C:\Active\Develop\TEST\SANDBOX\DEV-VS2010"  /all /noprompt /recursive

It failed in MSBuild so I copied the text to the command line and got this error:

Unable to determine the workspace. You may be able to correct this by running 'tf workspaces /collection:TeamProjectCollectionUrl'.

This brings me to two questions: how is this extension task intended to be used?

How can I use it dependably in a situation where the user who fires the MSBuild targets at the command line may NOT have tfs permissions?



Feb 24, 2011 at 8:12 AM

Hi Kimball

What was the error in MSBuild? Setting the WorkingDirectory is important as it allows TFS to determine the workspace.

If you run the command from a commandline, you need to do it from a folder that is in the workspace you have configured.


Feb 24, 2011 at 11:59 AM


I appreciate your response.

Now can you please answer the most important question:

How is this Extension task intended to be used?

Or should I just check the tf.exe usage information and presume the same requirements?

But if you really want to help, what about this:

In a build machine (not necessarily a canonical 'tfs build machine') I want my msbuild scripts to get code from source as a normal step in the procedure.

Therefore I need to be able to establish ALL the normal TFS Environment features that are required to satisfy TFS's concerns about authentication and authorization and so forth.

I must admit I am puzzled that neither the MSBuild Extension Pack nor the MSBuild Community tasks include a target and tasks that address the full feature set for accomplishing this.

It makes me wonder about whether I am at all thinking about the role of MSBuild correctly in the first place since with neither of these extension packs can I get to what I think of as 'first base'.

Your comment about calling the tf.exe from within a folder that is within the established working directory of an established tfw workspace presumes (to me) that you believe every build machine and each path to a set of build folders has a separate workspace defined in TFS for each user who might want to fire a MSBuild process.

This means (in my mind) that to successfully perform a 'get' from TFS with an MSBuild target, one would expect to have to provide the user name and domain for an admin user on a build machine as well as a name for an existing or new workspace to be created, plus a TFS path to the source folder and a local item path to the existing or new working directory where the code should be placed.

Which likely means that for every new 'get' a new workspace would have to be created and then destroyed.

Without all of that, the operations of the MSBuild extension tasks are so circumscribed as to be functionally useless.

Or do I just not get it?

Do you see why I want to know 'why' and 'how' not just when and if?



Feb 24, 2011 at 12:59 PM

TFS Source Control is all about workspaces. This task is a light wrapper for tf.exe. You can find more information on it here: