Avoid the GAC (and Check My Reasoning)

Here.

The one where I can only come up with two reasons for using the GAC, the first being very difficult to pull off correctly and the second to happen more and more rarely as we move to SOA and .NET.

This post feels very much like "Why do we still need duals?" so if you've got a reason for using the GAC that I didn't list, by all means, let me know!

#3 - because other products force you to use the GAC - like BizTalk Server 2004. Quite annoying and seemingly without reason (like many of the other strange things in this software beast).

What about a shared Web hosting provider? The provider wants to offer some special DLLs that provide extra capabilities (a shopping cart, a polling component, etc.). They want these available to everyone running on their system, but don't want to put them in each directory and: (1) take up extra space in the account; or, (2) deal with the support headaches when the people using the account delete the DLLs because they think they're taking up space and don't need them, and then go looking for their functionality.

I try and avoid the GAC myself. The one situation where I have used it:

I created a new configuration section handler that is defined in MACHINE.CONFIG so that all apps on the server use it. In that case, I felt it was best to put the section handler code in the GAC. Since apps that use it don't have a reference in their web.config, why should they have to have a copy in their bin folder as well? The effect is that the section handler is completely transparent to the app.

Michael says, "Because I'm forced to by my tools." I don't like that reason, but it's real (although it shouldn't be).

Tommy says "Avoid support costs for ISPs." That's not a technical reason, but a good one.

Josh says, "Extending the platform seamlessly." I admit that "seamless" is pretty compelling, but remember that you're on the hook for backwards compatibility if any of those apps program against your types.

We have some PIAs - Visual Studio .NET does _not_ pick them up from the GAC when you add a reference to the COM object, and it doesn't list them on the .NET tab either. You have to write them into a directory VS.NET can find in the HKLM\Microsoft\.NETFramework\AssemblyFolders key (we cheat and write into [PROGRAMFILES]\Microsoft.NET\Primary Interop Assemblies, which you're not really supposed to do).

Be aware that a signed DLL has a different search algorithm to an unsigned one. The system will check the GAC first, then any paths configured, only finally ending up in the same path as the calling component. This caught out someone I was on a course with a few months back; administrators were 'fixing' a broken system by placing a component in the GAC, which wasn't then being upgraded properly. My recommendation is to sign it and install in the GAC, or don't sign it at all - then the admin cannot ever put it in the GAC.

For our new version PIAs, I've created publisher policies to allow components built against the previous version to run on the new one without needing the previous version PIAs. The Publisher Policy documentation could do with, well, I was going to say a polish, but it could actually do with rewriting - it's inaccurate and unclear.

Okay, I'll say it if no one else will :-)

When you're doing an xcopy deployment, why not just statically link an entire executable image? I mean, I guess you could argue that building some functionality into dll's allows you to upgrade that part of the functionality without having to send along the whole exe but honestly, how much less trouble is it to install a new dll than it is to install a new version of the app?

Dynamic Linking, at least as it's currently implemented, seems to be a technology that has not met the cost/benefit test. That is, the cost of using the technology seems to outweigh any benefits that its use confers.

--
Onorio Catenacci

Hi Chris,
We are using it like Tommy and Josh tell.
We host lot of different applications in a server but these applications share some common things like i.e. http handlers for authentication and compression etc. Usin the GAC allows us a better control of this common code rather that need to copy the same dlls again and again, with the problems for updating each one when something changes.
I dont feel the hook for backwards compatibility as if we need to change something in new version we can have both versions in the GAC and each application will continue using the correct one, that is quite similar situation at the one we have if we copy the dlls on each application but with easier control, or am I missing something?.
Regards ,
Jose

One more case I know of. Sometimes, if your .NET assembly is loaded via interop by _another_ application, it's possible the AppBase has already been set to another directory. Then, in some cases, you won't be able to find your dependencies if they are in your own directory. For a certain subset of these cases, the GAC is the only way you can guarantee you can find your dependent assemblies.

How about Visual Studio integration (I suppose this is a subset of the "other tools require it" argument).

I was building two assemblies - we'll call them A.dll and B.dll. B had a bunch of IComponent implementations in it, and I wanted to be able to have this DLL show up in VS.NET's assembly search box by default (the box that shows up with the list of "known assemblies" when you right click and do "add reference" or "customize toolbox").

All you need to do that is to set up a couple registry entries. I did that, and voila, there was my assembly. But there was a catch.

You see, B.dll depends on A.dll. Despite the fact that both DLL's were in the same directory, when VS.NET tried to load assembly B, it didn't find assembly A. So I couldn't use my lovingly crafted components from the toolbox as they were designed.

The solution? Put 'em in the GAC, then VS.NET could load the darn thing and everything worked.

To GAC or not to GAC... that is the question... whether 'tis nobler...

1. Assemblies load from the GAC faster – no security check (they were checked when they were added)

2. If you are loading a .NET assembly from a COM+ process then where does fusion look to load the dll's? In the System32 folder. You don’t want to xcopy your assemblies into system32

