Is it bad practice to register assemblies in the GAC?

Question

I have moved a few assemblies to the Global Assembly Cache because they are used by multiple applications i.e. a VB.NET app and an ASP.NET app.

I remember a few years ago when I started in my current role I noticed that the previous developer registered COM DLLs in the System32 folder. I asked about this and Hans Passant replied saying this was poor practice because System32 is for Operating System DLLs. Is it bad practice to register assemblies in the GAC for similar reasons?

My understanding is: if a .NET DLL is accessed my 2 or more applications then put it in the GAC.

related (possibly a duplicate): How do we isolate dependencies for a .Net app deploy in a way which is safe for a strongly-named assemblies? — gnat, Jan 27 '15 at 18:16
@gnat: I don't think this question is a duplicate, since the OP is asking about best practices. This isn't a "how-to" question, but a "should I" question. — Greg Burghardt, Jan 27 '15 at 18:33
@GregBurghardt question points that "Having the dependencies in the GAC makes deployment complex, setting up dev environments a pain, and restricts freedom to choose deployment environments..." — gnat, Jan 27 '15 at 18:34

score 6 · Answer 1 · answered Jan 27 '15 at 19:20

I would recommend Staying away from the GAC as much as you can. Different assembly versions don't always play nice and debugging that can be a real PIA.

From a technical point if two apps use an assembly it is acceptable to place it in the GAC.

In real world usage, the few Kilobites of saved space is not worth the weeks/months of debugging a GAC dependency problem. It's much better (in real practice) to keep an app and it's dependencies as isolated as possible.

score 3 · Answer 2 · edited Nov 23 '22 at 09:12

I would say yes, using the GAC is a "bad practice"... Or better put, it's not a recommended practice for most situations. Case and point, the next version of ASP.NET doesn't even use the GAC (Link).

Some other reasons the GAC is a bad idea:

Deploying assemblies into the GAC can be difficult.
Versioning assemblies in GAC can be difficult.
Configuring permissions to assemblies can be difficult.

And, if anything, my personal experience with the GAC has lead me to avoid it at all costs... :)

score 0 · Answer 3 · answered Jan 27 '15 at 20:17

Using the GAC isn't bad per se (in some situations it may even be required), but you should know what you're doing.

However, some quick tips;

Don't deploy to the GAC if the machine is not yours to command.
Don't deploy to the GAC if you don't use assembly versioning.
Don't deploy to the GAC if you can just use a local bin folder.
Don't deploy to the GAC if you want to use multiple distinct versions in different locations on the machine (unless they differ in major.minor version).

That said;

I wouldn't deploy to the GAC for an ASP.NET scenario. Just use the bin folder in the web application path. Note that ASP.NET looks into the local bin folder before looking in the GAC as well.

Is it bad practice to register assemblies in the GAC?

3 Answers3