Finally! .NET 2.0 has been out for a year.  Finally found the time to move our main application to 2.0. It's been a bit of an adventure.  There are 12 class libraries, 2 server control assemblies, a service, a web app and various utilities.  Two of the class libraries are in C++, one managed, one native. The truly insane can read about the little odyssey through those assemblies.  Everything else is written in VB.NET. 

The VB.NET class libraries converted easily.  The only issue was in the few classes that performed XSL Transformations where I had to change a couple of deprecated method calls.  These were no surprise.  Other than that there were only warnings for untyped functions or parameters (very naughty, and one of the dangers of working in VB with OPTION STRICT OFF) and a surprising number of unused local variables. 

The web application was a lot trickier than anticipated.  There are some fundamental differences between 1.1 and 2.0 web applications. One of the significant changes is in the coding model.  2.0 makes use of partial classes, so that a single class can be created from separate files, this cleans some things up.  There are no longer control declarations in the code-behind file, but it is a change. 

Here is a very handy resource that discusses most of the issues you will run into when converting from 1.1 to 2.0. 

In the standard out-of-the-box VS2005, the project file for web applications has also gone the way of the dodo, you create Web Site Projects.  Everything in the project tree gets put into the application. Fortunately, there is a feature to exclude files, which you will use. Since the Web Site Project includes ALL the files in the directory tree, files that you excluded in your 1.1 project will suddenly reappear like uncompilable ghosts in the 2.0 version. The other annoying "feature" is that these projects spew forth an assembly for every folder in your application, and couple of others for good measure, and the files are randomly named.  Hello deployment fun -- I'm sure there's good reason for this, but it is not intuitively obvious, it seems friggin' nutty.

This application model had been fine for the smaller projects I had converted, and I figured I would discover a way to deal with the assembly vomit, so I pushed on assuming that I was moments away from having a our application working in 2.0.

But it was not to be, this web application pushed the Web Site Project model over the cliff of despair.

The application has around 60 pages, 15 classes and 15 user controls spread amongst 10 directories. Most of the heavy lifting is done in the underlying libraries. I didn't think it was that large until I tried to compile it.  In VS 2003, it was up and running in under a minute, in VS2005 it was 5+ minutes, and the sucker was crashing every time I changed the base web page class that the pages inherited from.  I lived with this for about a day, googling while it compiled or restarted, toggling various settings, swearing and pruning previously exlcuded and unused pages ruthlessly. 

After one seemingly eternal cycle of rebooting, I seriously considered asking for a quad-core super box or retreating back to 1.1.  I decided to take one more look around the web for a solution and I stumbled across this article, which in turn led me to discover an alternate model to this lunancy, the Web Application Project! It was the old 1.1 compilation model, complete with a single assembly output -- hooray.  It required some VS update installations and yet another conversion from my original 1.1 application, but in a few hours I had a quickly compiling application.  Some testing and a small victory dance later, and it was time to start ripping out the facacta hand-rolled page templates and putting in the master pages!