ASP.NET 1.1 to 2.0 Conversion Continued

So far, I've identified three key issues with the upgrade process:

#1. Automatic Conversion Limitations - The automatic conversion seems to sporadically experience issues converting web pages and user controls that contain a namespace in the codeBehind definition. The strange errors I reported in my previous blog were completely caused by this issue. I found two key changes that needed to be made in the affected files:

The conversion automatically creates a new page or control declartion at the top of the markup code. The declaration looks something like this:

<%@ Page Language="vb" AutoEventWireup="false" Classname="myNameSpace.myPageName" CompileWith="myPageName.aspx.vb" %>

In certain situations, the conversion forgets to add the myNameSpace portion of the class name. This causes the IDE to be unable to link the page with the codeBehind, causing all sorts of confusion. If you see all sorts of strange compilor errors, including objects not being declared, look for this issue.

Another related issue is that VS.NET 2005 no longer needs the autogenerated code created by VS.NET 2003. In fact, if any auto-generated code exists, you end up with the same kinds of errors. It appears that the conversion process attempts to remove this code, but fails in many circumstances. You need to manually remove this section of code from each codebehind page:

#Region " Web Form Designer Generated Code "

'This call is required by the Web Form Designer.
Private Sub InitializeComponent()

End Sub

Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init
'CODEGEN: This method call is required by the Web Form Designer
'Do not modify it using the code editor.
InitializeComponent()
End Sub

#End Region

I feel like this process is going to end up being fairly time-consuming in my case, as I have about 300 forms to fix. I'm dreading the fact that I may end up going through this process again when we are actually ready to switch over to ASP.NET 2.0...that is, if they don't fix the conversion process before then.

#2. ASP.NET 1.1 Page Paradigm vs. ASP.NET 2.0 Master Pages - Master pages are a great new tool available in ASP.NET 2.0, but it appears that the producers of VS.NET 2005 want to ensure you use them. In my current application, I've used user controls to mimic my own version of master pages. Every page in my application has the same format: (Which I apparently can't display, even using PRE tags)

myNamespace:myHTMLHeaderControl tag
form declartion
myNamespace:myPageHeaderControl tag
...content....
myNamespace:myFooterControl
form close tag
myNamespace:myHTMLFooterControl tag


Now, when I attempt to compile the application, every page complains with an error, rather than a warning, that the element form must be included within a parent element. I just went through a recent site overhaul, which led to the present master site layout. The recent overhaul occurred because I wanted to include a form element in every page header. The compilor complained unless the

and

were in the same page. Now, the compilor seems to complain unless and

are all in the same page. I'm guessing that this is where master pages fall into play. I'm really hoping I can run a single clever search-'n-replace to take care of this one.

#3. Could not find any attribute 'NAME' of element 'Hyperlink' - This one makes me mad. In VS.NET 2003, the IDE automatically added the attribute "NAME" to any control that you copy-'n-paste, even when the original control didn't have a name attribute. I guess some older browsers use the name attribute, instead of the ID attribute, in JavaScript code. Suddenly, with VS.NET 2005, all of these NAME attributes are declared illegal, generating errors rather than warnings. I'm really glad that you are actually able to generate XHTML 1.1 Strict code using ASP.NET 2.0, but this is annoying, considering VS.NET put all that crap in my code in the first place. If I invested a little more time in thoroughly understanding Regular Expressions, I could probably strip out all those NAME attributes with a simple AWK script. Again, hopefully the conversion process is updated, and the redundant NAME attributes are automatically removed before the final product is released.

#4. Option Strict disallows late binding: Did I mention that I love the fact that VS.NET 2005 now checks your markup pages, along with your code behind? When I first started this application, I was using the beta version of ASP.NET 1.0, and I hadn't yet developed the best coding practices. A large chunk of the current application code still has pages that don't even use code behind. I simply haven't had the time and energy to dig through all of the ugly .NET code I created during my first weeks/months on the project. Now that VS.NET 2005 won't even compile my application without fixing the bugs, I have no reason not to switch everything over to a nice, clean code-behind model. For instance, the following is no longer permitted:


<%# Container.DataItem("partNo") %>


Overall, I am pretty happy with the automated conversion process, even though it's going to be a headache to get this application to compile successfully. I haven't found a lot on the web on converting projects to VS.NET 2005, so I thought it would be nice to share my experience.

Good luck,

Mark Heimonen