Strong Name, GAC, and CM questions

bri189a

bri189a

Well-known member
Joined
Sep 11, 2003
Messages
1,004
Location
VA
Still trying to understand the GAC and SN better. In order for something to be in the GAC it has to be SN; Ive learned how to do SN - pretty simple (at this point). I know the purpose of the GAC is not to have to have a billion copies of the same dll on a targeted machine.

Besides this what are some of the advantages to the GAC? I dont know of any, but Im sure there are some.

Is there ever a reason to SN an assembly and not put it in the GAC?

Ive learned how to deploy something into the GAC (and I really think its stupid that if you deploy to the GAC you also have to deploy to the Visual Studio folder so it shows up in in the Add References dialog - if its the GAC, I think it should be there!), but Ive encountered some things in VS2005 that yell at me that I cant use something because its not registered... how are they checking this? Is there a namespace that allows you load things from the GAC without having a reference to it in your references? How come I cant add the assembly manaully (CopyLocal = true rather than false) and get around this error?

Im also trying to find some information (written in laymans terms - MSDN wasnt very helpful on this one) about when you Configure and Assembly of the GAC...specifically what is the Binding Policy and Code Base tabs used for (in a real world example).

Ive recently gotton thrown into the Configuration Management position on my team and Im learning a lot by fire; things are slowing down so Im trying to get on top of the ball. I recently deployed a library and strongly named it and the msi puts it in the GAC. So now I need to learn how to update it for when a fix is needed for some obscure bug is found (because they always have a way of coming out).

Thanks in advance for comments/links.
 
A strong name is always a good idea - even if you never bother installing it into the GAC.
If your library has a strong name then the application compiled against it will only load the correct version of the dll as released by you and will not allow a 3rd party to either modify your dll or substitute a replacement dll of the same name (regardless of the version number).
The idea behind the binding policy is that you can selectively allow applications to use a newer version of a dll (either all apps or on an app by app basis) but without forcing this upgrade out and causing potential compatability issues. As the original manufacturer of the software though you can also provide what is known as a publisher policy and make the upgrade an opt out rather than the opt in approach that is the default.
 
Code project was kind enough to have Chapter 6 from an Apress book that had some good stuff in it. That is an excellent idea about the SN for security...never thought about somebody spoofing a dll but its quite possible now that I think about it. I need to bring that up in our next meeting (thanks)... guess you didnt have any thoughts on the whole specified assembly is not registered part huh? Maybe its just the way they display the error message... I need to do an experiement with dynamically loading assemblies.... I think that will answer my question about loading an assembly in the GAC that isnt referenced in the project.
 
Well I have a pretty solid answer - the only way to directly iterate through the GAC (and therefore load from the GAC) is to use this interface IAssemblyEnum in some obscure manner and its documented in several places not to, so I dont think anybody is loading things dynamically from the GAC - however on a side note I noticed version 2.0 when using Assembly Load will load from the GAC if the assembly name is found in the GAC, but I didnt find anything that specifically didnt say you couldnt load from the GAC if you knew the Assembly name and security policy (using Assembly.Load) - have you ever done something like this - I couldnt get it to work - Ive never been able to load an assembly outside of using the file name.

Thanks again PD for your help tonight.
 
Never come across the error about dlls not being registered before. Is this any DLL in particular?
You can always dynamically load a DLL using Assembly.Load and passing in a string representation of the strong name - something like
Code: 
Dim a As Reflection.Assembly
a = Reflection.Assembly.Load("Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A")
 
You might recall this was the issue I was having with a custom Membership class in V 2.0 for the WebPartManager object last week... I havent played with it since you posted that one example (I had seen it before), so it may just be a matter of making the class in a seperate assembly...need to look at the example. Anyway, didnt know you could load that way, thats way cool.

Um, I noticed when I was looking in the .NET 1.1 Configuration add-in that not all objects are GAC - there is also ZAP (System.Windows.Form is one that is both a GAC and ZAP cache location) - what is ZAP?
 
The ZAP cache is the cache for assembles precompiled with ngen.exe, if a file is in the ZAP then you would also expect to find a copy in the GAC although the reverse isnt the case
 
ngen.exe doesnt make the dll run any quicker, it can make the loading quicker though by removing the need to just-in-time compile methods when they are first used. You might not even notice a difference in a lot of cases between an ngened assembly and a normal assembly.
The precompiled assemblies are also very machine specific (cpu, os, permission and framework version) and would need to be redone if any of several things change otherwise it will just fall back to doing JIT compiles anyway.
 
Back
Top