bpeikes

Is there anyway to put a directive into app.config which will force the loading of an assembly from a local directory instead of the GAC We have a situation where a developer updated a library which we put into the GAC with a new version which only has the file version number changed even though it has a breaking change for some applications.

As a quick fix, we would like to add a directive to the app.config for the applications which need to use the previous version, so that they will not look for a particular assembly in the GAC.

Is this possible

I've seen the <dependantAssembly> section, but I don't know if when you set the <codeBase> the CLR will not look in the GAC.


Re: Common Language Runtime Force use of local assembly instead of GAC

TaylorMichaelL

You can not force the use of a local assembly over the GAC in the general case. However you can use a versioning policy to redirect to another version. Note however that when code references an assembly from the GAC then it is automatically tied to the older version even if a newer version exists. Therefore if your code was compiled against v1.2 of an assembly then the application will use v1.2 of the assembly even if v1.3 and v1.4 are available. Publisher policies can be used to reconfigure existing apps without recompilation but this is getting more complicated. All this is involved in just determining which version of the assembly to use.

Once the version has been identified the loader has to find the assembly. If this were a development machine then DEVPATH would come into play but we'll ignore that option. Next is how the assembly is referenced. If the assembly was referenced with a public key (which it will be if you compiled against the GAC assembly) then the loader uses the GAC to load it. If it can't find it in the GAC then it uses probing of the local directory to find the assembly.

Michael Taylor - 7/6/07

http://p3net.mvps.org





Re: Common Language Runtime Force use of local assembly instead of GAC

bpeikes

I'm not talking about assemblies with different assemblyversion attributes, but assemblies with the same assemblyversion but two different assemblyfileversion attributes. I have a couple of questions:

1) If the codepath element on a dependantAssembly directive in the app.config is set, the program will still load the assembly from the GAC if it is there

2) You state "If the assembly was referenced with a public key (which it will be if you compiled against the GAC assembly) then the loader uses the GAC to load it.", but I'm under the impression that just because you sign an assembly doesn't mean that it has to be in the GAC. I thought that signing is required if you want to put an assembly in the GAC, but that a signed assembly can exist outside of the GAC as well.





Re: Common Language Runtime Force use of local assembly instead of GAC

TaylorMichaelL

2) Yes a signed assembly is not required to go into the GAC. However whenever a strongly named assembly is referenced (GAC or not) then the GAC is searched first irrelevant of whether it actually resides in the GAC or not. Only by using the simple assembly name (through Assembly.Load or when referencing a non-strongly named assembly) will the GAC not be searched first.

The algorithm used by the resolver is pretty well defined. If an assembly is referenced with a public key then the loader will look in the GAC first. If it finds an assembly with the correct version then it'll load it from there. AFAIK the config file path will not be used provided the file resides in the GAC. Most of the config info is related to determining the version of an assembly to load and not actually identifying where to load the assembly from. Remember that loading assemblies is a two step process: versioning and then locating. Only after failing to find the assembly in the GAC (or if it isn't strongly named) will the config path be examined.

Personally I think you're going to have to go through a lot of hoops to try and circumvent the GAC. Releasing a newer version of an assembly without a versioning change is dangerous at best. The modified assembly should be versioned appropriate and then released. You can then use a versioning policy to "upgrade" applications that need the fix while leaving the remainder of the apps with the original assembly. This would resolve all your problems.

Michael Taylor - 7/6/07

http://p3net.mvps.org