.net – NOT use the GAC

gacnet

There have been a few questions asked along this line stackoverflow such as
What are the advantages and disadvantages of using the GAC
and When and when-not to install into the GAC? and a few people have asked it on the
web expamle. I can't any convincing arguments for not using the GAC. I am sure I am being naive but it seams like there are more benefits (such as performance and version control issues) to using the GAC then not using it.

Why should I NOT use the GAC?

Best Answer

Chris Sells gives probably the best reason for avoiding the GAC where you can:

What this boils down to is that any of the shared spots for updates, whether it's a COM CLSID, windows\system32 or the GAC, are dangerous and should be avoided. And this is why the preferred .NET deployment scenario is "xcopy deployment," i.e. having your own private copy of each DLL that you test and deploy with the rest of your application.

"Aha!" you say. "The GAC supports multiple version of an assembly! When a foo.dll is updated to v1.1, v1.0 sits right along side of it so that your app doesn't break!" Of course, that's absolutely true. But if that's the case, why do you care? I mean, if there's a new assembly available but your app isn't picking it up, what difference does it make?

"Aha again!, you say. "I can put a publisher policy into the GAC along with my assembly so that apps are updated automatically!" That's true, too, but now, like any of the machine-wide code replacement strategies of old, you're on the hook for an awesome responsibility: making sure that as close to 0% of apps, known to you or not, don't break. This is an awesome responsibility and one that takes MS hundreds of man-years at each new release of the .NET Framework. And even with those hundreds of man-years of testing, we still don't always get it right. If this is a testing responsibility that you're willing to live with, I admire you. Personally, I don't have the moral fortitude to shoulder this burden.