The new technology for creating dynamic Web pages is a full rewrite, based on the services of the CLR. To this end, any of the languages offered by .NET will be usable in the ASP.NET pages. Pages bear different extensions to ASP 3.0. So, simple pages take extension '.aspx', while Web Services take '.asmx' (for Assembly). Pagelets, which are a sort of reusable portion of ASP.NET pages, take extension '.aspc'.

A .NET application can therefore happily allow old .asp and .aspx pages to cohabit. Simply put, old-style ASP pages will run via the DLL asp.dll and will not benefit from the CLR's functionalities.

Now, .aspx pages are no longer interpreted but are compiled as MSIL code when first invoked, then run from the intermediate code produced, following the example of JSPs in the J2EE world. The logical result should be an improvement in performance, which Microsoft announces as comparable to that enjoyed by Visual Basic applications when moving to compiled version 5 from version 4.

These deep-rooted changes will entail a number of modifications to the way an ASP page is coded, in addition to the changes caused by the introduction of new concepts in VB.NET. It might be a good idea to become familiar with these modifications now, so as to be prepared for the next ASP applications written in VBScript and minimize the work required to migrate them to ASP.NET. We shall look at the main changes in order to give you an idea of the effort required to migrate from ASP to ASP.NET.

These changes will take place on three levels:

• Changes in the API
• Changes to page structure
• Changes between VBScript and VB.NET

ASP.NET only supports one type of language per page. In DNA, an ASP page could contain alternate sections of JScript and VBScript. In ASP.NET, this would be impossible, as one page leads to the creation of an MSIL code file after compilation.

In ASP.NET, functions must be flanked by HTML <SCRIPT> tags, and it would be impossible to explode an HTML-generating function into different bits. So, you will no longer be able to write:

Instead, you will need to write:

The parentheses around the function-calling parameters are now mandatory. Other compatibility problems will come from the fact that all ASP.NET arrays are 0 based, while in ASP 3, some are 1 based, while others are 0 based.

In VB.NET, parameters will, by default, be passed by value (ByVal); currently, in VBScript, they are by default passed by reference (ByRef). Lastly, VB.NET will no longer support the default values, or keywords Set and Let.

Although these are not critical modifications, they will cost a lot of time, since existing codes will have to be changed if you want to be able to benefit from the capacities of the CLR and the compiled codes. Microsoft is already announcing that migration tools will be provided when the .NET platform is distributed, but there is no harm in getting into good habits.

As for COM components, ASP.NET will be able to make old COM components work by encapsulating them, but they will run outside the managed environment of the CLR, and the context changes between managed and non-managed will be costly in terms of performance. It is therefore highly likely that you will eventually decide to rewrite COM components as COM+ 2.0 components or Assemblies.

The argument that could clinch your decision to use ASP.NET is the introduction of controls on the server side. With these controls, your ASP.NET pages will benefit from visual or non-visual components that provide advanced services: TreeView, ListBox, Calendar, and so on. All these components analyze the type of Web client calling them, and generate a suitable representation. Typically, an entry field will use the client scripting functionalities of Netscape or Internet Explorer (JavaScript or DHTML) to validate the entry, but will validate on the server side for browsers where Javascript is not supported or has been deactivated.