Question

We have a TFS 2008 project with two branches (“Main” and “NewFeature”).
Each is a complete, independent “copy” (variant) of the source code.

By changing the workspace mappings, we can map either variant onto our local PCs and have been working with both branches with no problems.

However, if I set up the mappings to switch our build server on to the NewFeature branch (which should simply swap in the NewFeature source code without changing anything else as far as the build server is concerned) I get errors:

There is no working folder mapping for $/Main/Product.sln

i.e. when it is building from the NewFeature branch, something is still looking in the Main branch, even though there are no references anywhere in the source code to this branch. It appears to be caching some reference to Main?!

I have done a completely clean build (deleted the build folder from the server and run the build with /p:ForceGet=true to make sure the mapping is flushed through to the server, and there are no files on the server that might cache the workspace bindings), but this doesn’t help.

Any suggestions?

Answer 1

Verify that:

• $(SolutionToBuild) uses a relative path when referencing Product.sln
• the relative path between $/NewFeature/…/TFSBuild.proj and $/NewFeature/Product.sln is the same as it is in the Main branch.

/ EDIT /

Note, however, it’s not important that $/Main and $/Branches/Feature live at the same level in the tree hierarchy. Nor should the local path on the build server matter.* All that matters is what’s underneath each branch. If the contents is internally consistent then all of your existing build scripts should work without modification.

For concrete examples of how I like to tie everything together, see my past answers, e.g.:

• Modular TeamBuilds
• SDLC Mangement for TFS Build Scripts
• Where to put my database project in TFS?
• How do you share external dependencies between Visual Studio solutions?

My way is not the only way, but I can attest that it works better than all the other variations I’ve encountered over the years 🙂

*Frankly, trying to micromanage Team Build can become a lot more painful than the proposed restructuring to your MSBuild scripts. For reliability you have to place your tfsbuildservice.exe.config customizations under version control somewhere…if you own >1 build server (or might in the future) then you have to consider a change deployment strategy…you end up needing a meta-SCM process to manage your SCM process!