Migration: VS2005 Stock Web Site Project --> VS2005 SP1 Web Application Project

I'm following these instructions by Scott Guthrie on updating my Web Site project to a Web Application Project.  It sounded good after reading Rick Strahl's advice here.  Below is my journal of following those steps, in case this process need be repeated, or someone else finds it helpful.

Step 0 : I already have WAP installed, having VS2005 SP1.

Step 1 : I opted to create a new Project in my current Solution.

Step 2 : Everything seems to go swell here.  We'll see if I missed any references or dependencies later on.  This is kind of interesting compared to the stock project options.  Instead of having the "Bin" directory and putting dlls in there, I add references and the dependencies will be compiled into my project assembly I imagine.

Step 3 : I did the copy paste in Visual Studio like Scott recommends.  Everything seemed to go well.  I did get some "Overwrite files?" requests when copying the \Bin directory.  That's because VS physically copies the assemblies for the references I added in step 2 to the \bin folder in the WAP whenever I build and they are out of date (or not there).  So, no big deal.  TAKE 2: Oops.  I realized that if I copy all of the files this way (right in VS), I'll loose all of the source control history I have in Subversion.  Instead, I copied them all over using the subversion copy -- which is to say I did a Branch/Tag (cheap copy) of the old project to a new directory, then copied the WAP files to that directory and renamed the directory to the WAP name.  Confused?  Ok, I had \web as the old stock project, and \stations as the new WAP project from step 2.  I renamed \stations to \stations2, did a branch/tag of \web to \stations, and then copied the files out of \stations2 into \stations and deleted \stations2.  Then I hit refresh in Solution Explorer and nothing!  Well, naturally there is nothing.  This is back to the good old project model now, where all files in the project must be added.  So, I clicked "Show All Files" at the top of the Solution Explorer and added those files that I wanted by right-clicking on them and doing "Include in project".  I did everything except "obj" and "bin" folders.

Step 4: Everything seems to have gone fine here, but it won't compile now.  I expected that.  First things I did: I did some SVN rename magic to make the App_Code folder (which the convert renames to Old_App_Code) into the "Source" folder, and maintain the file source control version info.  Then I pointed the "Protos" database in SQL Server to the new copy of the protos.mdf file in SQL Server Management Studio (delete, attach). The Full Text Catalogs can't come along for this ride, so I re-run the script I have saved that makes it, along with all the indexes.  Now when I try to build, I get missing references to all my SubSonic generated classes.  That's because before I was using the SubSonic build provider (the .abp file in App_Code) but that won't work in a Web Application Project, because the compilation doesn't happen on the fly.  WAPs don't support Build Providers.  Remove the Build Provider section from the Web.config, it'll do me no good. So, I need to physically generate the class files - I know the title is "without a website", but this webcast by Rob, daddy of Subsonic, explains how to use SubSonic commander (subsonic.exe) to generate your files, and how to make a cool little button to do it.  I think their might be some other tools or Macros you can use here, but I'll look into that later.  For now, this works.

The next problem: one of my files did not get ".aspx.designer.cs" files generated for them, and thus cannot compile.  I had already read about this and other problems on Rick Stahl's blog.  I tried right-clicking on the .aspx file and selecting "Convert to Web Application." This showed me what the problem was.  "Cannot convert: unrecognized server control uc:DynamicDropDown!"  At first I thought that updating my Web.config file to point to the new "Source" code directory for its "assembly" attribute would fix it, but that did nothing.  So, I commented out the custom controls and then did the convert.  It worked!  Then I uncommented them back in and wha-la, a successful build of the project!

Step 5 : Well, the custom control was still giving me trouble.  So, I finally just stopped searching for strange solutions and did what you are supposed to do in the first place: I created and put the custom control in it's own C# class library project.  Added a reference to this project in my WAP, and updated my control registration in my web.config to match.  Works like a charm, although it is kind of annoying to have to build a second project just for this custom control:

    //[SupportsEventValidation]

    /// <summary>
    /// This DynamicDropDown behaves identical to the 
    /// DropDownList control, except that it does
    /// not have the [SupportsEventValidation] Attribute, 
    /// and thus does not participate in
    /// event validation.  This makes it ideal for use with 
    /// the CascadingDropDown AjaxControlToolkit
    /// Extender control.
    /// </summary>
    public class DynamicDropDown : DropDownList
    {
    }

Step 6 : Hmmm... adding the new namespace to all my forms, and then updating all of the "inherits" fields.  I think I'll save this for tonight.  I'm tired, and I spent ALL day working on this.  I should post something fun to my "blog" every now and then, like my cousin James does.