#1: ASP.NET is compiled and not interpreted.
ASP.NET applications are always compiled and we cannot execute C# code without it being compiled first.
There are 2 stages of compilation:
- C# code which we write is compiled into intermediate language called Microsoft intermediate language (MSIL). This is the reason that .NET is called language independent. All .NET languages are compiled into almost identical IL codes. The first compilation happens when the page is requested for the first time, or through pre-compilation. The compiled file with IL code is an Assembly.
Points to remember here
- ASP.NET applications are not compiled every time. MSIL code is created once and regenerated only when the source is modified.
- If we are building a web project inside Visual Studio, the code is compiled into IL when we compile the project.
- If we are building a projectless website, the code is compiled when we request the page. For both scenarios, compiled code goes to JIT.
- The second stage of compilation happens before the page is actually executed. At this point, the MSIL code is further compiled into low level machine code. This is called JIT, Just in Time compilation.
Point to remember for JIT:
- Before JIT, the compiler needs to know about hardware platform and OS on which application will run on, i.e. 32 bit or 64 bit.
- ASP.NET pages are not compiled every time. Similarly, the native machine code files are cached in a system directory that has a path like: \Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files.
- ASP.NET files are found in a directory with a 2.0 version number
Rather than a 3.5 version number because ASP.NET 3.5 uses the ASP.NET 2.0 engine.
#2: ASP.NET has multiple language support.
Although when we write code, we will choose any single language like C# and VB.NET, but no matter what language we choose, all code had to get compiled ultimately into MSIL, because IL is the only language that the CLR understands. If we compile c# code and look at its IL code, it will be the same for VB.NET code. How this is achieved?
CLS: Common Language Specification defines laws that all languages (C#, VB.NET) using the CLR must follow, such as method overloading etc. So any compiler for any language that generates IL code to be executed in CLR must follow rules defined in CLS. The CLS gives developers the opportunity to work within a common set of specifications for languages, compilers, and data types.
*ILDASM is a Microsoft SDK tool to view IL codes.
#3: ASP.NET comes within .NET Framework.
Within the .NET Framework classes are grouped into a logical, hierarchical container which is called a namespace and each namespace provides different features. They offer features for all kinds of coding that we do, and this is called a Class Library.
So the way we use these class library classes in ASP.NET is same the way we use in other type of .NET applications, like window or standalone. In other words, .NET gives the same tools to Web developers that it gives to rich client developers.
#4: CLR Hosts ASP.NET
When we write code in ASP.Net, we are said to write managed code, code which runs within CLR. So the whole of .NET is referred to as managed code. So ASP.NET also runs inside the runtime environment of the common language runtime. Now this brings many benefits.
- Garbage collection and memory management: The garbage collector keepa running periodically inside the CLR, and it automatically reclaims unused memory for inaccessible objects. As soon as a reference to an object goes out of scope (or your application ends), the object becomes available for garbage collection.
- Type Safety: when we compile an application, .NET adds information in the assembly that has details like classes, member's variables ans data types; this is called metadata. The benefit of this is that other applications can use them when looking for additional files, and the compiler can verify that every call is valid at runtime.
- Multithreading: CLR gives us a pool of threads that various classes can use, which means with one thread we can communicate with web services asynchronously, read files etc.
#5: ASP.NET Is Object-Oriented:
While writing code for ASP.NET, we have full access to all objects in the .NET framework. We can also exploit full Object Oriented programming conventions, i.e. we can create reusable classes, code with interfaces, extend existing classes with inheritance etc, so ASP.NET truly has an Object Oriented language.
Let us understand how. Consider server controls; actually they are an epitome of encapsulation. From the code behind we can access them and manipulate their object to customize their appearance, can bind data into it. Instead of forcing the developer to write raw HTML manually, the control objects render themselves to HTML when the page is finished rendering. In this way, ASP.NET offers server controls as a way to abstract the low-level details of HTML and HTTP programming.
#6: ASP.NET applications are easy to deploy and configure.
Deploying an ASP.NET application is relatively simple because with every installation of .NET framework provides the same core classes, all we need is to copy all the files from a virtual directory on a production server. Just make sure that the host machine has .NET installed.
ASP.NET makes configuration simpler by not relying on IIS for security information such as user information and user privileges. This is possible because ASP.NET keeps settings stored inside the web.config file. The web.config file is placed in the same directory as your web pages. It contains a hierarchical grouping of application settings stored in an easily readable XML format. When you modify an application setting, ASP.NET notices that change and smoothly restarts the application in a new application domain (keeping the existing application domain alive long enough to finish processing any outstanding requests). The web.config file is never locked, so it can be updated at any time.