把ASP移植到ASP+

来源：互联网发布：上古世纪捏脸兽灵数据编辑：程序博客网时间：2024/05/02 14:21

<a href='http://www.biancheng88.cn/html/2008-11/ASP-67111021.html'>把ASP移植到ASP+</a> 
 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 <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+, 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 <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+. Both 
<a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a> and <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ 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 <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+. 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 <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ 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. <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ 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.QueryString("Language")) 
 
 ' Writes out: VB 
 Response.Write(Request.QueryString.GetValues("Language")(0)) 
%> 
The most common places you are going to find code like the preceding—which requires updating—is in 
places where you have multiple select listboxes, multiple radio buttons or checkboxes with the same name, 
and multiple submit buttons. 
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 <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ 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. 
 
 
-------------------------------------------------------------------------------------------------------- 
 
ASP to <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ Migration (cont'd) 
 
 
 
Semantic Changes: ASP+ also introduces several changes to the basic semantics of the page. From a 
compatibility and migration standpoint, the most important ones boil down to three: 
Only one language per page 
 
Functions must be in script blocks 
 
Render functions are not supported 
<a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a> allowed you to mix more than one scripting language per page. You could write one function in 
JavaScript, another in VBScript, and use them interchangeably on the same page. ASP+ has eliminated this 
capability. In ASP+ only one language is allowed per page. This doesn't mean you can't have client-side 
JavaScript and server-side Visual Basic in the same page. If you really must mix server-side languages in 
a single page, check out the new pagelets capability. Pagelets are miniature ASP+ pages that can be 
embedded in other pages. This allows you to use JavaScript in a pagelet and Visual Basic in the page that 
embeds it. The main reason for this change is the move from scripted languages to compiled languages. With 
a common scripting engine runtime it was relatively easy for multiple interpreted scripting languages to 
share the same symbol table and coexist on a page. With <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ all code is compiled into a class that 
represents the page. Two different languages would require two different compiles with two different 
outputs and two different symbol tables. 
In addition, functions must be placed inside of script blocks. I suspect this is also due to the move from 
scripting languages to compiled languages, but I don't know the exact technical reasons. What it means to 
developers is that instead of: 
 
<% 
 Function MyFunc() 
 
 
 End Function 
%> 
you must now write like this: 
<SCRIPT LANGUAGE="VB" runat=server> 
 Function MyFunc() 
 
 End Function 
</SCRIPT> 
This isn't a big deal, but it's a change that you must make nonetheless. 
Tip: Start placing your functions and subroutines into script blocks today to make the migration easier 
later on. 
 
Render functions are really a specialized form of the fact that functions must be declared in script 
blocks. As a side-effect of the way scripting was implemented, it was possible to write functions like 
this: 
 
<% 
 Function DrawTable() 
%> 
 <table> 
 <tr> 
 <td> 
<% 
 Response.Write "Hello World" 
%> 
 </td> 
 </tr> 
 </table> 
<% 
 End Function 
%> 
This code fragment uses the ASP <% %> escaping syntax to drop from code back to raw HTML. ASP treats these 
chunks of HTML as though they had been emitted using Response.Write and inserts them into the calling 
page. Now that functions must be enclosed in script blocks there isn't an easy way to do escape embedded 
HTML and the above must be changed to look like this: 
<SCRIPT LANGUAGE="VB" runat=server> 
 Function DrawTable() 
 Response.Write "<table><tr><td>" 
 Response.Write "Hello World" 
 Response.Write "</td></tr></table>" 
 End Function 
</SCRIPT> 
VB Language Changes: The final category of compatibility issues doesn't really deal with <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a> itself but 
with the languages it uses. ASP+ no longer uses scripting languages. If you previously used VBScript, all 
that code will be executed using the Visual Basic compiler. Visual Basic itself has had several 
significant changes in this revision and therefore creates additional compatibility issues. There are four 
known issues at this point, although additional ones may crop up as Visual Basic continues to change 
during development: 
Visual Basic no longer has default properties. You must now fully qualify all non-indexed properties to 
identify which property you want. Instead of writing "rsData("Name")" you must write "rsData 
("Name").Value." 
Tip: Prepare for this now by always explicitly specifying the property you want and not relying on the 
default property. 
 
Visual Basic no longer has both a set and a let. Set was originally introduced in Visual Basic 4 to 
differentiate between value assignments and object assignments. Some objects in Visual Basic 4 would 
return either an object or a string. The ActiveConnection property of an ADO command object is an example 
of this. Because of this dual nature, Set was needed to indicate an object assignment and Let was used to 
indicate the string assignment. With the elimination of default properties, however, this is no longer an 
issue. Instead of writing: 
Set cn = Server.CreateObject("ADODB.Connection") 
you can now write: 
cn = Server.CreateObject("ADODB.Connection") 
 
 
Visual Basic now requires parentheses around all subroutine calls. In previous versions of Visual Basic 
they could be used with a single argument but could not be used with more than one argument unless you 
used the Call keyword. In my code this is going to be the one that requires the most cleanup. The common 
case will be the use of Response.Write. Where I previously used it like this: 
Response.Write "Test: " & iCount 
it will now have to be called like this: 
Response.Write("Test: " & iCount) 
 
 
The way arguments are passed to subroutines and functions has changed from VBScript to Visual Basic. In 
VBScript arguments were passed ByRef by default. With Visual Basic arguments are passed ByVal by default. 
Tip: If you rely on the passing of arguments ByRef, explicitly include the keyword in your code to make 
your code more portable to <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+. 
Performance Considerations 
Although this is not strictly a migration issue, ASP+ developers will see significant performance 
increases when porting their ASP code if they move all of their variable instances from loosely typed 
variants to strongly typed data types. This one change alone can yield significant performance increases. 
Additionally, rewriting existing COM components as managed code will eliminate many performance penalties 
due to marshalling and threading. 
In summary, ASP+ offers some very cool new features but they aren't entirely free. Migrating from ASP to 
ASP+ will require some work. However, careful attention to the aforementioned issues today will mean that 
your code ports much easier once <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ ships. 
 
 
Chris Kinsman is Vice President of Technology at DevX.com. He is reponsible for the site architecture, 
development, and day-to-day maintenance of the DevX network of sites. 
 
 
ASP to ASP+ Migration (cont'd) 
 
 
 
Semantic Changes: <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ also introduces several changes to the basic semantics of the page. From a 
compatibility and migration standpoint, the most important ones boil down to three: 
Only one language per page 
 
Functions must be in script blocks 
 
Render functions are not supported 
ASP allowed you to mix more than one scripting language per page. You could write one function in 
JavaScript, another in VBScript, and use them interchangeably on the same page. <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ has eliminated this 
capability. In <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ only one language is allowed per page. This doesn't mean you can't have client-side 
JavaScript and server-side Visual Basic in the same page. If you really must mix server-side languages in 
a single page, check out the new pagelets capability. Pagelets are miniature ASP+ pages that can be 
embedded in other pages. This allows you to use JavaScript in a pagelet and Visual Basic in the page that 
embeds it. The main reason for this change is the move from scripted languages to compiled languages. With 
a common scripting engine runtime it was relatively easy for multiple interpreted scripting languages to 
share the same symbol table and coexist on a page. With ASP+ all code is compiled into a class that 
represents the page. Two different languages would require two different compiles with two different 
outputs and two different symbol tables. 
In addition, functions must be placed inside of script blocks. I suspect this is also due to the move from 
scripting languages to compiled languages, but I don't know the exact technical reasons. What it means to 
developers is that instead of: 
 
<% 
 Function MyFunc() 
 
 
 End Function 
%> 
you must now write like this: 
<SCRIPT LANGUAGE="VB" runat=server> 
 Function MyFunc() 
 
 End Function 
</SCRIPT> 
This isn't a big deal, but it's a change that you must make nonetheless. 
Tip: Start placing your functions and subroutines into script blocks today to make the migration easier 
later on. 
 
Render functions are really a specialized form of the fact that functions must be declared in script 
blocks. As a side-effect of the way scripting was implemented, it was possible to write functions like 
this: 
 
<% 
 Function DrawTable() 
%> 
 <table> 
 <tr> 
 <td> 
<% 
 Response.Write "Hello World" 
%> 
 </td> 
 </tr> 
 </table> 
<% 
 End Function 
%> 
This code fragment uses the <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a> <% %> escaping syntax to drop from code back to raw HTML. <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a> treats these 
chunks of HTML as though they had been emitted using Response.Write and inserts them into the calling 
page. Now that functions must be enclosed in script blocks there isn't an easy way to do escape embedded 
HTML and the above must be changed to look like this: 
<SCRIPT LANGUAGE="VB" runat=server> 
 Function DrawTable() 
 Response.Write "<table><tr><td>" 
 Response.Write "Hello World" 
 Response.Write "</td></tr></table>" 
 End Function 
</SCRIPT> 
VB Language Changes: The final category of compatibility issues doesn't really deal with ASP itself but 
with the languages it uses. ASP+ no longer uses scripting languages. If you previously used VBScript, all 
that code will be executed using the Visual Basic compiler. Visual Basic itself has had several 
significant changes in this revision and therefore creates additional compatibility issues. There are four 
known issues at this point, although additional ones may crop up as Visual Basic continues to change 
during development: 
Visual Basic no longer has default properties. You must now fully qualify all non-indexed properties to 
identify which property you want. Instead of writing "rsData("Name")" you must write "rsData 
("Name").Value." 
Tip: Prepare for this now by always explicitly specifying the property you want and not relying on the 
default property. 
 
Visual Basic no longer has both a set and a let. Set was originally introduced in Visual Basic 4 to 
differentiate between value assignments and object assignments. Some objects in Visual Basic 4 would 
return either an object or a string. The ActiveConnection property of an ADO command object is an example 
of this. Because of this dual nature, Set was needed to indicate an object assignment and Let was used to 
indicate the string assignment. With the elimination of default properties, however, this is no longer an 
issue. Instead of writing: 
Set cn = Server.CreateObject("ADODB.Connection") 
you can now write: 
cn = Server.CreateObject("ADODB.Connection") 
 
 
Visual Basic now requires parentheses around all subroutine calls. In previous versions of Visual Basic 
they could be used with a single argument but could not be used with more than one argument unless you 
used the Call keyword. In my code this is going to be the one that requires the most cleanup. The common 
case will be the use of Response.Write. Where I previously used it like this: 
Response.Write "Test: " & iCount 
it will now have to be called like this: 
Response.Write("Test: " & iCount) 
 
 
The way arguments are passed to subroutines and functions has changed from VBScript to Visual Basic. In 
VBScript arguments were passed ByRef by default. With Visual Basic arguments are passed ByVal by default. 
Tip: If you rely on the passing of arguments ByRef, explicitly include the keyword in your code to make 
your code more portable to <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+. 
Performance Considerations 
Although this is not strictly a migration issue, <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ developers will see significant performance 
increases when porting their ASP code if they move all of their variable instances from loosely typed 
variants to strongly typed data types. This one change alone can yield significant performance increases. 
Additionally, rewriting existing COM components as managed code will eliminate many performance penalties 
due to marshalling and threading. 
In summary, <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ offers some very cool new features but they aren't entirely free. Migrating from <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a> to 
ASP+ will require some work. However, careful attention to the aforementioned issues today will mean that 
your code ports much easier once <a href="http://www.biancheng88.cn/html/special/2008-11/ASP/" title="ASP" target=_blank>ASP</a>+ ships. 
 
 
Chris Kinsman is Vice President of Technology at DevX.com. He is reponsible for the site architecture, 
development, and day-to-day maintenance of the DevX network of sites