Aremyst
Aremyst

Reputation: 1528

Is "CLR" the same thing as ".NET runtime"?

While reading Troelsen's book "Pro C# 5.0 and the .NET 4.5 Framework", I came across those 2 terms. I understand more or less what a Common Language Runtime(CLR) is, but is ".NET runtime" the same thing as CLR ?

I suppose it is.

Upvotes: 5

Views: 2509

Answers (3)

Daniel A.A. Pelsmaeker
Daniel A.A. Pelsmaeker

Reputation: 50306

The Common Language Infrastructure (CLI), defined in standard ECMA-335, describes among other things:

  • the Common Type System (CTS);
  • the Common Language Specification (CLS);
  • the Virtual Execution System (VES);
  • the Common Intermediate Language (CIL).

The VES stands out in this list (it is not Common), and is a description of a hypothetical runtime system. The actual runtime implementation is often called Common Language Runtime (CLR), but this term does not appear in ECMA-335.

There are several implementations of the CLI: the .NET Framework, the .NET Micro Framework, the XNA Framework, Silverlight, the Mono platform, etc... Each platform or framework implements one or more versions of a CLR.

There is Microsoft CLR (aka .NET CLR), often called .NET runtime. There is also a Mono CLR, often called Mono runtime. There are also Silverlight CLR and .NET Compact CLR.

Since Microsoft CLR is the first and most well-known CLR, unqualified use of the term CLR usually refers to no specific version of the .NET runtime. But the CLR is not a specific implementation of a .NET runtime... it is the other way around.

Upvotes: 7

Hans Passant
Hans Passant

Reputation: 941327

The CLR is part of the runtime support that a .NET program needs. Rather a major part, but it is not the only one. You always get a set of native DLLs loaded in a .NET process. You can see them by turning on unmanaged debugging, Project + Properties, Debug tab, tick the "Enable unmanaged code debugging". After you start, you see can those DLLs with the Debug + Windows + Modules window.

I'll document the .NET version 4.5 names:

  • mscoree.dll, the "loader stub". This is the one that gets your .NET program loaded. Windows has special knowledge of this DLL, the loader will automatically transfer control to it when it detects a .NET executable. A very nontrivial thing it does is transmogrify a .NET process into a 64-bit process, even though the EXE header itself indicates a 32-bit process.
  • mscoreei.dll, the default CLR host. The CLR requires a host, code that adapts the CLR to the desired runtime characteristics. Examples of custom CLR hosts are SQL Server and ASP.NET. And the Visual Studio Hosting Process, vshost.exe, active when you are debugging a .NET program. This DLL is also responsible for the side-by-side versioning support built into .NET 4+, permitting a process to have multiple versions of the CLR.
  • clr.dll, that's the CLR
  • clrjit.dll, that's the just-in-time compiler
  • msvcr110_clr0400.dll, the C runtime library. The other DLLs are written in C++, this DLL contains essential runtime support code. You use some it yourself as well, Math.Pow() ends up calling the pow() function in this DLL for example.

You'll also see a bunch of DLLs loaded from c:\windows\system32, the Windows operating system DLLs. Important ones are ntdll.dll, kernel32.dll and user32.dll. Lots more in a typical .NET process. You can't really count them as .NET runtime components since every process in Windows will use these.

Upvotes: 6

Matt Ball
Matt Ball

Reputation: 359786

The Common Language Runtime is a specific implementation of a .NET runtime, but there are others too – namely, the Mono runtime.

Upvotes: 8

Related Questions