Moving from ASP to ASP.NET

Contents Overview Migration Issues – Good and Bad Structural Differences Page Layout, Languages, Syntax etc. VBScript and VB.NET COM Compatibility Migration Approach Summary

Overview Completely re-designed ASP Model Maintains compatibility wherever possible Breaks compatibility in favor of improved performance Clear separation of Logic from presentation 10x more Features than traditional ASP Re-designed ASP Model – Structured and Object-oriented Gave up backward compatibility in favor of improved performance and better platform which can grow for a long period of time While ASP.NET preserves the majority of ASP's feature set, 100% compatibility between the two was not possible if the platform was to move forward, so there are a few changes to the old way of doing things.

Advantages of ASP.NET Improved Performance and Scalability Extensive list of server side Page Controls Web Farm support Output Caching and Security Options XML Web Service Infrastructure Configuration and Deployment

Migration : Bad News Can’t insert .NET info into existing HTML pages Migrating existing pages from ASP to ASP.NET requires extensive rework Can’t use VBScript ASP and ASP.NET pages can’t share State Management, without effort ASP Model has been completely re-designed. So most pages will require some changes before they can run under ASP.Net ASP and ASP.NET can co-exist but can’t share Session state and Application state

Migration: Good News Preserves Developer’s ASP Skills Improved Performance of compiled code Increased Developer’s productivity ASP and ASP.NET pages can co-exist New file extension .aspx Many more built in objects Many things are possible in .NET that were impossible or difficult before If you have worked with ASP before, ASP.NET programming paradigm will seems familiar to you. No changes to ASP.dll New features like server controls and event handling in ASP.NET help developers build applications more rapidly and in fewer lines of code. It is also easier than ever to separate code from HTML content.

Structural Changes: Layout Scripting Blocks Use <script runat=server /> instead of <%...%> to declare variables and functions Variables declared within <%...%> are accessible to other render blocks only, not to other functions Multiple <script> blocks but same language within the Page <%....%> refer these tags as code-rendered blocks

Replace Functions like <% Sub DoSomething() Response.Write "Hello World!" End Sub DoSomething %> With <script language="VB" runat=server> Sub DoSomething() Response.Write ("Hello World!") </script> <% DoSomething() %> Note parentheses around Write method.

Page_Load Any initialization code which needs to run as soon as page is loaded should be included in the Page_Load event Any code inside <%..%> will be executed when page is rendered – similar to ASP A related Page_Unload is always the last event to be raised during the life-cycle of a page With traditional ASP, code was enclosed within <%…%> tags and page processing began with the first statement following the first <% tag. You can still write code in <%…%> blocks, but it will be executed at render time (in top-down fashion, as in ASP) after the page is loaded.

