Specifying Tf.exe and MsBuild version in CC.Net

The problem

I am porting a build to a newer version of CC.Net (from 1.4.4 to a very recent version of 1.6). Previously the build mixed <msbuild /> tags with <exec /> tags that call batch files with tf.exe commands in them.

The build must have relied on the source control version being the same between the msbuild and tf.exe commands, because now I get an error on the tf.exe command:

Unable to determine the workspa开发者_JAVA技巧ce.

When I launch a command prompt, with runas as the same user the service is using, and call the same command the batch file used (from the same directory), I get the same error.

However if I launch a Visual Studio 2010 command prompt, with runas, and call that command (from the same directory), I don't get the error.

This also makes sense, because the %UserProfile%\Local Settings\Application Data\Microsoft\Team Foundation\3.0\Cache\VersionControl.config file has the workspace mapping, but the ...\1.0\Cache\VersionControl.config file does not.

The solution I'd like to try

I can't simply change the PATH for the batch file because it actually needs to build against an older version of Visual Studio, due to licensing.

I think I could solve this by specifying the TFS/msbuild version used with the <msbuild /> tag. But I'm not sure how to go about this. I think it would be some sort of server configuration, but I haven't found anything about this in the docs.

My question is: How do I specify the version of TFS that Cruise Control uses for <msbuild /> tags? Or is there another way to solve this?

As far as I know, there is no way to specify this directly with msbuild. The way it is solved at our place is that we set the executable for msbuild to a bat-file that's basically a copy of the desired vcvars-script (used by Visual Studio Command Prompt to set up the environment).

<tasks>
      <msbuild>
        <executable>vcvars_VC10_amd64.bat</executable>
        <workingDirectory>SomeFolder</workingDirectory>
        <environment>
            <variable name="foo" value="bar" />
        </environment>
        <projectFile>msbuild.proj</projectFile>
        <buildArgs>/m:2  /p:Configuration=Release /p:Platform=x64 /v:normal</buildArgs>
        <targets>Clean;Build;Test</targets>
        <timeout>3600</timeout>
      </msbuild>
  </tasks>

Maybe you could get away with setting up your desired paths using the <environment> property as well.

I won't accept this solution, in case people have other solutions (or can solve the problem I directly asked about), but here's how I ended up solving my problem:

I added a workspace sync task to the top of the build tasks:

<tasks>
    <exec>
        <description>Sync the workspaces with the TFS server, for the version of TFS used in exec commands</description>
        <executable>Tf.exe</executable>
        <buildArgs>workspaces /s:$(TfsServer)</buildArgs>
    </exec>

This works because in my scenario, I don't care about the versioning as much as I do about the workspaces getting out of sync.