This article explains the difference between the Classic ASP and ASP.Net and also focuses on the new features in ASP.NET. Let's discuss the differences between these two in detail:
Process Isolation
ASP is running under the inetinfo.exe (IIS) process space and hence susceptible to application crashes due to that the IIS needs to be stopped or restarted. ASP is related to the process isolation setting in IIS. Where as, ASP.Net process is separate from inetinfo.exe (IIS process). Though the entry point into a ASP.Net application is still IIS but it is not related to the IIS process isolation settings.
Non-MS Platform Support
Classical ASP has no mechanism of running itself on non- Microsoft technology platforms like the "The Apache Web Server" (there are some third party products, like ChiliSoft) but, ASP.NET could be run on non- Microsoft Platforms also. Cassini is a sample Web server produced by Microsoft which, among other projects, has been used to host ASP.NET with Apache.
Multi Language Support in WebPage
Only VBScript and Javascript were available for scripting in ASP where as, in ASP.NET there are no such restrictions. The .NET compliant language can be used with ASP.NET including several like C# and VB.NET, where both of them are server-sided languages.
Interpretation Vs Compilation
In ASP, an interpreter like Jscript or VBScript is used to execute the server-side code. When an ASP page is requested, the text of that page is parsed linearly. The content that is not server-side script is passed back as it is to the response. Where as, the server-side script in the page is executed through the appropriate interpreter, and the output is then submitted back to the response. The efficiency of page rendering is affected by this architecture in several ways. Firstly, on the go interpreting of the server-side script. A common optimization for the ASP applications for this side affect is to move a mass of server-side script into precompiled COM components to improve the response time. Secondly, the intermingling server-side evaluation blocks with static HTML is another efficiency concern. It is less efficient than the evaluating a single server-side blocks because the interpreter has to be invoked time and again.
As a rescue, many ASP developers resort to large blocks of server-side script for replacing static HTML elements with Response.Write() invocations instead. Eventually, this ASP model permits the inclusion of different blocks of scripts within a page to be written in different script languages. This may appeal in some ways but it also reduces performance by requiring that a particular page load both scripting engines to process a request that consumes more time and memory if compared to just using one language.
But in ASP.NET, the pages are always compiled into .Net classes housed within assemblies. This class includes both the server-side code and static HTML, so when the page is accessed for the first time, subsequent rendering of that page is serviced by executing the compiled code. All the inefficiencies of the scripting model of traditional ASP are eliminated by this. No longer had any performance difference between compiled components and server-side code embedded within a page observed. Both of them are compiled assemblies now. Also, no performance difference between interspersing server-side code blocks among static HTML elements and writing large blocks of server side code and using Response.Write() for static HTML content. The .aspx file is parsed into a single code file and compiled, its not possible to use multiple
This eliminates all the inefficiencies of the scripting model of traditional ASP. There is no longer any performance difference between compiled components and server-side code embedded within a page they are now both compiled components. There is also no performance difference between interspersing server-side code blocks among static HTML elements, and writing large blocks of server-side code and using Response.Write() for static HTML content. Also, because the .aspx file is parsed into a single code file and compiled, it is not possible to use multiple server-side languages within a single .aspx file.
Debugging benefits
In classic ASP, debugging is a tough task because of limited support due to the interpreted model. In contrast, not only ASP.NET improves the performance over the interpreted model but also provides debugging tools for component developers and pages compiled into classes. The page errors are generated as compiled errors and there is a fir chance that most of them will be discovered at the compilation time instead of runtime due to the fact that VB.Net and C# are strongly typed languages. In addition to this, the tools available to the Windows Forms .Net developer are applicable to the ASP.NET developer.
Server-Side code placement Web Page
In ASP pages you might include the executable code outside the scope of a function within a script block marked as "runat=server" and you may also define a function within a pair of server side script tags. Where as in ASP.Net the former is no longer supported and the latter is also not possible.
A default constructor is provided by the generated class definition, and it would be a compiler error if you try to write a default constructor. For this, you can choose the alternative method of separating the layout from the page logic which consequently gives you a complete control over the class definition. This method is called code-behind.
Deployment Strategies
The components used by pages and deployed in this manner were difficult to update or replace in the Classic ASP. You are required to shutdown the IIS because of the fact that while the application was functioning, it referred to the component file for replacement. So, after taking your web server temporarily offline, you had to replace the file and then restart IIS. But, in ASP.NET it aimed to get rid of the need to stop the functioning Web application whenever the components needed to be updated or replaced.
To attain this, the designers of ASP.NET had to ensure two things: first, that the running application not hold a reference to the component file and second, that whenever the component file was replaced with a new version, that new version was picked up with any subsequent requests made to the application. Both of these goals are achieved by using the shadow copy mechanism provided by the Common Language Runtime (CLR).
New Page Directives
In ASP, the directives are required to be placed on the first line of a page within the same delimiting block. For instance:
<%LANGUAGE="VBSCRIPT" CODEPAGE="932"%>
While ASP.NET required you to place the Language directive with a Page directive, as follows:
<%@Page Language="VB" CodePage="932"%> <%@QutputCache Duration="60" VaryByParam="none" %>
It could be more than one directive lines, which depends on your need. The standard practice is to place the directives in the beginning of the file but you can place it anywhere in your .aspx file.
Threading Issues
The threading model of COM object created using VB within a web-based application is STA (Single Threaded Apartment). ASP worker thread resides in its own STA and hence the compatibility is fine in this case with a little performance hit.
But in ASP.NET, threading model is the Multiple Threaded Apartment (MTA). This means that components that you are using were created for the Single Threaded Apartment (STA) will no longer perform or function reliably without taking some extra precautions in ASP.NET. This includes, but is not limited to, all COM components that have been created using Visual Basic 6.0 and earlier versions. You will be glad to hear that you can still use these STA components without having to change any code. What you need to do is include the compatibility attribute aspcompat=true in a <%@Page> tag on the ASP.NET page. For example, <%@Page aspcompat=true Language=VB%>. Using this attribute will force your page to execute in STA mode, thus ensuring your component will continue to function correctly. If you attempt to use an STA component without specifying this tag, the run time will throw an exception. Setting this attribute to true will also allow your page to call COM+ 1.0 components that require access to the unmanaged ASP built-in objects. These are accessible via the ObjectContext object. If you set this tag to true, your performance will degrade slightly.
Validation & Browser scripting capabilities
- There is no inbuilt facility for the validation of controls in the Classic ASP. For example, checking whether a textbox is left blank, or a combo is selected or not, or if a phone number does not fit a particular pattern for area etc.
- These kinds of validations required the user to write the client side Javascript code.
- It was not less than a headache for the developer to cater the client and server side validations.
- What added to the burden on the developer was the Javascript code to fit a particular Browser. Specific code had to be written to fit a set of browsers and it consumed a lot of time.
But in ASP.NET, In built validation controls are provided which are easy to implement and the developer has to worry the least.
The features provided by ASP.NET validation controls:
- Browser Independent coding: Developer does not have to worry about the browser and how controls would render to.
- Client-Side or Server-Side: The Validation Controls manage the code checking if the client side code is disabled the validation is done on the server side.
Rich Validation set
There are few types of validation which cater to the needs of the validation requirements:
- RequiredFieldValidation Control - Requires that the control not be left blank.
- CompareValidator Control - Used to compare Data in Two Controls
- RangeValidator Control - Used to check for Range validation (also supports various data Types - Date, string etc...)
- RegularExpressionValidator Control - Used to check the complicated patterns in the user input.
- CustomValidator Control - The final control we have included in ASP.NET is one that adds great flexibility to our validation abilities. We have a custom validator where we get to write out own functions and pass the control value to this function.
This control also provides Client side and server side validation of which the Server side validation could be a different function altogether.
Validation Summary
The validation summary control will collect all the error messages of all the non-valid controls and put them in a tidy list. The list can be either shown on the web page (as shown in the example above) or with a popup box.
Conclusion
Classic ASP goes a long way toward simplifying Web programming. It is demanding when it comes to writing a new DDL from the very beginning as compared with the easier task to write some HTML and mingle it with a script. But then Classic ASP is not fee of issues. The ASP pages are mass of unstructured code. It can be compared to the early days of BASIC programming, where achieving a task quickly was possible but the resultant code was often hard to follow. The object model of ASP has multiple inherent or global objects. For instance, for the generation of the content of an HTTP request, script code is written and the content is send to the client using the intrinsic Response object. In the guaranteed situations where only one client is involved in talking to your Web application, this isn't much of a problem. But not many web applications guarantee this. And the reason for this is the way ASP is organized by these intrinsic objects.
ASP.Net improves the classic ASP. The same intrinsic objects still remain in ASP.Net and the scripting can be added anywhere on the page per you requirement. In fact, ASP.NET easily manages and runs most of the ASP pages with .aspx extension.
ASP.Net introduces a lot of new features. Like all the components within .Net, ASP.Net pages too are compiled into the assemblies, which give a performance and security edge. Further, it supports the usage of any .Net language. This means there is no restriction over the use of JavaScript or VB Script on your Web pages. Now, you have an option to use more structured languages.
ASP.Net opens up a whole new programming model with the blend and combination of Web forms, server-side controls, data binding, and Web services.
