In addition to language changes, you need to consider several other things when converting an application. Unlike the language changes, many of which can be caught by the compiler, most of the changes to ASP architecture generate either a runtime error or possibly no error at all. Either way, you need to test each page to be sure you don't produce unexpected results.
One of the major areas of change is in the way ASP.NET applications are configured. In ASP, configuration was largely done in the Registry and the IIS Metabase. With the exception of some security settings, ASP.NET has all its configuration settings in a human-readable XML file called Web.Config. No longer will you use the Internet Services Manager snap-in to change your application settings, because these are largely ignored by ASP.NET. You might want to review Chapter 7, "Application Framework and Configuration," to see exactly what settings can be made in the Web.Config file.
This change will affect you most if you programmatically change the settings either as part of your application or if your application has an installation program that modifies the Web server settings.
For installation purposes, having all the application settings in a file makes things a lot easier. You do not need to make all the settings by hand or write a program that manipulates the IIS Metabase when you distribute the application to the live servers. You now only need to distribute the Web.Config file along with the rest of your application files.
If your ASP application modifies its own settings, that's where you'll find yourself doing most of your work. This might be the case if you have a custom Web-based IIS Manager, such as a front end for a service provider that sells virtual Web accounts. Fortunately, the Common Runtime Library has a number of classes for handling XML files. You can review Chapter 8, "XML in ASP.NET," for the details on accessing and modifying XML files programmatically.
Intrinsic ASP Objects
Only one change that affects your ASP code was made to the intrinsic ASP.NET objects. These objects, such as the Request , Response , and Server objects, are largely backward compatible with ASP, though there are numerous additional methods .
The change is that the Request collections, such as Request.QueryString and Request.Form , no longer return an array of strings. They now return an object of type NameValueCollection .
If only one value is associated with the key you are accessing, you do not need to modify your code. If multiple values are associated with the key, you need to change your code. Don't forget that collections are zero based, and parentheses are required for method calls.
ASP would access the first item in a request collection with multiple values for a key as follows :
The ASP.NET equivalent is as follows:
There were several changes to ASP.NET's page structure. These changes come from added features and fundamental changes to ASP.NET's architecture. Following is a list of these changes:
One of the first things you will notice if you compare an ASP page and an ASP.NET page is the different directives at the top of the page. In ASP, all directives must be placed on the first line within the same delimitating block, as shown in the following example:
<%@ Language="VBSCRIPT" CODEPAGE="932" %>
In ASP.NET, you are required to place the language directive within a page directive. You can also have multiple directives on a page, specifying a variety of parameters. This can be seen in the following ASP.NET example:
<%@ Page Language="VB" CodePage="932" %> <%@ OutputCache Duration="60" VaryByParm="none" %>
Although still placed at the top of the page by convention, the directives in ASP.NET can be located anywhere on the page.
Mixing Programming Languages
ASP enables you to program in either VBScript or JScript. Optionally, you can install the scripting engine for other third-party languages, such as Perl. You can mix different languages in a single page by declaring them in script blocks.
This has changed in ASP.NET, which enables you to program in Visual Basic .NET, C#, or JScript. You also can access managed components written in C++ and, eventually, other third-party languages. In ASP.NET, unlike ASP, you can use only one language on a given page. Different pages in the same application can be written in different languages, but languages can't be mixed on a single page. The use of multiple languages on a single page was made largely unnecessary by allowing the easy use of managed components written in any of the languages.
In ASP, you can declare functions between your code delimiters like this:
<% Function DoSomething() Return 10 End Function %>
In ASP.NET, this is no longer allowed. You must declare your functions within a script block, like this:
<script language="vb" runat="server"> Function DoSomething() Return 10 End Function </script>
This is because of a major architectural change between ASP and ASP.NET. In ASP, each page is a standalone script file, and code delimiters and script blocks are handled in virtually the same way.
In ASP.NET, the code between the delimiters and the HTML is converted to what is basically the Render method of the associated System.Web.UI.Page object. Because subroutines cannot be declared within other subroutines, you can no longer declare functions between the code delimiters.
Render functions in ASP are functions that contain embedded HTML blocks within the function. Here is an example of a render function:
<% Sub RenderFunction() %> <H1>Render Output</H1> <% End Sub %>
This is no longer allowed in ASP.NET. In ASP.NET, subroutines defined in script blocks are not allowed to contain embedded HTML. In fact, HTML blocks are not allowed to be embedded in script blocks at all. Script blocks are processed separately from the .aspx page and are assumed to contain only code. The preceding subroutine should be converted to the following code:
<script language="VB" runat="server"> Sub RenderFunction() Response.Write("<H1>Render Output</H1>") End Sub </script>
An even better practice would be to move all function declarations out of the .aspx file and instead make the functions member functions of the System.Web.UI.Page derived class that contains the code behind your page. This enables you to separate your code from your user interface as much as possible, which makes it easier to maintain and debug. Additionally, Visual Studio .NET currently compiles and displays the errors for these .vb or .cs files when you build your Web application, but the default is for the .aspx file to be compiled the first time it is accessed, with the errors being output to the Web browser.
If you use the Session or Application objects, you will be happy to know that you now can save state across multiple Web servers. This is covered in greater detail in Chapter 4, "Response, Application, and Session Objects." If you use this new capability or are migrating your application one segment at a time, you must be aware of a couple of things.
If you save state across multiple servers, you should not store COM objects in the Session or Application objects because this feature of ASP.NET requires the component to be self-serializable. The new managed components can be made self-serializable, unlike COM objects, which cannot. You need to convert any COM objects you intend to store in this way to a managed component or else not use the new state management features.
It is also important to note that ASP and ASP.NET pages do not share Session or Application data. If you are migrating your code incrementally, you will need to either duplicate this information in both systems or develop a custom solution until your application is completely migrated .
Security in ASP.NET is largely the same as that in ASP, though configuration of security in ASP.NET is now done in the Web.config file. You can see this in more detail in Chapter 18, "Security."
The one change that you must be aware of when migrating an ASP application to ASP.NET is that ASP.NET does not do per-request impersonation by default. If you need this feature, you need to enable it in your Web.config file as follows:
<identity> <impersonation enable="true"/> </identity>