I just spent a couple of days migrating my remaining (important) VS2003 Web Application code to VS2005. It had its frustrating moments but each of those frustrating moments reminded my why it was such a great idea to dump the VS2003 Web App code. The #1 biggest problem was getting VS2003 Web Applications to actually open on a machine other than the one it was written on (remember how much fun it was to get the IIS virtual directory settings to match with the file system directory references in the .sln file?)
Anyway, it’s done.
Here are the top weird issues:
1. Problem: You run your migrated Web Deployment Project (aka Installer Project or MSI) and then go to the newly created website and there’s nothing in the “bin” directory. All the assemblies (DLLs) are in the root of the website.
In VS2003 installers, when you specified the “Primary Output” from a web app, you’d put it in the root of the “Web Application Folder”. This Primary Output would create a “bin” directory and copy it’s output into that directory. (I always thought this was a little confusing.) It doesn’t do this anymore in VS2005.
Solution: Create a “bin” folder in the “Web Application Folder” and move (drag/drop) the Primary Output from your web project into “bin”. When you’ve done this, you should see “Primary output from MyWebProject (Active)” in the “bin” directory along with all the assemblies that it depends on. In the “Web Application Folder” you should just have “Content Files from MyWebProject (Active)”.
2. Problem: Page_Load() isn’t getting called.
This happened once or twice to me when migrating. The conversion process for 2003 to 2005 has to go through your code and create the MyPage.aspx.designer.cs files and the “partial” keyword. If you’re doing the conversion in a folder other than the original, the converter gets confused and edits some files in the wrong folder (translated: it edits the wrong file).
Solution: for any file that isn’t working, go into the .aspx.cs file (MyPage.aspx.cs) and find the InitializeComponent() method. (Hint: It’s inside of a #region named “Web Form Designer generated code” and is covered with code comments that direct you to never ever modify this code.) Make sure that there’s a line in there that subscribes your Page_Load() to the Load event for the Page.
private void InitializeComponent()
this.Load += new System.EventHandler(this.Page_Load);
3. Problem: AuthenticateRequest() isn’t getting called and your custom security code doesn’t work.
This is another one that’s kind of like problem #2 — essentially the events aren’t getting hooked up properly in global.asax.cs. One of the things that I saw is that sometimes my global.asax.cs’s had two methods in them: Global_AuthenticateRequest() and Application_AuthenticateRequest(). Sometimes there’d be code
Solution(?): This one was extra difficult. Maybe I’m just being cranky here but I didn’t think that the documentation was all that great about how to hook up to events in the global.asax of a VS2005 Web Application Project (I’ve done it in VS2005 Web Site projects before — the documentation was somewhat hazy there, too.)
It looks like the easiest way to solve this problem is to name your AuthenticateRequest method “Application_AuthenticateRequest” and be done with it.
protected void Application_AuthenticateRequest(object sender, EventArgs e)
Context.User = new SecurityPrincipal(new SecurityIdentity());
If you do this, make sure that you don’t have any explicit subscriptions to the AuthenticateRequest event inside of the Global() constructor — if you name your method Application_AuthenticateRequest() and you also subscribe to the AuthenticateRequest event, then your auth code is going to get called twice. Check to see if you have something similar to this:
If you see that “this.AuthenticateRequest+=” line in your code and you already have an Application_AuthenticateRequest() method, you probably want to delete the “this.AuthenticateRequest+=” line.