When running the "appcmd.exe" tool to migrate an existing Web Application to IIS7, make sure you have a backup of your web.config.
99.999% of the time the changes made are additive, but there is an obscure issue that I bumped into.
Here's some info on the long-ago-deprecated browserCaps section of the web.config:
Using the browserCaps element in the Web.config file to define browsers is deprecated in the .NET Framework 2.0, but it is still supported. The data in this element is merged with the information from the browser definition files (.browser) that is located in the machine-level %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers folder and any existing application-level App_Browser folders. For more information, see Browser Definition File Schema (browsers Element).
This section was and is used to tell ASP.NET about the capabilities of various browsers, usually mobile ones. The original idea was that it'd be updated a lot by a company called Cyscape but Cyscape has hijacked their own URL and turned it into an upsell for their BrowserHawk product. The community tried to step up, but the workload is huge. There's some good browserCaps sections out there, one from SlingFive a few years back, a valiant attempt to energize the CodeProject community around this issue by Chris Maunder.
As I said, this section is deprecated but supported. The preferred - and easier - way is to use BROWSER files, which are more portable and can be installed with ASPNET_REGBROWSERS.
Back to the migration bug. The format of the old browerCaps section was funky from an XML perspective:
<configuration> <browserCaps> <result type="System.Web.HttpBrowserCapabilities, System.Web"/> <use var="HTTP_USER_AGENT"/> browser=Unknown version=0.0 majorversion=0 minorversion=0 frames=false tables=false cookies=false backgroundsounds=false ...etc...
It's totally valid XML, but it's very uncommon to see "mixed nodes" in XML, with an Element, then some text, then an element. In this example the browser=Unknown and all that is just 'tunnelled' in a text node that most folks writing XML processing code would ignore, or not see coming.
It appears that the migration portion of this IIS7 tool...
%systemroot%\system32\inetsrv\APPCMD.EXE migrate config "Default Web Site/DasBlog2"
...toasts these text nodes so that the resulting file is just flat out missing them. This is a common mistake when processing XML that I'm likely guilty of as well.
The Moral and Workaround - Backup your web.config and add this section back after migrating. Of course, this only applies if you're using this kind of obscure section. In our case, DasBlog uses it for Mobile Support.
Ads by The Lounge