The Common Language Runtime
The CLR is the engine that supports all the .NET languages. Many modern languages use runtimes.
In VB 6, the runtime logic is contained in a DLL file named msvbvm60.dll. In C++, many
applications link to a file named mscrt40.dll to gain common functionality. These runtimes
may provide libraries used by the language, or they may have the additional responsibility of
executing the code (as with Java).
Runtimes are nothing new, but the CLR is Microsoft’s most ambitious runtime to date.
Not only does the CLR execute code, it also provides a whole set of related services such as
code verification, optimization, and object management.
All .NET code runs inside the CLR. This is true whether you’re running a Windows application
or a web service. For example, when a client requests an ASP.NET web page, the
ASP.NET service runs inside the CLR environment, executes your code, and creates a final
HTML page to send to the client.
The implications of the CLR are wide-ranging:
Deep language integration: VB and C#, like all .NET languages, compile to IL. In other
words, the CLR makes no distinction between different languages—in fact, it has no way
of knowing what language was used to create an executable. This is far more than mere
language compatibility; it’s language integration.
Side-by-side execution: The CLR also has the ability to load more than one version of a
component at a time. In other words, you can update a component many times, and the
correct version will be loaded and used for each application. As a side effect, multiple versions
of the .NET Framework can be installed, meaning that you’re able to upgrade to new
versions of ASP.NET without replacing the current version or needing to rewrite your
applications.
Fewer errors: Whole categories of errors are impossible with the CLR. For example, the
CLR prevents many memory mistakes that are possible with lower-level languages such
as C++.
Along with these truly revolutionary benefits, the CLR has some potential drawbacks.
Here are three issues that are often raised by new developers but aren’t always answered:
Performance: A typical ASP.NET application is much faster than a comparable ASP application,
because ASP.NET code is compiled to machine code before it’s executed. However,
processor-crunching algorithms still can’t match the blinding speed of well-written C++
code, because the CLR imposes some additional overhead. Generally, this is a factor only
in a few performance-critical high-workload applications (such as real-time games). With
high-volume web applications, the potential bottlenecks are rarely processor-related but
are usually tied to the speed of an external resource such as a database or the web server’s
file system. With ASP.NET caching and some well-written database code, you can ensure
excellent performance for any web application.
Code transparency: IL is much easier to disassemble, meaning that if you distribute a
compiled application or component, other programmers may have an easier time determining
how your code works. This isn’t much of an issue for ASP.NET applications, which
aren’t distributed but are hosted on a secure web server.
Questionable cross-platform support: No one is entirely sure whether .NET will ever be
adopted for use on other operating systems and platforms. Ambitious projects such as
Mono (a free implementation of .NET on Linux, Unix, and Windows) are currently underway
(see www.mono-project.com). However, .NET will probably never have the wide reach
of a language such as Java because it incorporates too many different platform-specific
and operating system–specific technologies and features.
The CLR is the engine that supports all the .NET languages. Many modern languages use runtimes.
In VB 6, the runtime logic is contained in a DLL file named msvbvm60.dll. In C++, many
applications link to a file named mscrt40.dll to gain common functionality. These runtimes
may provide libraries used by the language, or they may have the additional responsibility of
executing the code (as with Java).
Runtimes are nothing new, but the CLR is Microsoft’s most ambitious runtime to date.
Not only does the CLR execute code, it also provides a whole set of related services such as
code verification, optimization, and object management.
All .NET code runs inside the CLR. This is true whether you’re running a Windows application
or a web service. For example, when a client requests an ASP.NET web page, the
ASP.NET service runs inside the CLR environment, executes your code, and creates a final
HTML page to send to the client.
The implications of the CLR are wide-ranging:
Deep language integration: VB and C#, like all .NET languages, compile to IL. In other
words, the CLR makes no distinction between different languages—in fact, it has no way
of knowing what language was used to create an executable. This is far more than mere
language compatibility; it’s language integration.
Side-by-side execution: The CLR also has the ability to load more than one version of a
component at a time. In other words, you can update a component many times, and the
correct version will be loaded and used for each application. As a side effect, multiple versions
of the .NET Framework can be installed, meaning that you’re able to upgrade to new
versions of ASP.NET without replacing the current version or needing to rewrite your
applications.
Fewer errors: Whole categories of errors are impossible with the CLR. For example, the
CLR prevents many memory mistakes that are possible with lower-level languages such
as C++.
Along with these truly revolutionary benefits, the CLR has some potential drawbacks.
Here are three issues that are often raised by new developers but aren’t always answered:
Performance: A typical ASP.NET application is much faster than a comparable ASP application,
because ASP.NET code is compiled to machine code before it’s executed. However,
processor-crunching algorithms still can’t match the blinding speed of well-written C++
code, because the CLR imposes some additional overhead. Generally, this is a factor only
in a few performance-critical high-workload applications (such as real-time games). With
high-volume web applications, the potential bottlenecks are rarely processor-related but
are usually tied to the speed of an external resource such as a database or the web server’s
file system. With ASP.NET caching and some well-written database code, you can ensure
excellent performance for any web application.
Code transparency: IL is much easier to disassemble, meaning that if you distribute a
compiled application or component, other programmers may have an easier time determining
how your code works. This isn’t much of an issue for ASP.NET applications, which
aren’t distributed but are hosted on a secure web server.
Questionable cross-platform support: No one is entirely sure whether .NET will ever be
adopted for use on other operating systems and platforms. Ambitious projects such as
Mono (a free implementation of .NET on Linux, Unix, and Windows) are currently underway
(see www.mono-project.com). However, .NET will probably never have the wide reach
of a language such as Java because it incorporates too many different platform-specific
and operating system–specific technologies and features.
Tags:
asp.net