Publishing a website to the filesystem with msbuild and config transforms

Ever since I read Scott Hanselman's post Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong I've wanted to leverage Visual Studio's config transforms, but never had the opportunity until last week. I also took the opportunity to investigate Web Deploy. Here's a summary of my findings:

On Web Deploy
I followed Troy Hunt's excellent series on this topic, in order to learn how to set up an end-to-end build process that uses Web Deploy. Whilst it is indeed an excellent technology, the following notes need bearing in mind:

1. The target web site, file-system folder and app-pool must all exist to start with. I was quite disappointed to find this, as it means an alternative technology is required to create these in the first place (such as the MSBuild Extension Pack's Web tasks or MSDeploy).
2. Visual Studio needs to "know" about all files and folders that need deploying. Most cases are covered by marking the file as either Content or as a reference. If your project had files copied into the distribution by either a pre or post-build event then these files won't be deployed.

On MSBuild

The build pipeline I was integrating into used MSBuild Extension Pack's web tasks to deploy to IIS. This meant that my part of the build had to create a transformed web-site as a complete file-set, ready to deploy. I achieved this using the following MSBuild command:

<MSBuild

   Projects="$(SolutionPath)"

   Targets="Clean;Rebuild;ResolveReferences;Package"

   Properties=

"Configuration=$(Configuration);

OutDir=$(MSBuildProjectDirectory)\bin\; 

AutoParameterizationWebConfigConnectionStrings=false;

_PackageTempDir=$(OutDir)"

/>

The items in italics are the important ones:
Package invokes the package step (creating the web-site as a complete file-set), which includes transformation of web.config.
_PackageTempDir=$(OutDir) tells msbuild where to place the resultant package.
AutoParameterizationWebConfigConnectionStrings=false ensures that the package step fully transforms ConnectionString elements. Read more on what happens if this is omitted, or set to true at Troy Hunt's Stack Overflow question.

Hiding the WCF .svc extension on IIS 5 or 6

If you're setting up a WCF web service, its nicer to present a URL that does not have the .svc extension in it, i.e.

http://moviesite.com/movies/123

Instead of
http://moviesite.com/service.svc/movies/123


A simple way of achieving this on IIS versions 5 or 6 is using the free ISAPI Rewrite tool, with the following configuration:

# Don't rewrite url's that already contain .svc.


RewriteRule .*\.svc.* - [L]


# Rewrite requests for host moviesite.com to be moviesite.com/service.svc/whatever.

RewriteCond %{HTTP:Host} moviesite.com

RewriteRule ^/(.*)$ /service.svc/$1 [L]

Load testing a WCF web-service gives a 403 error on IIS 5.1 (XP Pro)

If you're hosting a WCF web service using XP Pro's IIS and checking its thread-safety by hitting with > 20 threads, then its likely you'll be seeing some 403 errors.

This is unfortunately by design. See Jeff Atwood's article on why and how to get around IIS 5.1's shackles.

Configuring the Identity of an IIS Application Pool

If a web-site needs to run under a specific identity, IIS application pools provide a convenient means of achieving this. However, a reoccurring problem I come up against in setting these up is forgetting to ensure the identity is also a member of the local IIS_WPG group. TechNet has the full story.

So if you get one of these red icons on your Application Pool, check the IIS_WPG group.