What are the difference between ASP and ASP.Net?

Question Posted / poojitha

4 Answers
8377 Views
Accenture, Mphasis, I also Faced
E-Mail Answers

Answers were Sorted based on User's Feedback

What are the difference between ASP and ASP.Net?..

Answer / neelima

Difference between ASP and ASP.NET

------------------------------------------------------------
--------------------
Author: Tony John

HP GDIC

------------------------------------------------------------
--------------------

This article explains what is ASP.NET and how different it
is from ASP.NET

ASP stands for Active Server Pages. ASP.NET is the next
generation of ASP. After the introduction of ASP.NET, old
ASP is called 'Classic ASP'.

Classic ASP uses vb script for server side coding. Vb
Script is not supported any more in ASP.NET. Instead,
ASP.NET supports more languages including C#, VB.NET, J#
etc. VB.NET is very similar to vb script, so it should be
easy for old Visual Basic or ASP programmers to switch to
VB.NET and ASP.NET

VB Script is a simple scripting language, where as VB.NET
or C# are modern, very powerfull, object oriented
programming languages. Just for that reason, you will be
able to write much more robust and reliable programs in
ASP.NET compared to ASP.

In classic ASP, there was no server controls. You have to
write all html tags manually. ASP.NET offers a very rich
set of controls called Server Controls and Html Controls.
It is very easy to drag and drop any controls to a web
form. The VS.NET will automatically write the required HTML
tags automatically for you.

ASP is interpreted, ASP.NET is compiled

Is This Answer Correct ?

13 Yes

1 No

What are the difference between ASP and ASP.Net?..

Answer / chauhan rakesh botad

ASP:
1) ASP is Interpreted language based on scripting languages
like Jscript or VBScript.
2) ASP has Mixed HTML and coding logic.
3) Limited development and debugging tools available.
4) Limited OOPS support.
5) Limited session and application state management.
6) Poor Error handling system.
7) No in-built support for XML.
8) No fully distributed data source support.

ASP.Net:
1) ASP.Net is supported by compiler and has compiled
language support.
2) Separate code and design logic possible.
3) Variety of compilers and tools available including the
Visual studio.Net.
4) Completely Object Oriented.
5) Complete session and application state management.
6) Full proof error handling possible.
7) Full XML Support for easy data exchange.
8) Fully distributed data source support

ASP stands for Active Server Pages. ASP.NET is the next
generation of ASP. After the introduction of ASP.NET, old
ASP is called 'Classic ASP'.

Classic ASP uses vb script for server side coding. Vb Script
is not supported any more in ASP.NET. Instead, ASP.NET
supports more languages including C#, VB.NET, J# etc. VB.NET
is very similar to vb script, so it should be easy for old
Visual Basic or ASP programmers to switch to VB.NET and ASP.NET

VB Script is a simple scripting language, where as VB.NET or
C# are modern, very powerfull, object oriented programming
languages. Just for that reason, you will be able to write
much more robust and reliable programs in ASP.NET compared
to ASP.

In classic ASP, there was no server controls. You have to
write all html tags manually. ASP.NET offers a very rich set
of controls called Server Controls and Html Controls. It is
very easy to drag and drop any controls to a web form. The
VS.NET will automatically write the required HTML tags
automatically for you.

ASP is interpreted, ASP.NET is compiled

Since ASP uses vb script, there is no compilation. All ASP
pages are interpreted when th page is executed.

ASP.NET uses modern .NET languages like C#, VB.NET etc. They
can be compiled to efficient Microsoft Intermediate Language
(MSIL). When you compile an ASP.NET application, the server
side code is compiled to assemblies. These assemblies are
loaded at run time which makes the ASP.NET pages perform
better than classic ASP.

ADO and ADO.NET

Classic ASP uses a technology called ADO to connect and work
with databases. ASP.NET uses the ADO.NET technology (which
is the next generation of ADO).

Event driven programming

If you have written Visual Basic programs before, you would
love the event driven programming approach. It is so easy to
drag and drop a button control and double click on the
button to write the event handler for the button click
event. When you click on the button at turn time, it will
execute whatever code you have written in the event handler.

This type of event driven programming was not available with
classic ASP. You cannot drag and drop a button and write a
'on click' event handler with ASP.

With ASP.NET, this is changed. It works pretty much like
your Visual Basic program. You can write event handlers for
several events like button click event, text changed event etc.

However, there is big difference between the way event
handling works in regular Visual basic and ASP.NET. In
ASP.NET, a page is loaded in the client browser. And the
server may be in another location (may be in another
country). When you click on the button in an ASP.NET page,
the 'click event' handler has to be executed on the server,
not on the client.

