At the heart of the .NET Framework is an execution engine called the Common Language Runtime. Designed from the ground up to support a myriad of programming language styles, the CLR provides a common type system, automatic memory management, support for concurrent execution, and facilitites for interoperating with native Win32 and COM components. Whether you're developing RESTful services using WCF, graphics-intensive desktop applications using WPF, or forms-based web applications using ASP.NET, the CLR provides the foundation for your application's managed execution. This module explores several key services provided by the CLR in support of managed application development on the .NET Framework.
Understanding Managed Code Hi, this is Mike Woodring with Pluralsight and I'm going to be presenting this module on Understanding Managed Code which is a look at the. NET Framework and its core execution engine which is referred to us the Common Language Runtime. I will start with, a look at the elements that comprised the. NET Framework. I'll point out some of the relevant standards that govern the various implementations that exist and then I'll point out what some of the implementations are because a few variations do exist. Then I'm going to focus on the core execution engine which is referred to us the CLR. And this will take a look at the nuts and bolts of how it's actually implemented, you know, what is the CLR on your machine, where is it? And I'll take a look at how it gets initialized or bootstrapped within the context of a running program and then we'll take a look at some of the really core runtime services that the CLR provides which truly characterized Managed code of Manage Execution. In particular, I'm going to take a look at just-in-time or JIT compilation and then the garbage collector. Along the way, I will be using a couple of tools. Some of the tools are geared towards the static analysis of code. Tools hat let you open up and inspect the contents of a managed executable or a managed code binary. And other tools are runtime or debugger-based, tools that allow you to actually peak under the hood so to speak and see the specifics and the details of what it is that we're talking about in a somewhat abstract way.
Assemblies and Versioning In this module, I'm going to look at CLR Assemblies in terms of how code is packaged, loaded and versioned. What I'm going to cover in particular is first of a little bit about types and scoping, in terms of what role assemblies play and how they relate to the types within those assemblies. Then we're going to take a look at assembly naming and that will lead into a discussion of assembly resolution, so I'll be covering both private path probing as this referred to or often referred to as just sort of simple assembly resolution. And then we'll take a look at applying a strong name to an assembly and then the corresponding assembly resolution algorithms. They become available to you once you've given an assembly a strong name. And towards the end, I'm going to cover 2 types of assembly caches which are repositories on a local file system where assemblies can optionally be deployed. One is the Global Assembly Cache or sometimes referred to as the GAC and the other is a native code cache which is populated for using a tool called ngen.
Win32 and COM Interop In this module, I'm going to take a look at the CLR support for interoperating between managed code or dot net code and native code residing either Win132 or in COM. So we'll take a look at the comparison between managed execution and native execution kind of actually consider what those phrases mean and I will describe a metadata-driven partnership that really is at the core of CLR support for interop, so we'll take a look at some specific mechanics in the area of the managed native interop starting with the CLR support for calling out to Win32 DLLs. And we'll take a look at CLR support for calling out to COM components and then the reverse. We'll take a look at COM components and how the CLR supports the COM components or COM clients calling into managed code.