Strong Name, GAC, and CM questions

B

bri189a

Senior Contributor
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; I've 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 don't know of any, but I'm sure there are some.

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

I've learned how to deploy something into the GAC (and I really think it's 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 it's the GAC, I think it should be there!), but I've encountered some things in VS2005 that yell at me that I can't use something because it's 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 can't add the assembly manaully (CopyLocal = true rather than false) and get around this error?

I'm also trying to find some information (written in laymans terms - MSDN wasn't 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).

I've recently gotton thrown into the Configuration Management position on my team and I'm learning a lot by fire; things are slowing down so I'm 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 it's quite possible now that I think about it. I need to bring that up in our next meeting (thanks)... guess you didn't have any thoughts on the whole 'specified assembly is not registered part' huh? Maybe it's 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 isn't 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 it's documented in several places not to, so I don't 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 didn't find anything that specifically didn't say you couldn't load from the GAC if you knew the Assembly name and security policy (using Assembly.Load) - have you ever done something like this - I couldn't get it to work - I've 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
Visual Basic: 
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 haven't 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, didn't know you could load that way, that's 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 isn't the case
 
ngen.exe doesn't 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