Microsoft Common Language Runtime Version 4.0.30319.0.l
Eden Alvardo
Compilers and tools expose the common language runtime's functionality and enable you to write code that benefits from the managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code. Managed code benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.
Compilers and tools can produce output that the common language runtime can consume because the type system, the format of metadata, and the run-time environment (the virtual execution system) are all defined by a public standard, the ECMA Common Language Infrastructure specification. For more information, see ECMA C# and Common Language Infrastructure Specifications.
To enable the runtime to provide services to managed code, language compilers must emit metadata that describes the types, members, and references in your code. Metadata is stored with the code; every loadable common language runtime portable executable (PE) file contains metadata. The runtime uses metadata to locate and load classes, lay out instances in memory, resolve method invocations, generate native code, enforce security, and set run-time context boundaries.
The runtime automatically handles object layout and manages references to objects, releasing them when they're no longer being used. Objects whose lifetimes are managed in this way are called managed data. Garbage collection eliminates memory leaks and some other common programming errors. If your code is managed, you can use managed, unmanaged, or both managed and unmanaged data in your .NET application. Because language compilers supply their own types, such as primitive types, you might not always know or need to know whether your data is being managed.
The common language runtime makes it easy to design components and applications whose objects interact across languages. Objects written in different languages can communicate with each other, and their behaviors can be tightly integrated. For example, you can define a class and then use a different language to derive a class from your original class or call a method on the original class. You can also pass an instance of a class to a method of a class written in a different language. This cross-language integration is possible because language compilers and tools that target the runtime use a common type system defined by the runtime. They follow the runtime's rules for defining new types and for creating, using, persisting, and binding to types.
As part of their metadata, all managed components carry information about the components and resources they were built against. The runtime uses this information to ensure that your component or application has the specified versions of everything it needs, which makes your code less likely to break because of some unmet dependency. Registration information and state data are no longer stored in the registry, where they can be difficult to establish and maintain. Instead, information about the types you define and their dependencies is stored with the code as metadata. This way, the task of component replication and removal is less complicated.
Language compilers and tools expose the runtime's functionality in ways that are intended to be useful and intuitive to developers. Some features of the runtime might be more noticeable in one environment than in another. How you experience the runtime depends on which language compilers or tools you use. For example, if you're a Visual Basic developer, you might notice that with the common language runtime, the Visual Basic language has more object-oriented features than before. The runtime provides the following benefits:
However, the .NET Framework version number doesn't necessarily correspond to the version number of the CLR it includes. For a list of .NET Framework versions and their corresponding CLR versions, see .NET Framework versions and dependencies.
The Common Language Runtime (CLR), the virtual machine component of Microsoft .NET Framework, manages the execution of .NET programs. Just-in-time compilation converts the managed code (compiled intermediate language code) into machine instructions which are then executed on the CPU of the computer.[1] The CLR provides additional services including memory management, type safety, exception handling, garbage collection, security and thread management. All programs written for the .NET Framework, regardless of programming language, are executed in the CLR. All versions of the .NET Framework include CLR. The CLR team was started June 13, 1998.
CLR implements the Virtual Execution System (VES) as defined in the Common Language Infrastructure (CLI) standard, initially developed by Microsoft itself. A public standard defines the Common Language Infrastructure specification.[2]
During the transition from legacy .NET technologies like the .NET Framework and its proprietary runtime to the community-developed .NET Core, the CLR was dubbed CoreCLR.[3] Today, it is simply called the .NET runtime.[4]
Today we are excited to announce the availability of the .NET Framework 4.6.2! Many of the changes are based on your feedback, including those submitted on UserVoice and Connect. Thanks for your continued help and engagement!
This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
You can opt applications that target an earlier version of the .NET Framework into using this functionality by setting an AppContext switch, as demonstrated in the following configuration file. The switch will only be honored when an application in running on the .NET Framework 4.6.2 (or later).
The absence of targeting the .NET Framework 4.6.2 or setting the AppContext switch results in the existing behavior of being blocked from using paths longer than MAXPATH. The behavior is opt-in to maintain backwards compatibility for existing applications.
The DSA base class has also been updated so you can you use FIPS 186-3 support without casting to the new DSACng class. This is the same as the approach that was used for updating RSA and ECDsa implementations, in the two previous .NET Framework releases.
The usability of the ECDiffieHellmanCng class has been improved. The .NET Framework Elliptic Curve Diffie-Hellman (ECDH) Key Agreement implementation includes three different Key Derivation Function (KDF) routines. These KDF routines are now represented and supported by three different methods, as you can see in the example below.
The Windows Cryptography Library (CNG) supports storing persisted symmetric keys on software and hardware devices. The .NET Framework now exposes this CNG capability, as you can see demonstrated in the example below.
You need to use the concrete implementation classes, such as AesCng to use this new capability, as opposed to the more common factory approach, Aes.Create(). This requirement is due to key names and key providers being implementation-specific
Any programs which have registered a custom SignatureDescription handler into CryptoConfig to add support for these algorithms will continue to function as they did in the past, but since there are now platform defaults the CryptoConfig registration should no longer be necessary.
You have probably experienced and investigated the cause of a NullReferenceException. We are part-way through partnering with the Visual Studio team to provide a better debugging experience for null references in a future Visual Studio release.
The debugging experience in Visual Studio relies on the Common Language Runtime debugging APIs for low-level interaction with your code. Today, the NullReferenceException experience in Visual Studio looks like this:
In this release, we extended the CLR debugging APIs to enable the debugger to request more information and perform additional analysis when a NullReferenceException occurs. Using this information, a debugger will be able to determine which reference is null and provide this information to you, making your job easier.
We added support for TLS 1.1 and 1.2 protocols in ClickOnce for .NET Framework versions 4.6.2, 4.6.1, 4.6 and 4.5.2. We would like to thank those who voted for it on UserVoice! You do not need to do any extra steps to enable TLS 1.1 or 1.2 support as ClickOnce will automatically detect which TLS protocol is required at runtime.
Secure Sockets Layer (SSL) and TLS 1.0 are no longer recommended or supported by some organizations. For example, the Payment Card Industry Security Standards Council is in the process of requiring TLS 1.1 or higher for online transactions that meet their specifications.
ClickOnce continues to support TLS 1.0 for applications that do not or cannot upgrade, for compatibility. We recommend analyzing all of your uses of SSL and TLS 1.0. See the KB articles for links to download the hotfix .NET Framework versions 4.6, 4.6.1 and 4.5.2.
Localization is now much easier when using model binding and DataAnnotiation validation. ASP.NET has adopted a simple convention for resx resource files that contain DataAnnotation validation messages:
Using the .NET Framework 4.6.2, you specify DataAnnotation attributes in your model file just like you would in an un-localized application. For the ErrorMessage, you specify the name that you will use in resx file, as you can see in the example below:
SessionStateModule and Output-Cache Module have been improved to enable async scenarios. The team is working on releasing async versions of both modules via NuGet, which will need to be imported into an existing project. Both NuGet packages are anticipated to release within the coming weeks. We will update this post when that happens.
Session State allows you to store and retrieve user session data as a user navigates an ASP.NET site. You can now create your own async Session State Module implementation using the new ISessionStateModule interface, enabling you to store session data in your own way and use async methods.
7fc3f7cf58