The CLR differs between assembly loading, and assembly resolution. One is about finding the assembly, the other is about pulling it in.
- [Narrator] So one of the first things we're going to need to do, is we're going to need to describe the differences between these two terms, the assembly loader and the assembly resolver, because they're in fact two different entities inside of the runtime. The assembly loader is actually that bit of code which takes an assembly once it's been found and unpacks it. It will extract the types, it will do the verification, it'll look for any tampering that might have been done, it'll verify that the strong name is in fact still valid, and so on and so forth. And we invoke the loader directly by using the static method LoadFrom on the assembly class.
Now the loader completely bypasses the resolver. The resolver is the process that we're going to discuss over the next hour or so, talking about which assembly do in fact we want to load. So the resolver's responsibility is to figure out where the assembly is that we want to load, and the loader's responsibility is in fact to lift that up pick it apart and bring those types in as a part of the CLR. Usually this happens pretty transparently.
We will simply declare that an app has a dependency on a library, and behind the scenes the CLR will go ahead and invoke the resolver in order to find that library in order to hand it to the loader. However, through the use of Assembly.Load we can explicitly load an assembly through the resolver, or using, as I said, Assembly.LoadFrom, we can point to a particular file on the file system or in fact any URL, and say go load that and ignore any of the resolution process.
- Loading assemblies
- Resolving assemblies
- Setting a public key status
- Adding strong naming
- Working with policies
- Configuring machines
- Consulting the GAC
- Examining file and HTTP codebase hints
- Probing files and file systems
- Reviewing successful and failed resolutions