Render Functions In ASP, page-render functions could be declared with <%...%> blocks: <% Sub RenderFunction() %> <font color="red">Time: <%=Now %> </font> <% End Sub %> <% RenderFunction %> In ASP.NET replace above code with: <script language="VB" runat=server> Sub RenderFunction() Response.Write ("<font color=red> ") Response.Write (“Time: " & Now) End Sub</script> <% RenderFunction() %> Using older versions of ASP, you could insert literal HTML within a procedure body Unlike Active Server Pages (ASP), it is invalid to declare a function or sub routine within a code render block (between <% and %> tags) in ASP.NET.

Page Directives In ASP, a single directive could be placed on the first line, for example: <%@LANGUAGE="VBScript" Debug=“true” %> In ASP.NET, several new directives have been added, Language attribute should be placed within Page directive: <%@Page Language="VB" Debug=“true” %> But for migration purposes, the shorter ASP-style syntax is also supported for the Page directive only Case and quotes are not important.

Language Changes Supports all CLR-compatible languages including VB.NET , C# and JScript.NET Declare default language at the top of the page : <%@Page Language=“c#” %> Only one language per page but can have controls written in different languages Different languages are allowed within the same application

API Changes Fully API-compatible with traditional ASP except for the following: Request(), Request.QueryString() and Request.Form() Traditional ASP returns an array of strings http://localhost/test/Test.aspx?values=45&values=600 <% ‘ Below line outputs: “45, 600” Response.Write Request.QueryString(“values”) ‘ Below line outputs: “45” Response.Write Request.QueryString(“values”)(0) %>

In ASP.NET these collections require an explicit method to access Query String values These are 0 based collections http://localhost/test/Test.aspx?values=45&values=600 <% ‘ Below line outputs: “45, 600” Response.Write(Request.QueryString(“values”)) ‘ Below line outputs: “45” Response.Write(Request.QueryString.GetValues(“values”)(0)) %>

VBScript and VB.NET Migrating VBScript to VB.NET would be the most challenging issue Major Issues No more default properties No more Let and Set Parentheses required for calling Subs and passing parameters Arguments ByVal by default Array Elements start with 0 Property syntax is different IsNull is now IsDBNull for DB

COM Component Compatibility Most COM components should work fine Use Server.CreateObject(progID) for late binding When using single-threaded (STA) COM components, such as components developed using VB, you must include the compatibility attribute aspcompat=true in the Page directive on the ASP.NET page. E.g. <%@Page aspcompat=true Language = VB %> Changes in ASP.NET security model will cause COMException if existing MTS components are used. add a new Local Machine a/c under Default Access Permissions While late binding to components is still supported, early binding is a better choice for performance reasons. Once the COM component is converted to a .NET assembly, you can import it into an ASP.NET page by placing aspcompat directive at the top of the page.

COM: Performance Considerations ASP.NET thread pool is MTA VB5 and VB6 produced STA components Use early binding to increase performance Use TlbImp tool to convert COM components to equivalent .NET Assembly Calls between managed and unmanaged code has marshalling cost Consider re-writing COM components to .NET Assemblies You can also use early-bound, traditional COM components by creating runtime callable wrappers (RCWs), which optimize the performance of calls between unmanaged and managed code. If you convert the STA component to an assembly using TlbImp, the runtime does not detect that the component uses the STA model and does not throw an exception, but your application can suffer from poor performance and possible deadlocks. STA components cannot be used from .NET Framework code modules (compiled .NET assemblies); they can be used only from ASP.NET pages.

ADO Compatibility ADO.NET is evolutionary improvement to ADO – Totally new set of classes Changes are not required to make ADO to work under ASP.NET Add aspcompat attribute to the Page Most changes will be language related ADO will work under ASP.NET but there are significant advantages to migrate to ADO.NET

Steps to convert ASP or HTML Pages to Web Form using VS.NET Add existing ASP or HTML page to the solution and rename the extension to aspx Allow VS.NET to create code-behind page Page directive at the top of the page It also corrects certain HTML syntax Convert existing inline ASP code <%..%> to a class file Convert Client-side script (VBScript or JScript) to Web-Forms ASP.NET code Client script will run without modification in Web Forms pages, since it runs entirely in the browser. However, you might want to re-implement the same functionality in Web Forms server code instead so that there are no browser dependencies in the page.

Optionally convert HTML elements to Web or HTML Server controls Convert Visual InterDev design-time controls (DTCs) to Web Forms controls. Optionally convert HTML elements to Web or HTML Server controls Controls you need to access from the server Other HTML controls will work just fine Optionally convert ADO code to ADO.NET Save the form, compile the project, and view the page in the browser. Look for issues in the Task List and Resolve them When the migration is complete, you can run the page normally. Generally, however, after performing the migration you will want to do further work on the page, such as substituting ASP.NET server controls for existing HTML elements. You should plan for having minimum number of Server controls.

Migration Approach Staged Migration of existing application Does not have to be nothing or all Page-by-Page migration Identify complexity presented by existing ASP implementation ASP.NET provides many advanced features Streamlines web-programming model Start with poor performing parts of the application Pages that are changing significantly New Functionality

Other Recommendations Don’t forget about Server side code when migrating ASP Pages Careful about State Management between ASP and ASP.NET Pages Duplicate Global.asa global variables in Global.asax Centralized Session storage Use Query String/Hidden Variables and Cookies

Summary ASP Applications will not seamlessly upgrade to ASP.NET Will involve some work to port Will continue to work side-by-side Benefits of upgrading to ASP.NET Better performance Easier development Cleaner code Platform to build apps for the future