I'm going once again through a conversion from Stock Projects to a WAP project conversion this time for my West Wind Web Store. I've done the conversion once before but returned back to stock projects because of a Visual Web Developer requirement. Recently though development on the store has been a lot slower and I seriously find myself dreading updating the store because of the compilation and deployment hassles. So I'm finally to the point of just saying screw it to VWD support and going to WAP for good. This is the last 'real' project I have left that's running stock projects and I'm excited to see it go WAP.

I'm also doing this conversion with Orcas Bea 2 while I'm at it, although for the moment at least (phase 1) I'm sticking with pure 2.0 code. Starting next week I'll be looking at upgrading a bunch of my framework code to .NET 3.5.

WAP Conversion

So I did the conversion this evening. The project is medium in size I'd say - about 50 forms in all with a few user controls and a few sets of master pages. There are a few odd things in this projects - like the theme matched master pages and a number of semi-dynamic pages that are used for full page message and error displays, but for the most part there's nothing tricky.

So the process should be pretty much automated, but I'm finding that it rarely works correctly on the first try. I'm doing this with Orcas Beta 2 but I recall exactly the same issues in VS 2005 in a recent similar migration.

The steps to convert an application to Web Application Projects (WAP) from stock projects are:

1. Create a new WAP project
2. Add all references that were in the old project manually
3. Copy all the files from the stock project installation from Explorer
4. Take care not to copy pure content files (images, XML and temp files etc.)
5. Rename your App_Code Folder to something else
6. Go to the Project Root and run Convert to Web Application

These are the official steps that should be necessary to do the full conversion. If you recall Web Application Projects use a CodeBehind model where all code related to a page or control for the entire project is compiled into a single assembly. WAP does this by explicitly generating the ASP.NET control definition into a separate designer file rather than letting ASP.NET doing its own thing completely dynamically at runtime.

So when you run Convert To Web Application Visual Studio basically runs through all ASPX and ASCX and Master etc. files and fines the CodeFile attribute and converts it into a CodeBehind attribute instead. It also creates .designer.cs file and generates each of the page's controls into this file so you have concrete control reference in the known CodeBehind class which is one of the main reasons why WAP is more consistent than stock projects which generate control properties on a dynamic type that is difficult to get a hold off deterministically.

Anyway, the process should be pretty painless but I still see problems with it. Take a look at this screen shot of Solution Explorer after an import:

Notice that a few of the ASPX files are missing their aspx.designer.cs files. What's really odd about this is that I don't really see anything that would account for this apparent nilly willy skipping of files. All the pages in this application inherit from a Page base class and all are running with a master page so it's really strange that some pages should convert while others won't. Even odder: If I manually Convert to Web Application the files convert just fine (this is something I had problems with in VS 2005 in the past: For some reason some pages just wouldn't go until everything was recompiled and they'd go one at a time - this is not the case in Orcas. In fact here I can just re-run Convert To  Web Application from the root folder and by the second and third time it works.

But something is obviously broken in the conversion parser...

In addition, I've found that standalone classes (.cs files) are not getting their Build Action set correctly:

All the files below the top level classes folder have the incorrect build action set - it should be Compile not Content.

These things are minor but I'm surprised to still see these errors cropping up in Orcas. I mentioned that I did a conversion on this particular project before WAP was actually released with almost the same failures. I figured these little kinks would be worked out by now... <shrug>

But not to take away from WAP - these small issues aside the app fired right up. In all it took about an hour of tweaking the various files and finding a few errors and unconverted files, which all things considered is not bad at all.

Uploading the Project to the Live Server

Next I had to actually migrate the application to my live Web site. The steps for this are basically:

• Move the old, live application to a new folder
• Re-create the original folder and set proper permissions on the folder (IUSR_ and NETWORK SERVICE rights)
• Copy all ASPX/ASCX/MASTER files, the BIN folder, App_Themes etc to the server

The deal is that this is basically a brand new installation so everything has to be copied back up to the server. Unlike stock projects WAP doesn't have a 'deploy' option, so it's basically up to us to figure out what needs to go to the server. For complex applications with many folders getting everything to the server at least for the first time can still be somewhat tedious as you need to sort out the markup files and don't send up code files. Not a big deal but tedious.

Another option here is that you can still use Web Deployment Projects with a WAP project which can precompile all the ASPX/ASCX/MASTER pages etc. and reduce that step, but I actually prefer using the one step compile upload cycle that allows updating one page at a time.

Finally copying the old Web.Config back into the newly copied application so that all the configuration settings (AppSettings) and connection strings would be properly updated for the new application. In my case the web.config required no changes, but you might want to double check BEFORE you update your local web.config to the server whether the old settings are all 100% compatible. In most cases they should be.

One Orcas Beta Compatibility Issue Bites Again

Finally I ran into a nasty snag because of my Orcas installation.  .NET 3.5 patches the .NET Framework 2.0 with SP1 and in the process changes a couple of things. Specifically I get this error:

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

which is related to how ASP.NET deals with the HTML Table  control and uses a new type that doesn't exist in the unpatched .NET 2.0 runtime.

I posted about this before and I had a workaround for it with stock projects by deploying the the CodeBeside file for that application. However with WAP this is not really an option because the compilation goes into the precompiled CodeBehind assembly.

So my fix was to install .NET 3.5 on the server even though I had no immediate plans to do so. Problem fixed, but I'm not really happy with this solution although I suppose this sets me up for testing .NET 3.5 more realistically now <s>...

Still I'm kind of baffled which this change was added to SP1 rather than putting it in the new 3.5 runtimes. This bugs me big time because if I distribute a precompiled application now I have to make sure I compile it with unpatch 2.0 because somebody without SP1 will break. That sucks big time!

This is effectively a breaking change (and there maybe others) which make SP1 and the original .NET 2.0 runtime incompatible. Ontop of all the other versioning nightmares that are 2.0, 3.0 and 3.5 we can now add even more confusion with a service pack that potentially makes non service pack code fail. This is really heavy handed IMHO and just plain WRONG! Especially in the above case because it seems totally unnecessary. To make things even worse I haven't been able to find a list of things that have been changed in the SP so there's really no easy way to tell what else is broken. It's all pretty ugly.

All griping aside, the process of the conversion both to Orcas Beta 2 and Web Application Projects was very smooth and took maybe 2 hours total including the site update and tracking down the above compatibility error...

Not bad at all...