Join Ted Neward for an in-depth discussion in this video Assembly scope types, part of CLR Assemblies Deployment for .NET Developers.
- [Narrator] Now one of the things I mentioned is that one of the purposes of the assembly is to scope types. And what that means is types know the assembly from which they came. Let me show you what I mean by that real quick. Let's go back to the ILDASM view for just a second of People. And in particular, let's look at the ToString implementation. Now ToString, we don't have to really know all of the IL here to understand what I'm about to say. Specifically, notice that when we start to make use of the System.Int32 type, as far as the CLR is concerned, that's not just the name of it.
The full name of this particular type is the assembly from which it came, plus the fully-qualified type name. And the assembly is actually given by this bracketed syntax here. So, fundamentally, as far as the CLR is concerned, what we think of as an int is actually understood to be a System.Int32 that's coming out of the mscorlib assembly. Similarly, you can see the same thing in the next line, when we make use of the String.Format Method, we understand that the class name is System.String.
Again, that's the namespace plus the class name. The "::" is the indicator that this is a member of a class, "Format" is the name of the method we're invoking, and all of this is coming out of the mscorlib assembly. Part of the reason for this, very bluntly, is so that your types and my types don't clash. If, for whatever reason, I decided to create a System.String Method, well, let's be more realistic, I'm probably not going to create a System.String, but chances are good that you may create a class called "Util," and I create a class called "Util," and if we both choose to use the same names, well, now which Util is which? The CLR gets around this by saying, "The assembly becomes a qualifying reference." It's a prefix, if you will.
Normally, the languages that you use are smart enough to know the assembly that it's coming out of. We go back to C# here for a second. When I use the Person type here, Visual Studio looks at the using reference up here, and Studio is smart enough to figure out that the People namespace comes out of this People component over here, this library. Under the hood though, when the C# compiler emits the code, it's going to need to make sure it issues the fully-qualified assembly-referenced names.
And this is one of the reasons why we like having compilers, is because they'll take care a lot of these details for us. The basic reason for all of this, again, is to avoid any sort of ambiguity, so that you can use your classes without any concern about accidentally clashing with my classes. And more importantly, we close off a potential security hole here, because if I could somehow subvert the system into thinking that your code is in fact my code, I might be able to do things that you wouldn't enjoy.
So again, most of the time this is all hidden away for us down inside the Runtime, but when you're looking inside of an ILDASM view, understand that this is the name of the assembly from which this type originates.
- 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