3. If you are writing an enterprise app that will be the only app on the boxes you will have done the testing and you may need to share your assemblies across many processes. i.e. Windows Services, COM+ apps, BizTalk, a WebSite etc. Some of these may be on the same box and if you use xcopy you'll have the same dll in multiple places on the same box.

4. If you write a BizTalk AIC in .NET your library assembly will be loaded into the BizTalk process. Where will it look to load your assemblies from? The location of the BizTalk service exe. You don’t want to have to install your own assemblies in another products folders.

Am I the only one who wondered about the question "Why do we still need *duels*?" (instead of what it actually said!)?

I don't recall all the details, but my first real .NET project included some assemblies that acted as COM objects via COM callable wrappers.

We could not get them instantiated via COM unless they were in the GAC - specifying a codebase parameter when registering the assemblies did not work for some reason.

To share code accross multiple asp.net Applications. Pretty common. (Sorry if someone else said this and I missed it).

First, I must say the first that ever caught my attention about .NET is the Xcopy deployment. So, yes I too dislike the registry and GAC for that matter.

I could be mistaken but I was thinking of security. As some folks have pointed out about ASP.NET sharing DLL’s, but more specifically, if an app needs a certain level of permissions (Code Access Security rights) like File IO but the rest of the App has can have lower rights. One could foreseeably install the component into the GAC with elevated rights (may be run under partial trust) and call that component from the rest of the app that would have lower permissions, preventing opening up the security to the entire App that was XCopied. I guess this is the shared idea but with a security twist.

As for the faster execution and all those arguments, well 4Ghz are probably around the corner and most of the times the bottleneck for apps is memory. Besides make the pretty Splash screen display a nano second longer.

Just some thoughts.

