After introducing a Microsoft plan to force full trust all assemblies in the GAC, Shawn Farkas posted follow-up inviting further feeback. Included in his post are six points explaining some of the reasoning behind the change. In my opinion, none of these reasons even begins to justify the change, and I’d like to present some counter-arguments to each. I’ll address each of Shawn’s points in a separate post here, with the individual points and subpoints labeled for ease of discussion.
Starting with point 1…
1.a) “Assemblies in the GAC build up the managed platform that all managed applications can run on.”
Not all assemblies in the GAC are meant to form part of the general .NET platform, just as not all DLLs in the Windows\System32 folder form part of the Windows platform. Microsoft lost the right to assume this the moment every Tom, Dick, and Harry were allowed to put their assemblies in the GAC.
1.b) “In order to build up a platform where any application, trusted or not, can run safely, it makes sense that you need to trust the assemblies making up that platform.”
But that trust need not be blind. See my earlier post on trust decisions for why one might not want to grant full trust to even the most trustworthy assemblies.
1.c) “If you don’t trust an assembly enough for any code to be able to call into it, then the best place for it is probably not the GAC”
i. On inappropriate GACing:
By and large, the decision to place any given assembly in the GAC or not is made by the folks who author and distribute applications, not the folks who run their installation packages. I might decide not to install an app once I find out that it puts assemblies in the GAC in a manner that I find unnecessary (and I’ll be far more likely to make this decision if the change goes through), but I won’t be adjusting someone else’s app or installer to avoid putting their assemblies in the GAC.
ii. On trusting GACed assemblies:
Under v. 1.x rules, one could set policy to grant only partial trust to assemblies in the GAC, so allowing other folks’ apps to put assemblies in the GAC did not necessarily cause a trust problem. The problem is introduced by eliminating the possibility to the restrict GACed assemblies to the permission one feels they actually merit.