【 tulaoshi.com - ASP 】
                             
                               Before embarking on the inevitable—and not painless—migration to ASP+, it's best to know what 
compatibility issues you'll have to deal with 
by Chris Kinsman  
  Microsoft is set to release an exciting upgrade to ASP later in 2000. This is a major upgrade unlike the 
minor changes from ASP 2.0 to 3.0. Unlike past upgrades, however, this one will not be painless. When they 
designed ASP+, Microsoft had to make the hard decision occasionally to break backward compatibility in the 
interest of improved functionality and features. 
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)
%
then depending on the way I invoke Request.QueryString, I will get differing results. One would have 
thought that the first invocation would return a string array, as opposed to a CSV string. ASP+ has 
changed this model. Now to get the individual items you must call an explicit method to get access to the 
items. Using the same URL as above, the following ASP+ code will provide the same functionality: 
<%
    ' Writes out: VB, C#
    Response.Write(Request