Migrating from ASP Pages

I l @ ve RuBoard

Chances are, you'll want any new projects that you start on a Windows platform to take advantage of the new features in the .NET Framework. But you might also need to migrate existing ASP-based application into ASP.NET. The first thing to note here is that you don't have to migrate everything immediately: ASP pages and ASP.NET pages can quite happily coexist on the same Web server or even in the same application, if this suits your purposes.

Language and Code

One main issue with migration is the language barrier . Most ASP applications are written using Visual Basic as the server-side language. If you want to recast these as J# (or C#), you'll obviously need to port the code. However, you've seen that you can use different languages in different pages, so you can migrate your code gradually on a page-by-page basis. You've seen the new <%@ Page %> directive for defining the language for the page that allows you to do this. Even if you decide to leave the code on some pages in Visual Basic, you'll still need to update them slightly due to language changes between ASP and ASP.NET. (See the .NET Framework documentation on Visual Basic for more details.) You also need to be aware of some other issues (some of which we've already covered), such as the need to enclose function definitions in their own <script> tag.

Because most ASP pages contain their functionality inline, you'll probably want to move a lot of this code to code-behind classes. Again, this is not obligatory and your newly migrated ASP.NET pages will work just fine. However, as discussed previously, placing your code in code-behind classes greatly improves the maintainability of your code. In fact, if you convert the filename extension of an ASP page to ASPX and then load it into a Visual Studio .NET project, you'll be prompted to create a code-behind class for the page in which its code can live.

Beyond the language issues, you'll need to ensure that your application continues to function as it always did. The major area of concern here is probably data access. However, you need not worry too much. All ADO code will still work under ASP.NET, but you should see better performance if you port your code to ADO.NET. This is particularly true if you use disconnected recordsets in ADO because the ADO.NET DataSet handles the disconnected scenario far better. You'll also still be able to instantiate and use any COM components from your ASP pages. The main caveat here is if you have COM components that expect to run in a single-threaded apartment (STA). Such components can be loaded only into an ASP.NET page that is itself single threaded. (ASP.NET pages are multithreaded by default.)

To set a page as an STA, you set the AspCompat attribute of the <%@ Page %> directive to true , as shown in this example:

 <%@Pagelanguage="VJ#" AspCompat="true" Codebehind="FeedsHowMany.aspx.jsl" AutoEventWireup="false" Inherits="FourthCoffee.FeedsHowMany" %> 

The User Interface

In addition to application functionality, the other major area to consider when you migrate to ASP.NET is the user interface. Design-time controls are no longer supported, so if your application uses them, you must change them to Web controls. If your ASP pages use regular HTML controls, you must change these as well, although the changes will be minor because ASP.NET provides its own library of HTML controls. You can convert an ASP HTML control into an ASP.NET server-side HTML control by adding a runat ="server" attribute. As long as the control has an id attribute, it will be accessible to server-side script, in much the same way as a server-side Web control.

The sample file MigratedFeedsHowMany.aspx that follows is a migrated version of the FeedsHowMany.asp ASP page shown earlier. The script code has been migrated to J# and the <form> and <input> HTML controls have all had the runat="server" attribute added. The text boxes can be directly accessed from server-side script using the names defined in their id attributes. Migrating this page took only a few minutes, most of it taken up with porting the code from JavaScript to J#.

MigratedFeedsHowMany.aspx
 <%@PageLanguage="VJ#" %> <HTML> <BODY> <formrunat="server" method="post" action="MigratedFeedsHowMany.aspx"> Size:<inputrunat="server" id="SizeField" type="text" name="size"> Filling:<inputrunat="server" id="FillingField" type="text" name="filling"> <inputrunat="server" type="submit" value="Calculate"> <p>Thiswillfeed<%=calculate()%>people</p> </form> </BODY> </HTML> <scriptlanguage="VJ#" runat="server"> intcalculate() { Stringfilling=FillingField.get_Value(); Stringsize=SizeField.get_Value(); intnumConsumers=0; if(filling!=null&&filling.length()!=0&&size!=null&& size.length()!=0) { booleanfruitFilling=(filling.Equals("fruit"))?true:false; intmunchSizeFactor=(fruitFilling?3:1); numConsumers=Integer.parseInt(size)*munchSizeFactor; } returnnumConsumers; } </script> 

Although server-side HTML controls provide a useful mechanism when you convert from ASP to ASP.NET, bear in mind that they're not as powerful as server-side Web controls. Migration is their main purpose, so if you're designing new functionality, you should use Web controls rather than HTML controls.

Caution

Be careful if your migration strategy involves using both server-side HTML controls and code-behind classes. The id attributes defined on the HTML controls are visible to code placed directly in the ASPX page, but Visual Studio .NET does not automatically insert a reference to them in the code-behind, as it does for Web controls. This means that if you want to access your HTML controls from your code-behind class, you must locate them programmatically. This involves writing code that iterates through the components that your page contains to locate controls of the correct type and id .


I l @ ve RuBoard


Microsoft Visual J# .NET (Core Reference)
Microsoft Visual J# .NET (Core Reference) (Pro-Developer)
ISBN: 0735615500
EAN: 2147483647
Year: 2002
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net