VBUG Spotlight
LANGUAGES: ALL
ASP.NET VERSIONS: 2.0
Upgrading to ASP.NET 2.0
What Are the Risks?
By Phil Winstanley
asp.netPRO is pleased to initiate a regular column written by VBUG members. Since 1994, VBUG has been trusted by thousands of people to provide information and resources for developers and development teams. VBUG offers a comprehensive membership package for VB.NET and C# developers, including regional and national events in the United Kingdom. For more information visit http://www.vbug.com.
More often than not, you ll want to be careful when moving to a new version of anything, be it Microsoft Windows, Microsoft Office, or even that game you ve been keeping secret from your better half Just working late at the office, dear ...
ASP.NET is no different; as soon as a new version comes out you can simply go and install it onto all your servers, then wait for the error reports to come in. However, it s much more sensible to take a more cautious and methodical approach to the whole affair.
In this article we ll go through the caveats of upgrading to a new version of ASP.NET and how to get applications to run side by side under different versions of the .NET Framework (while paying special attention to IIS 6 and its rather convoluted way of doing things), as well as running through some of the tools you can use to perform the upgrade on Windows 2003, Windows 2000, and Windows XP.
If It s Not Broken, Why Fix It?
There s an argument and a very good argument at that for leaving something well enough alone if it s working fine. If your business, as many do, relies heavily on the systems and applications you run having a near 100% uptime, then you d do well to avoid sticking any spanners in the works which includes upgrading to new versions of the .NET Framework as soon as they come out.
Take the time to evaluate the new framework; look at the performance enhancements from which you could benefit, but also pay great attention to the breaking changes and other factors that might cause your applications to cease operating in the correct fashion.
What Could Possibly Go Wrong?
Microsoft has done a great job with ASP.NET 2.0; they ve managed to cram it full of wonderful new features with the minimal amount of breaking changes to existing applications as they re upgraded to the new version of the framework. There are, however, some exceptions to this picture of beauty and elegance.
With the new version of ASP.NET, you now get standards-compliant XHTML being rendered as default, so any application you have that relies on its HTML being rendered in a certain way will break by default.
It is possible to force an ASP.NET 2.0 application to render with non-compliant XHTML with a configuration switch in your web.config named enableLegacyRendering, but the option is like the big red button marked Do Not Press it s better for you to adjust your applications so that they can work with XHTML-compliant code. If you wish to preserve the way in which your application renders its HTML, then add an entry like this to your web.config file:
<configuration>
<system.web>
<xhtml11Conformance
enableLegacyRendering="true"/>
</system.web>
</configuration>
Another consideration is with the document type which is added to pages by the default Visual Studio.NET templates for ASP.NET pages. The DOCTYPE added to pages has changed in Visual Studio.NET 2005 from that in Visual Studio.NET 2002/3. Although this doesn t sound like a breaking change, it can be. Internet Explorer and other browsers use the DOCTYPE to determine how to render the HTML they receive.
Here s the Visual Studio.NET 2003 default DOCTYPE:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
Here s the Visual Studio.NET 2005 default DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
These different DOCTYPEs mean that you can take HTML from a page built in Visual Studio.NET 2003, paste it into a page built with Visual Studio.NET 2005, and, if the DOCTYPE isn t changed, the actual output of the pages can be significantly different.
Correcting these rendering issues can be quite simple; make sure your pages use the old DOCTYPE where you need to rely on the way in which Internet Explorer renders your pages, or change your code so that it works in an XHTML 1.1 standards-compliant way (read the full XHTML specification on the W3C site at http://www.w3.org/TR/xhtml1/). To see a comprehensive list of the HTML rendering behavior issues and CSS rendering issues with different DOCTYPE directives, see Lance Silver s article CSS Enhancements in Internet Explorer 6 on MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp.
As well as the switch to XHTML, all the script files that ASP.NET uses have also been changed and updated; in fact, they no longer even reside inside files under each application. All the JavaScript files that ASP.NET 2.0 needs are fed from an HttpHandler named WebResource.axd, which the framework hosts for each application. If you ve written your client-side script to use the ASP.NET JavaScript functions, it s possible that your code will no longer work (the advice here is to move your code away from the ASP.NET client-side code so that your applications are not reliant upon it).
That s the HTML Sorted; What about My Code?
As Microsoft has written ASP.NET 2.0 to encapsulate the common functionality that we found ourselves writing manually in ASP.NET 1.x, it s more than likely that there are new Microsoft classes inside the System namespace that also share a name with classes you have created yourself. Therefore, naming collisions are more than likely when upgrading to ASP.NET 2.0.
There are a couple of things you can do to get around naming collisions. Firstly, rename any classes you have that match classes in .NET 2.0. The other thing you can do is fully qualify all the calls to your classes that might conflict.
Following is an example of a non-qualified class reference; try to avoid these as the compiler will throw a hissy fit when it finds ambiguous references to classes that have naming conflicts with System classes:
using MyCompany;
private void Page_Load(...)
{
MyClass.DoSomething();
}
The simple fix to keep the compiler happy is to fully qualify the class reference by prefixing it with the namespace:
private void Page_Load(...)
{
MyCompany.MyClass.DoSomething();
}
To get a full list of all the classes added to the .NET Framework 2.0, take a look at the Visual Studio 2005 documentation at http://msdn2.microsoft.com/.
The new compilation model of ASP.NET 2.0 can also cause your existing ASP.NET 1.x applications to break when running under the new framework. Pages that reference methods on other pages, where the two pages reside in different folders within your ASP.NET applications, will not compile.
The new compiler for ASP.NET no longer drops all the pages from the ASP.NET application into one mammoth assembly, but instead now creates many smaller assemblies in a way that means only pages within the same folder can see one another.
Additionally, there are some code changes to the .NET Framework API that might stop your existing ASP.NET 1.x applications from compiling under .NET 2.0. For a full list of these changes visit the Compatibility Considerations and Version Changes page on Microsoft s GotDotNet site at http://www.gotdotnet.com/team/changeinfo/default.aspx.
Now to Fix that Spelling Mistake ...
Once you ve gotten your application all sorted, and you ve published it to the Web server, it s only a matter of time before your boss or client asks you to change a bit of text on the About Us page or add a paragraph to the Help user control. In ASP.NET 1.x this was not an issue; you simply fired up the page live on the server and modified the HTML content there.
In ASP.NET 2.0, there s a compilation option that basically strips out all the HTML from ASP.NET pages at compile time, placing the HTML into compiled assemblies, then replacing the content of your files with the immortal line:
This is a marker file generated by the precompilation tool, and should not be deleted!
Now, how do you edit the content if you re using this compilation model? The answer: You can t.
What you need to do is switch to a different compilation model when choosing to publish a site from Visual Studio.NET 2005. This is as simple as checking the box marked Allow this precompiled site to be updatable. , which will preserve all the HTML in your ASP.NET pages and user controls, making your life much simpler when you need to correct that spelling mistake.
Don t Panic!
This article presents ASP.NET 2.0 in a very harsh light, but the items that are highlighted here will be the exception to the rules: 99.999% of ASP.NET sites will upgrade without any problems, and will benefit greatly from the upgrade with increased performance, better HTML output, and a much richer API and development environment for your applications.
ASP.NET 2.0 is a really flash piece of kit; your Web development will become much easier, much more reliable, and an all around nicer experience from the second you install Visual Studio.NET 2005 and write your first line of code in the new development environment.
VBUG member Phil Winstanley is a highly experienced Web developer who is internationally acclaimed and possesses a burning passion for Internet technologies and solution building, specialising in database-driven Web applications using ASP.NET, C#, SQL Server, and XHTML. Writing is a recent adventure for Phil, who s currently writing some chapters for the Wrox title Professional ADO.NET 2: Programming with SQL Server 2005, Oracle, and MySQL. Phil s been awarded Microsoft MVP status for the past few years and is a member of the ASP Insiders, a group of trusted industry experts who provide early feedback to the Web Platforms team at Microsoft. He also helps to run the MsWebDev online community (http://www.mswebdev.org.uk/). Phil doesn t do VB.NET.
