A pedant that hangs out in the dark corner-cases of the web.

Thursday, May 17, 2007

Here's how to Team Build a Web Application Project

Update: Aaron Hallberg : Team Build and Web Deployment Projects

  1. First, create a Web Deployment Project for your Web Application Project. (If you have a Web Site Project, you will need to convert the Web Site Project to a Web Application Project before continuing.)
  2. Set the Output Folder to the destination UNC for the Debug and Release build types.
  3. Set any other WDP properties appropriate to your environment, such as Web.config file section replacement.
  4. Make sure your build server has VisualStudio and VS SP1 installed. If the server does not have the C:\Program Files\MSBuild\Microsoft\WebDeployment\ folder, you may need to install Web Deployment Projects as well.
  5. Create fixup.TeamWebDeployment.targets (see below) in C:\Program Files\MSBuild\. Normally, the Team Build drop location overrides the Output Folder, so this file adds a second compile task to put the web app where you wanted it to go in the first place.
  6. Add an import directive for $(MSBuildExtensionsPath)\fixup.TeamWebDeployment.targets.
  7. Create the team build, choosing your solution and build type, but you MUST choose Mixed Platforms as the Platform, or things will go very badly for you.
  8. Cross your fingers and run the build.
fixup.TeamWebDeployment.targets
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="AfterBuild" Condition="$(OutputPath) != $(WDTargetDir)">
<AspNetCompiler
PhysicalPath="$(_AspNetCompilerSourceWebPath)"
TargetPath="$(OutputPath)"
VirtualPath="$(_AspNetCompilerVirtualPath)"
Force="$(_Force)"
Debug="$(DebugSymbols)"
Updateable="$(EnableUpdateable)"
KeyFile="$(_FullKeyFile)"
KeyContainer="$(_AspNetCompilerKeyContainer)"
DelaySign="$(DelaySign)"
AllowPartiallyTrustedCallers="$(AllowPartiallyTrustedCallers)"
FixedNames="$(_AspNetCompilerFixedNames)"
Clean="$(Clean)"
MetabasePath="$(_AspNetCompilerMetabasePath)"
/>
<RemoveDir Condition="'$(DeleteAppDataFolder)' == 'true'" Directories="$(OutputPath)\App_Data"/>
</Target>
</Project>

Also, I have to ask any MS folks out there: Why C:\Program Files\MSBuild\ ? Why not C:\Program Files\Common Files\MSBuild\ or C:\Documents and Settings\<current/all user(s)>\Application Settings\Microsoft\MSBuild\ ? This adds yet another customizable location that needs to be backed up.

Monday, May 14, 2007

VS TFS Build: Another day completely wasted

I've been trying to set up a Team Build for a simple web application for about a week now, and I just don't see the point anymore.

Sure, it integrates into Visual Studio, but that represents ROI for Microsoft, not me.

I've come from scheduling build scripts (.cmd -fu), with some Ant/nAnt experience to the nightmare world of the overdesigned MSBuild, which is just completely opaque. With a syntax that makes a simple tag reference impossible (properties are assigned by the tag name), too much confounding magic (this property or item or target has a special name that is used somewhere deep within the Web Deployment target file, and good luck finding a simple reference for that), and a completely impenetrable variable syntax ( @(FilesToCopy –> '$(MSBuildProjectDirectory)\Bin\%(Filename)%(Extension)') ? Are you kidding me?), and the ever-human-readable GUIDs (also impossible to find a quickref for) sprinkled throughout.

I've found exactly one book, published last year (not even by MS Press), on MSBuild. Other books may provide an appendix or something, but I haven't found anything helpful.

Today I finally got my Web Deployment Project to build successfully as a Team Build, but nothing showed up in the WDP Output Directory. Great, so it isn't working, and there is no error message to tell me why. WTF?

Side topic: What are the intended purposes of Web Sites, Web Application Projects, and Web Deployment Projects? How do they compare? Why do all three exist? Am I using the wrong thing?

Why am I doing this? Because it's the Microsoft direction? What do I gain? As far as I can tell, the primary differences are some better reporting and auditing, integration with the VS Team Process Template (once we decide to try customizing that again), and that our QA staff will now need to open VS to start a test build, where they could just open \\<server>\admin$\Tasks before.

In the meantime, I am hemorrhaging hours, and seriously wondering...why?