Here's a stumper. Today I made a very minor change to my West Wind Web Store application. It's basically and administrative tweak to capture spam IP addresses and store them for later optional blocking. The change made didn't touch anything in the rest of the application.

The West Wind Web Store is my last app that's left that's not running Web Application projects. Primarily because it's a re-distributed application and geared towards developers including those that might not actually have Visual Studio and can only use Visual Web Developer 2005 which - sadly - doesn't support the Web Applicaiton model.

Anyway, today I made the change, re-tested the app to make sure it works locally and then ran it through Web Deployment projects to create a deployable site. I copied the site up to the server (skipping images and web.config) and all should be well.

Once uploaded I test it out on the server and the app starts right up. The base pages work fine, until - I hit one particular page where it bombs. It bombs with:

/wwStore/orderprofile.aspx

Could not load type 'System.Web.UI.HtmlControls.HtmlTableBodySection' from assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
on 5/17/2007 12:39:46 pm

--- Stack Trace ---
   at ASP.orderprofile_aspx.__BuildControlContent(Control __ctrl)
   at System.Web.UI.CompiledTemplateBuilder.InstantiateIn(Control container)
   at ASP.app_templates_standard_webstoremaster_master.__BuildControlContent()
   at ASP.app_templates_standard_webstoremaster_master.__BuildControlform1()
   at ASP.app_templates_standard_webstoremaster_master.__BuildControlTree(app_templates_standard_webstoremaster_master __ctrl)
   at ASP.app_templates_standard_webstoremaster_master.FrameworkInitialize()
   at System.Web.UI.UserControl.InitializeAsUserControlInternal()
   at System.Web.UI.MasterPage.CreateMaster(TemplateControl owner, HttpContext context, VirtualPath masterPageFile, IDictionary contentTemplateCollection)
   at System.Web.UI.Page.get_Master()
   at System.Web.UI.Page.ApplyMasterPage()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

--- Request Information ---
  Full Url: http://www.west-wind.com/wwStore/orderprofile.aspx
        IP: 209.216.162.15
   Referer:https://www.west-wind.com/wwStore/ShoppingCart.aspx
   Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
     Login: Anonymous
    Locale: en-us

What's interesting is this: It doesn't bomb on my local machine. Not in the dev setup, nor when running hte application out of the precompiled directory. In both cases - no error.

At first I thought I must be missing some files so I completely blew away the installation on the server and recopied all the files from the deployment output. Same damn problem. Next I went through and killed the ASP.NET temporary files directory thinking maybe there's some version mismatch going on (it's happened before), but that doesn't help either.

Finally after futzting with this for about an hour and a site that's down, I just broke down and copied my raw dev installation back up to the server (ie. without precompilation including the source files) and that worked. At least I have a running site for the moment.

After digging around with Google I found a few similar entries that deal ran into the HtmlTableBodySection object - which doesn't actually exist in ASP.NET 2.0. Apparently this is a new feature in ASP.NET 2.0 SP1 and ASP.NET's page parser is using this object for the table hierarchy in creating the page tree. This explains why the code fails with precompilation on the server: The app is pre-compiled with SP1 which doesn't exist on the live server. It also explains why the site runs just fine and dandy when the source is deployed because ASP.NET locally on the server compiles the app without the HtmlTableBodySection object.

Note that it doesn't matter that I didn't use Orcas to compile the Web application - it's the fact that .NET 2.0 SP1 is installed here that causes the problem. There may be other issues like this, but I hope this is actually a bug - I would prefer that there's binary compatibility between SP releases.

I'm done with stock ASP.NET projects

Yes I am. Just about all of my apps are using Web Application Projects now, with this one being the big exception. And although this problem is a self-inflicted wound (running beta software on a live dev machine) it just reminded me just how much of a freaking hassle stock projects are if you need to deploy a non-trivial application properly. Trying to get the myriad of file requirements into sync between dev and live site is a royal hassle, plus the step of actually precompiling which is deadly slow (and I went through about 50 times today trying to figure out what was going on).

After this excercise I think I'm going to move this project up to WAP as well - Express users or not. It's just not worth the aggravation, not to mention trying to explain in the documentation how to deploy the damn project.

And FWIW, it looks like WAP projects aren't affected by this particular issue (although it could potentially be by others related to other binary changes in the framework) since WAP projects leave page compilation to happen on the server.