Difference between asp and asp.net

But, ASP.Net

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.

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.

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

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.

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.

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.

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.

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 attributeaspcompat=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.

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

In built validation controls are provided which are as easy to implement and the developer has to worry the least.

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

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

• 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