views:

1248

answers:

3

We have a web application that's deployed to many websites with only frontend changes, the shared backend portion has it's DLL in the GAC so we only have to update that one dll and all the sites get the update.

Is there a way to override the GAC with a DLL in the /bin folder to test out new features before they get released?

+11  A: 

If it has the same version number as the referenced DLL, the GAC gets used.

If you increment the version number, rebuild the website referencing the new version number, put the new version in the /bin directory, then that DLL will be used.

If you do not want to change the version number, you're pretty much out of luck.

When .NET loads strong named assemblies, first it tries to decide what version number to use. It does this via the reference first, then it looks for publisher policies, then it looks for binding redirects in the configuration file.

After it does this, it looks for the assembly in the GAC, then in any codebase specified, then it probes various file system folders for the DLL. If at any one of those steps it finds the right version assembly, it stops.

If you are not changing the version number of your strong named assembly, .NET will find the original one in the GAC and stop looking. Note that because it stops when it finds one, and because looking in the GAC is first, specifying a codebase for your assembly will do no good unless you also specify a new version number.

Adam Sills
This was very helpful, thank you
John Boker
Do I understand this correct? If version 1.0.0.0 is in the GAC but I compile with version 1.0.0.1 and place 1.0.0.1 in my BIN, then GAC is ignored and BIN is used. If I remove the .dll from my BIN then 1.0.0.0 in the GAC will be used even though I compiled with 1.0.0.1?
J.Hendrix
No. If you compile against a strong-named assembly it will require the exact version number, unless there are publisher policy or binding redirects available.
Adam Sills
The publisher policies and binding redirects allow for version # redirection, so if your program is compiled against 1.0.0.0 and there is a binding redirect or publisher policy specifying 1.0.0.1, then that becomes the version it looks for.
Adam Sills
Once version redirection is complete, the assembly loader (fusion) probes various locations for the assembly. If it can't find the right version, you get an exception.
Adam Sills
So in your case, you compiled against 1.0.0.1. If it can't find that version (no matter where it looks), you get an exception.
Adam Sills
A: 

I think I might be saying the same think as Adam Sills, but re-worded it for my understanding. Through my own testing, looks like this is what happens:

  • If your app is compiled with version 1.0.0.0 and 1.0.0.1 is in the GAC, then you can omit the .dll from your /bin.
  • If your app is compiled with version 1.0.0.1 and 1.0.0.0 is in the GAC, then you MUST place the .dll in your /bin to ignore the GAC. A error will occur if the GAC version is older than the required version of your app, unless you include the newer version in your /bin.

I hope this is correct...

J.Hendrix
The .NET Framework will *not* do version redirection of strong named assemblies automatically, at least as of .NET 3.5 (.NET 2.0 runtime). Theoretically .NET 4 could change the rules, but I doubt it.
Adam Sills
Thanks! I now see why my tests worked with different versions. I thought the strong name was just the key you register it with. But I actually have two assemblies registered in the GAC 1.0.0.0 and 1.0.0.1 both with the same public key token. I thought that if I used the same key, 1.0.0.1 would replace 1.0.0.0. But that does not appear to be the case.<br>Thanks @Adam for you help!
J.Hendrix
A: 

Hi

You can view binding information in the log file using the Assembly Binding Log Viewer (Fuslogvw.exe), which is included in the Windows Software Development Kit (SDK).

Muse VSExtensions