What you need: ASP+ PDC Preview

At the Professional Developer Conference 2000 ASP+ Development Lead Scott Guthrie mentioned that Microsoft was guided by the idea that "There is more Internet time ahead of us than behind us." As an ASP developer with hundreds of thousands of lines of code directly affected by this, I am worried. At the same time, I sincerely feel that they made the right decision.

Compatibility Issues
What does Microsoft's decision about selective backwards-compatibility mean for you? At the most basic it means that migrating will require work. All but the most simple pages will likely require changes before they will run correctly under ASP+. Microsoft has made available a migration path from ASP to ASP+. Both ASP and ASP+ will run side by side on the same server without interacting. This means that your ASP applications will continue to run—albeit without taking advantage of new ASP+ functionality—while you are developing your new ASP+ pages. No modifications have been made to asp.dll, and nothing should break by installing ASP+.

This side-by-side operability is accomplished by using separate filename extensions for ASP and ASP+. All ASP+ filename extensions that I have seen so far end in an x (for example, .aspx, .asmx, etc.). The only exception would be new pagelets (miniature ASP+ pages—more about them later) that use the .aspc extension. This means that migration will typically entail copying an .asp file to an .aspx file, testing it, fixing the problems, and then deploying it by relinking the rest of the site to the file with the new extension.

Microsoft has mentioned that by the time the product ships they hope to have a conversion tool ready which will point out incompatibilities and, in some instances, fix them for you. This won't fix all incompatibilities but it will cover the majority. Compatibility issues come in three broad categories: API changes, semantic changes, and language changes.

API Changes: The first set of compatibility issues arise around changes to the core ASP objects. All of the arrays are now 0 index based. In the previous versions some arrays were 1 based and others were 0 based. For consistency, all now use a 0 base.

The second change has to do with the return types of certain objects. In ASP, Request, Request.QueryString, and Request.Form return different results based on what is in them. If I access a page with the following Url—http://localhost/apichanges.asp?Language=VB&Language=C#—and it contains the following code:

<%
    ' Writes out: VB, C#
    Response.Write Request.QueryString("Language")

    ' Writes out: VB
    Response.Write Request.QueryString("Language")(1)
%>

<%
    ' Writes out: VB, C#
    Response.Write(Request.QueryString("Language"))

    ' Writes out: VB
    Response.Write(Request.QueryString.GetValues("Language")(0))
%>

There isn't really much that you can do when writing code to prepare for this change except potentially wrap control access with your own subroutines so that you can centralize the fixes for the API change.

Although changes in the intrinsic objects are easily fixed in ASP pages using script code, what about compiled COM components for which you don't have the source? As it turns out, if your COM components use GetObjectContext to gain access to the intrinsic ASP objects, ASP+ will return to them a copy of the intrinsic ASP objects compatible with ASP. This support is not in the PDC build of ASP+ but will be forthcoming in future builds. That being said, using compiled Visual Basic 6 objects yields a performance penalty in ASP+ of 10 to 15 percent. This is due to the increased cost of marshalling data between managed and unmanaged code as well as threading issues due to ASP+ switching to an MTA thread pool. For the long term this means that you are going to want to rewrite your components using managed code.

Next: Semantic and Language Changes