How does the server know when you click on a button your
browser? This is a tricky thing in ASP.NET. When you write
an event handler for a button lick or something like that in
ASP.NET, lot of things happens behind the screens. ASP.NET
will produce lot of client side javascript code to handle
this and embed this javascript in the html page it sends to
the browser. When you click on the button in the browser,
the client side javascript will get executed. This
javascript will generate some information required for the
server and and submit the page request to the server. There
is enough information embedded in this request so that the
server will understand that user has clicked a specific
button in the browser and it has to execute some 'specific
event handler' code in the server side. So, when the user
clicks on a button, the page is submitted automatically to
the server with some special information. In the server
side, it will process the event handler for the button click
event and send back the output page to the browser again.
Similary, you can write other event handlers like text
changed event for Textboxes etc.

As a user of the web page, you will not even know what
happened in the background. All you can see is, when you
clicked the button, it executed the button click event
handler in the server side and you got the result. However,
you may notice a delay because the page has to be submitted
to the server to execute the event handler.

NOTE: The event handling we just discussed is server side
event handling. In addition to that, you can handle any
events in the client side using Javascript. This is
supported even in classic ASP. The client side event
handling is used for simpel client side validation,
displaying messages to the user etc. You cannot do any
server side programming in client side java script (like
accessing the database etc).

What You Need

If you have a Beta version of ASP.NET installed, we
recommend that you completely uninstall it!

Or even better: start with a fresh Windows 2000 or XP
installation!
Windows 2000 or XP

If you are serious about developing ASP.NET applications you
should install Windows 2000 Professional or Windows XP
Professional.

In both cases, install the Internet Information Services
(IIS) from the Add/Remove Windows components dialog.
Service Packs and Updates

Before ASP.NET can be installed on your computer, all
relevant service packs and security updates must be installed.

The easiest way to do this is to activate your Windows
Internet Update. When you access the Windows Update page,
you will be instructed to install the latest service packs
and all critical security updates. For Windows 2000, make
sure you install Service Pack 2. You should also install the
latest version of Internet Explorer.

Tip: Read the note about connection speed and download time
at the bottom of this page.
Install .NET

From your Windows Update you can now select the Microsoft
.NET Framework.

After download, the .NET framework will install itself on
your computer - there are no options to select for installation.

You are now ready to develop your first ASP.NET application!
The .NET Software Development Kit

If you have the necessary bandwidth, you might consider
downloading the full Microsoft .NET Software Development Kit
(SDK).

We fully recommend getting the SDK for learning more about
.NET, and for the documentation, samples, and tools included.
Connection Speed and Download Time

If you have a slow Internet connection, you might have
problems downloading large files like the Windows 2000
Service Pack 2 and the Microsoft .NET Framework.

If download speed is a problem, our best suggestion is to
get the latest files from someone else, from a colleague,
from a friend, or from one of the CDs that comes with many
popular computer magazines

Is This Answer Correct ?

1 Yes

0 No

What are the difference between ASP and ASP.Net?..

Answer / pradeep kumar

ASP interpreted where as ASP.NET is compiled.

In classic ASP, there was no server controls. You have to
write all html tags manually. ASP.NET offers a very rich
set of controls called Server Controls and Html Controls.
It is very easy to drag and drop any controls to a web
form. The VS.NET will automatically write the required HTML
tags automatically for you.

Is This Answer Correct ?

0 Yes

0 No

What are the difference between ASP and ASP.Net?..

Answer / chauhan rakesh botad

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.
Introduction

These are the list of differences which I came across while
working on ASPand ASP.NET projects.
Background

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.
Description

Process Isolation
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.

But, ASP.Net
The ASP.NET worker process is a distinct worker process,
aspnet_wp.exe, 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 application

Non-MS Platform Support

Classical ASP had no mechanism of running itself on non-
Microsoft technology platforms like the 'The Apache Web Server'

But, ASP.NET

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

In ASP only two languages were available for scripting
VBScript and Jscript/Javascript.

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 languages.)

Interpretation Vs Compilation

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() invocations instead. 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.
Debugging benefits

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 interpreted model.
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.

Server-Side code placement Web Page

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
code-behind.

Deployment Strategies

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
application.

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.

New Page Directives

In ASP you must place all directives on the first line of a
page within the same delimiting block. For example:
<%LANGUAGE="VBSCRIPT" CODEPAGE="932"%>

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.

Threading Issues

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.
But in ASP.NET,

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 need to.

Validation & Browser scripting capabilities

* 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 examples.

* The user had to write the client side Javascript code
for all these kind of validations.

* Client and server side validation both were the
headache of the of the developer.

* Javascript code to fit a particular Browser was also
the developer's burden. 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.

* 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 6 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 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 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
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 updated.
References

* A very indepth look at the differences. - Excellent.

* (W3Schools - Good article)

* A Comprehensive Description of the Difference- Worth
Reading

* A brief difference - Very Good

License

This article has no explicit license attached to it but may
contain usage terms in the article text or the download
files themselves. If in doubt please contact the author via
the discussion board below.