.net - 为什么我不应该使用 GAC？

Question

沿着这条线 stackoverflow 提出了一些问题，例如
What are the advantages and disadvantages of using the GAC
和 When and when-not to install into the GAC?有几个人在网上问过
网站expamle .对于不使用 GAC，我没有任何令人信服的论据。我确信我很天真，但看起来使用 GAC 而不使用它有更多好处(例如性能和版本控制问题)。

为什么我不应该使用 GAC？

Answer 1

Chris Sells 给出的可能是 the best reason for avoiding the GAC在那里你可以:

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.