Join Ted Neward for an in-depth discussion in this video The assembly concept, part of CLR Assemblies Deployment for .NET Developers.
- [Instructor] Let's start the conversation by asking the basic question, what is an assembly? Conceptually speaking, within the Common Language Runtime, an assembly is a unit, it's a fundamental unit, in fact, that something that the Runtime understands as a first-class concept. It's a unit of deployment, meaning this is what we're actually going to be dealing with when we start putting assemblies out onto machines, when we start deploying them potentially across the Internet, and so forth. It's also a unit of version control. We'll see assemblies and version numbers later, in terms of how to describe which version of an assembly we're working with.
These two things combine to make assemblies a unit of reuse, as something that I can simply drop into my project and make use of. We don't talk too much about activation within this particular lecture, but specifically around doing some .NET remoting, the assembly acts as a way to be able to scope some of that activation. And, assemblies play a very big role in .NET's security platform, which we'll talk a little bit about here. From a programmer's perspective, an assembly is a collection of types, to be quite specific about it.
In other words, the classes and the various interfaces and so forth that we work with will belong to an assembly, and the idea is that the assembly gathers these together to form a logical unit of functionality. So you can think about this in either a very small sense, you may want to create a brand new collection type, and you'll introduce that type as its own custom assembly. Or, this logical unit of functionality could be the entirety of your application, although that tends to be a little bit on the big side, and we'd prefer to break things up into smaller pieces.
The important thing to understand is that the assembly provides the CLR with the information it needs. In other words, it's going to provide some code, and it's going to provide some additional data, what we call metadata, to be aware of these type implementations. You create a class, this is going to tell it where this class comes from, who this class extends, and so on and so forth. The thing to understand is that when Microsoft described assemblies, when they created the assembly concept, they were learning from things that had come before, and particularly, their previous experience had been with C and C++ code in Windows, specifically DLLs and some of the issues that arose out of using DLLs, what is commonly referred to as DLL hell.
And so when Microsoft sat down to create the assembly concept, and when they sat down to describe the assembly concept to the .NET developers that would follow, they came up with a number of core principles that describe assemblies. Specifically, and the one that we'll be spending probably the most amount of time here, is the fact that assemblies are self-describing. That is to say, all of the information necessary to understand a particular component is contained inside that component. When we start looking at the assembly, we will notice that you only need the assembly itself, in contrast to previous editions where, for example, again, under C and C++ code under Windows, you had compiled code, but then you also needed a header file in that particular language to be able to understand how the compiled code worked.
Assemblies, completely self-descriptive, meaning that they will actually own everything there. Assemblies are platform-independent. As we'll see, .NET chooses to use a particular file format that actually works across a variety of different platforms, and this is important because it allows the runtime not only to run on different hardware. So now, of course in 2017, we see .NET Core, and .NET Core can run on top of Windows, it can run on top of Linux, it can run on top of a Raspberry Pi if you really want it to.
But the platform-independence nature here also means that the runtime can actually make decisions that are more efficient for this particular hardware than if we made those decisions at the time the code was compiled. We'll also see that assemblies are bound by name, and we'll talk about how that influences how assembly loading takes place. Now we're not going to talk about assembly loading here, that's actually going to be another course within the Lynda.com catalog on CLR assembly resolution, but it's going to take hints off of what we describe here, specifically version naming and what we'll talk about later called strong naming.
Probably one of the most important things to understand, though, is that assemblies are validated. The CLR will actually go through the assembly, it'll tear it apart, it'll look at the code, and it will make certain that nothing is hinky. It will make certain that there is no code here that wasn't present at the time that the thing was compiled, and in that way, it will verify that nobody's trying to tamper with assemblies after they were compiled and deployed.
- Reviewing the concept of assemblies
- Reviewing library assemblies in ildasm
- Working with assemblies and modules
- Working with assembly scope types
- Reviewing assembly names and versions
- Referencing assemblies from managed code