Sharing and Learning

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 respon sibility 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 deter mining 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.