Compatibility between VS, TFS and TeamBuild template versions?

Question

Disclaimer:

I'm no expert with TeamBuild. I'm aware that the questions I'm asking may be stupid.

What I currently have

I have a VS2010 solution with 10+ console applications and 3 ASP.NET Web Applications project. I set up a TeamBuild on our TFS2013.2 server with the following options:

• The TeamBuild template is the default TFS2010 DefaultTemplate.xaml
• It targets the solution file

The files ending in the drop folder are:

• All the exes and the config files of the console applications
• A _PublishedWebsites folder containing one folder per web application project. Note that web.config XML transform is not done

What I want

I'd like the build to give me:

• One folder per console application
• web.config XML transformation

My idea was to setup a new build with the default TFS2013 build template, TfvcTemplate.12.xaml, because I saw that there is an option specifying that the output should be on a PerProject basis. The build fails because of MSBuild failing to build the web projects, with an error related to WebDeploy:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3009): Web deployment task failed. (Unknown ProviderOption:DefiningProjectFullPath. Known ProviderOptions:.)

My Questions

• Is it normal that a VS2010 solution fails when being built by a TFS2013 build template?
• Is it normal that WebDeploy doesn't seem to get involved at all with the TFS2010 default build template but it is with the TFS2013 build template?
• If not, may there be some adjustement to make in .csproj files to get them being built by a TFS2013 build template?
• Do I have to update the targets files to the V12 version as it's TFS2013 which builds it?

My Potential answers

• I have WebDeploy 3.5 installed on my build server, and I already got it to work.
• All the targets files look in place

Thanks ;-)

Answer 1

I figured it out today, thanks to a blog post by Sayed Ibrahim Hashimi.
Basically, it explains what modifications are made to a .csproj when you open a VS2010 solution with VS2012 or VS2013. Links to .targets files, in this case the Microsoft.WebApplication.targets are made relative to the version of VS used to open the solution.

As the solution I'm working on was only worked on with VS2010, the .targets file I was pointing to was the VS2010 specific version, located at
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets

I manually edited the .csproj files of my 3 web applications projects to include Sayed's modifications, and then the build based on the TFS2013 default build template worked like a charm.

My guess: TFBuild2013 was passing arguments to some WebDeploy MSBuild task that the VS2010 version of the .targets file didn't understand.

Thanks for the response, @Daniel Mann!

Answer 2

For the first problem (separating output for each project into individual folders), the best approach is to use the TFS 2013 Default Template, which has a flag that makes it put each solution that's built into a separate folder. Then, make solutions for each individual application. The assumption is that one solution consists of one application and all of its dependencies, not multiple applications. The "golden rule" is: one application per solution.

For the problem you're encountering with the build failing when using the TFS2013 build process template, make sure VS2013 Update 2 is installed on that server -- my research on the subject points to that being a problem.

For the second problem, you probably don't want to be using web.config transforms. Ideally, you only need to build your binaries once, then you can deploy them to multiple environments -- the only differentiating factor is your config file. If you're using web.config transforms, the config file you get is dependent on which platform you're building. Building for each environment has a few problems:

1. It eats up more time -- if your build takes 10 minutes to run, and you have to run it once for each of 4 environments, then you're wasting 30 minutes just to get a different config file at the end.
2. It introduces risk -- what if something on the build server changed, or something in source control changed? Suddenly, the binaries you're releasing aren't the same as what you've been testing.
3. It's harder to maintain. You have to have a bunch of different build definitions, and a bunch of different solution platforms. The more things you have to maintain, the higher the chance of something getting messed up.

Your best bet here is to source control multiple versions of the web.config file, one for each environment, then choose the appropriate config file at the time of deployment.

An alternate method would be to use a tool that supports tokenization of the config file -- that way, you have one config file that just contains tokens that can be replaced with the appropriate values at the time of release. But that's going to require additional tooling and configuration that you might not be interested in.