Chris, I think you may want to talk with Suzanne (http://blogs.msdn.com/suzcook/archive/2003/06/13/57180.aspx). I have talked with her on her blog comments and I was pretty much persuaded that I should prefer GAC. You are definitely smarter than me and you may discuss with her what I am still in doubt.

Hi,

I think ILMerge does just that and more - it packs assemblies into one so you end up with one executable if you want to.
http://research.microsoft.com/~mbarnett/ilmerge.aspx

The post below is answer to Onorio...

I think your reasoning makes sence. There is however a small problem. I you are working with Windows.Forms then MS recomends that we ngen thoose assemblies since there is a lot of code executing at startup we want to avoid that performance hit that we get from the jitter.

Using ngen puts the code into the gac...
or atleast the native image... but sofar the only company that uses ngen on a wide basis is MS and all their stuff is alread in the GAC so they probably doesn't care...

I'll try this again. I was thinking about the underlying reasoning in your post and it led me to these thoughts.

Is it possible that the way things are designed is a flaw in Microsoft's thinking? I've been using MS stuff for a long time and there has rarely been any high level interest configuration management and easing the pain of deployment and infrastructure management.

.NET has designed some ways to ease the pain, but still, is there a top to bottom push for helping developers manage code and the resulting deliverables? I see a few development tools coming down the pipe (MS-Build), but VSS is still the company standard and is ancient.

This is where the Rational ClearCase folks, although possibly overkill, have really lept ahead of MS's thinking.

Config management is something that should be considered while you're building Whidbey and Longhorn. And not just from a developer's point of view. What other roles can be identified?

I think the underlying concern that Chris has is that the resulting duel system really comes from a lack of plan in the past.

Is this wrong?

I started writing a reply to this, but it got out of hand, so I posted it here instead:

http://www.interact-sw.co.uk/iangblog/2004/03/17/usethegacluke

(Now I get to find out whether Chris's comment software automatically detects and blocks URLs...)

As I was reading through the comments, I had a thought. Is it possible that the GAC is not necessarily useful now (except in the niche cases listed), but that it is being implemented & tested as part of something bigger & better that we’ll see in the future? I’ll go out on a limb and speculate that the GAC might be considerably more useful in terms of NGSCB. Any thoughts or comments? I’ve also got the same opinion of Code Access Security...

As I was reading through the comments, I had a thought. Is it possible that the GAC is not necessarily useful now (except in the niche cases listed), but that it is being implemented & tested as part of something bigger & better that we’ll see in the future? I’ll go out on a limb and speculate that the GAC might be considerably more useful in terms of NGSCB. Any thoughts or comments? I’ve also got the same theory on Code Access Security...

I guess Chris forgot there is a thing called Platform, and its purpose is to be shared. If you like to copy everything to your app directory, when next time Nimda comes, cross your finger. There is no way you know you are secure.

Of course if you are talking to application developers, I'll buy that. But, please don't generalize your conclusion.

I find it amazing that .NET has been out for, what, about 3 years now, and we still haven't quite figured out the basics yet.

My take: this sxs versioning business is awfully complicated. And adding complexity to the development and deployment of software has never, since I can remember, made for a better end-user experience.

In the end, I'm not sure sxs is any better than COM's "thou shalt not break app-compat" versioning scheme. We've always been free to bump our CLSIDs, if we're afraid of that responsibility...

Benefits of using the GAC :

1-side-by-side deployment and execution
2-improved loading time
3-reduced memory consumption
4-improved search time
5-integrity checking (install time)
6-file security

http://www.interact-sw.co.uk/iangblog/2004/03/17/usethegacluke

Mark Treadwell [1], Junfeng Zhang [2] and Alan Shi all point out that the GAC does have it's uses. It absolutely does, it's just not meant to be the first place you dump stuff.

[1] http://geekswithblogs.net/mtreadwell/archive/2004/03/28/3473.aspx

[2] http://weblogs.asp.net/junfeng/archive/2004/03/29/100777.aspx

[3] http://blogs.msdn.com/alanshi/archive/2004/03/28/100765.aspx

One reason to use the GAC would be that you actually do know what apps rely on the DLL, you actually have documented the changes you are making, and do have the *proper* foresight to know what to expect. So your advice is great, for poorly run shops who will make other mistakes anyway.

Ted also has a differing opinion [1], which boils down to "I can drop different versions of the same assembly into the GAC side-by-side and they'll run properly, so why shouldn't I?" The reason is because you give up xcopy deployment when you use the GAC and if there's no benefit to doing so, what's the point?

[1] http://www.neward.net/ted/weblog/index.jsp?date=20040329#1080551172872

I wanna know what do you do in this scenario:

Build a Class Library Tools.dll, v1.0

Build an asp.net app against Tools.dll,v1.0

Build a webcontrols library against Tools.dll,v1.0

Now, add some more Tools to the Tools.dll, and move to v1.1

If your original AspNet app references ClassLibrary, it has to pull Tools.dll [v1.0] into its bin, but when you go to pull the NEW WebControls w/Tools.dll[v1.1], the v1.1 overwrites v1.0

Read that very carefully, I didnt really have enough time to elaborate. But in essense I believe SxS assemblies are missing one major thing: their Version number in the filename!

Three months late to the discussion, oh well, but I made some points in Alan Shi's weblog relating to deployment. Read them at Alan's link:
http://blogs.msdn.com/alanshi/archive/2004/03/28/100765.aspx

I couldn't agree more. Unfortunately, the product I work on needs to use the GAC, as our functionality is in an MMC snap-in and we cannot force the working directory. *sigh*

There is another reason why should you use the GAC - if your app uses more than one process.
In example lets take an ASP.NET application that uses COM+ (ServicedComponent).
If there are assemblies that are shared for both layers (I.E: ValueObjects).
Registering these assemblies in the GAC saves a big headach...

points are :- I would suggest when should i prefer using GAC:-

1. when i need to provide an important fix to my app.

2.More then true when i need to supply backward compatibilty and my assembly to run in full trust.

3.whenever i needto share a componet between different app(no other way here).

Even though there is significant concern as raised by chris the more is with the approach we followed for our deployment and chris is true to certain extent so as few other's who made commnets in alan shi's response regd the fact that there is no other option to provide a publisher policy for the updates and which is many times a tedious task and there is many problems for related to the same .

However without GAC also some we could have asked for the fact why there is no option avalable for backward compatibility and componet sharing and the GAC hell due to the wrong implementation is far better then DLL hell which we suffered and the Binary compatibility of COM was too tedious and subject to more design restriction then the gac .atleast we can ship the publisher policy separately to avoid the same with few restriction.

Howvere even though the purpose of GAC and the usefull ness of the same are questionable with the above two discussion i found it quite astonishing as how both chris and alan didn't have the issue realted to the dependent assembly load and the control and issue related to using partial load,assembly.load as well as the assembly.loadfrom.

The trust level associated and the way the assembly were searched when it is local ,when it is loaded in a shared network and when it has few dependent assembly has significant changes when we are dealing with private assembly and Gaced assembly

Also when you use reflection to load an assembly and the dependent assembly the gaced and non gaced assembly behaves differently when the assembly are in diff domain as wella s in same domain but out of private path.

PLease commenet on the same.
sndshreeman@rediffmail.com
http://spaces.msn.com/members/shreeman

I have just one question to you.. when MS decides to upgrade .Net framework from 1.0 to 1.1 and 1.1 to 2.0 and so on.. do you expect "ALL" the application on your box [or may be on all boxes in the world] be upgrated to use the new version of .Net framework??? coz we all know, the new release might just not be 100% backward compatible... !!! ??? And I certainly will not qualify this as "hot fix". will you??

Hello Chris,
It does not seem like the GAC Hell issue is still being discussed, but I am facing the same question in my organization and had some thoughts on this.
The problems you have described, will they be addressed if the GAC somehow has a reverse lookup to find out assempblies using a specific version? I think MS still suggests GAC because they expect applications to have their own trace of what versions are being used by what consumers
thanks