The first step in assembly resolution is to apply version policy.
- [Instructor] So the first thing that the CLR needs to do, is it needs to figure out the version number of the assembly that we're going to talk to. Again remember, an assembly is named in a four part tuple. That is to say, it's friendly name, which in this case is Leb, its version number, its culture code, and its public key token. Public key token, we just derived by providing a strong name to the Leb assembly. And it's going to be some hexadecimal sequence of values. And culture code remains neutral because we're not doing anything internationalization-wise regarding this assembly.
The version number will be the key thing by which the CLR will be able to support side by side executions. So that one point O, one point one, two point O, et cetera, can all live simultaneously with one another. There are three particular places where as developers, and or, potentially system administrators, we can in fact apply these different version policies. In particular, there's application policy, what's known as publisher policy, and then machine policy.
Application policy is contained inside of the application config file. So for example if in our demo code, app dot EXE can have a corresponding configuration file, app dot XE dot config. And this will be where a lot of this configuration information for the given application will appear. Part of that configuration information can include the version policy as directed by application policy. If you're doing this for ASP dot net by the way, this is your standard web dot config within the web application itself.
Publisher policy actually sits in between application and machine policy to act as a way for people who publish components to be able to indicate, instead of using version one dot zero, I'd prefer to use one dot zero dot one. Publisher policy, we're not going to talk about simply because after it was introduced, most people found it a little too confusing to really adopt in any sort of meaningful way. And it exists inside of the runtime to this day, but it's not used very much, if at all.
The third is machine policy, which is a machine-wide configuration. And this policy file actually lives in a configuration sub-directory underneath where the runtime itself is installed, typically under C backslash windows, on a Windows machine, for example. And this will apply globally across the entire machine for any dot net application. Now the key thing to understand is that there is no trumping kind of behavior. There is no notion of application policy overriding what's in machine policy, or vice versa.
In fact, these three policies simply apply in order. So first application policy, then publisher policy, and then machine policy, which can allow for a certain amount of circular behavior. So if application policy says to go from one dot zero, to one dot one, and publisher policy says to go from one dot one to one dot two, and machine policy says to go from one dot two to one dot zero, we end up back at one dot zero. Because we simply apply them in sequential order.
For the most part I'm going to just suggest that most developers would focus specifically and universally on application policy, not worry about publisher policy. And as a matter of fact, you probably shouldn't worry about machine policy as well. Simply because too many places, too many opportunities to change this can create for some really confusing deployment scenarios, very difficult to debug. So I prefer application policy, but regardless, pick one and stick with it.
- 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