Difference between ASP.NET and ASP
Dear friends here is a list of differences of the ASP.NET technology and the
classic ASP technology.Hope it is informative. Please send your feedback or/and
add if you have additional information.
These are the list of differences which I came across while working on ASPand
I have seen many articles on Internet where in I came
across the differences of ASP.NET and ASP. These articles are jumbled across the
websites. I have compiled all those and published this article to give better
understanding on the differences of both.
ASP is run under the
inetinfo.exe(IIS) process space and hence susceptible to application crashes as
a result the IIS needs to be stopped or restarted. ASP is related to the process
isolation setting in IIS.
The ASP.NET worker process is a distinct worker process,
, separate from inetinfo.exe
( IIS process), and
the process model in ASP.NET is unrelated to process isolation settings in IIS.
Note :- IIS is still the entry point to a ASP.NET
Classical ASP had
no mechanism of running itself on non- Microsoft technology platforms like the
'The Apache Web Server'
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.
ASP only two languages were available for scripting VBScript and
But in ASP.NET
We are no longer constrained to the two scripting languages available in
traditional ASP: Any fully compliant .NET language can now be used with ASP.NET,
including C# and VB.NET.
Note :- (C# and VB.Net are both server Side
In ASP, ASP
engine executes server-side code, which is always through an interpreter
(JScript or VBScript). When a traditional ASP page is requested, the text of
that page is parsed linearly. All content that is not server-side script is
rendered as is back to the response. All server-side script in the page is first
run through the appropriate interpreter (JScript or VBScript), the output of
which is then rendered back to the response. This architecture affects the
efficiency of page rendering in several ways. First, interpreting the
server-side script on the fly.As a side effect, one common optimization for ASP
applications is to
move a lot of server-side script into precompiled COM
components to improve response times. A second efficiency concern is that
intermingling server-side evaluation blocks with static HTML is less efficient
than evaluating a single server-side script block, because the interpreter has
to be invoked over and over again. Thus, to improve efficiency of rendering,
many ASP developers resort to large blocks of server-side script, replacing
static HTML elements with Response.Write()
Finally, this ASP model actually allows different blocks of script within a page
to be written in different script languages. While this may be appealing in some
ways, it also degrades performance by requiring that a particular page load both
scripting engines to
process a request, which takes more time and memory
than using just one language.
But in ASP.NET,
In contrast, ASP.NET pages are always compiled into .NET classes housed
within assemblies. This class includes all of the server-side code and the
static HTML, so once a page is accessed for the first time (or any page within a
particular directory is accessed), subsequent rendering of that page is serviced
by executing compiled code. 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.
In classic ASP it was very difficult for us to debug the application. ASP
developers had time to debug application due to limited support due to the
But in ASP.NET In addition to improved performance over
the interpreted model, pages that are compiled into classes can be debugged
using the same debugging tools available to desktop applications or component
developers. Errors with pages are generated as compiler errors, and there is a
good chance that most errors will be found at compilation time instead of
runtime, because VB.NET and C# are both strongly typed languages. Plus, all the
tools available to the .NET developer are applicable to the .aspx developer.
class=docText>Especially if you are using ASP pages it is possible to
include executable code outside the scope of a function within a script block
marked as runat=server, and , it is possible to define a function
within a pair of server-side script tags.
But in ASP.NET,
In ASP.NET it is no longer possible to include executable code outside the
scope of a function within a script block marked as
runat=server, and conversely, it is no longer possible to define
a function within a pair of server-side script tags.
Note also that the generated class definition provides a default constructor
for you, and if you try to define your own default constructor within your page,
it will cause a compiler error. This can be somewhat frustrating if you are
trying to properly initialize elements of your class (such as filling up our
array of values or subscribing to events).
Fortunately, an alternative
technique gives you more complete control over the class definition while
separating the layout from the page logic. This technique is called
In traditional ASP applications, components used by pages and deployed in
this fashion were notoriously difficult to update or replace. Whenever the
application was up and running, it held a reference to the component file so to
replace that file, you had to shut down IIS (temporarily taking your Web server
offline), replace the file, and restart IIS.
But in ASP.NET,
The goals of ASP.NET was to eliminate the need to stop the running Web
application whenever components of that application need to be updated or
replaced that is, updating an application should be as simple as using xcopy to
replace the components on the Web server with the new updated versions. To
achieve this xcopy deployment capability, 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).
Shadow copying of assemblies is something you can configure when you create a
new application domain in .NET. The AppDomainSetup class (used to initialize an
AppDomain) exposes a Boolean property called ShadowCopyFiles and a string
property called CachePath, and the AppDomain class exposes a method called
SetShadowCopyPath() to enable shadow copying for a particular application
domain. The Boolean property turns the mechanism on for a particular application
domain, the CachePath specifies the base directory where the shadowed copies
should be placed, and the SetShadowCopyPath() method specifies which directories
should have shadow copying enabled.
ASP.NET creates a distinct application domain for each application it hosts
in its worker process and for each application domain, it enables shadow copying
of all assemblies referenced in the /bin directory. Instead of loading
assemblies directly from the /bin directory, the assembly loader physically
copies the referenced assembly to a separate directory (also indicated in the
configuration settings for that application domain) and loads it from there.
This mechanism also keeps track of where the assembly came from, so if a new
version of that assembly is ever placed in the original /bin directory, it will
be recopied into the Noteshadow" directory and newly referenced from there.
In addition to shadow copying of assemblies, ASP.NET needs the ability to
create and load assemblies on the fly. The first time an .aspx page is
referenced, as we have seen, it is compiled into an assembly and loaded by
ASP.NET. What we haven't seen is where those assemblies are located once they
are compiled. Application domains also support the concept of a "dynamic
directory" specified through the DynamicBase property of the AppDomainSetup
class, which is a directory designed for dynamically generated assemblies that
can then be referenced by the assembly loader. ASP.NET sets the dynamic
directory of each application it houses to a subdirectory under the system
Temporary ASP.NET Files directory with the name of the virtual directory of that
One consequence of both dynamic assembly generation and shadow copying is
that many assemblies are copied during the lifetime of an ASP.NET application.
The assemblies that are no longer being referenced should be cleaned up so that
disk space usage doesn't become a limiting factor in application growth. In
ASP.NET shadow copied assemblies are removed as soon as possible after a new
version of that assembly is copied, and dynamically generated assemblies that
are no longer used are cleaned up the next time the ASP.NET worker process is
bounced and the particular application associated with the dynamic assemblies is
run again. In general, this means that you shouldn't have to worry about unused
assemblies generated by ASP.NET wasting space on your machine for very long.
In ASP you must place all directives on the first line of
a page within the same delimiting block. For example:
But in ASP.NET, you are now
required to place the Language directive with a Page directive, as follows:
|<%@Page Language="VB" CodePage="932"%> <%@QutputCache Duration="60"
VaryByParam="none" %> |
You can have as many
lines of directives as you need. Directives may be located anywhere in your
.apsx file but standard practice is to place them at the beginning of the file.
Several new directives have been added in ASP.NET. I encourage you to look these
up in the ASP.NET documentation to see how they may benefit your application.
The threading model of COM object created using VB within a web-based
application is STA. ASP worker thread resides in its own STA and hence the
compatability is fine in this case with a little performance hit.
The ASP.NET threading model is the Multiple Threaded Apartment (MTA). What
this means is that components that you are using that 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. I suggest doing this only if you absolutely
- ASP has no inbuilt facility for Validation of controls.i.e, checking whether
a textbox is left blank or not or a combo is selected or not or if a phone
number does not fit a particular pattern for a area and many such
- Client and server side validation both were the headache of the of the
He had to write specific code so that it could fit a set of browsers. It took
lot of the developers time.
But in ASP.NET,
In built validation controls are provided which are as easy to implement and
the developer has to worry the least.
The features provided by ASP.NET
validation controls is :-
- Browser Independent coding :- Developer does not have to worry about the
browser how the controls would render to.
Rich Validation set :-
- 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
There are 6
types of validation which cater to the needs of the validation requirements:
- RequiredFieldValidation Control - Requires that the control not be left
- CompareValidator Control - Used to compare Data in Two Controls
- RangeValidator Control - Used to check for Range validation.(also supports
various data Type - 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 control also provides Client side and server side
validation of which the Server side validation could be a different function
- 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
This article targets to the developers who have directly
started working on ASP.Net and also for the web developers who have migrated
from ASP to ASP.Net. This article is at the draft level and might need additions
which I intend to do.I welcome suggestion or criticism!! I would request to add
as much feedback to this article post as possible. I would keep this post