is it better to register dll's to GAC or reference them from bin folder in ASP.NET

Question

and if the answer is "it depends", could you provide a short explanation why ?

Answer 1

GAC is meant to contain assemblies that are shared across multiple applications. If that is the case, you should strong-name the assembly and register it with the GAC.
If not, keep the assembly as a private assembly and reference it as a project/dll reference.

PS: Didn't really get the reference from bin folder part of your question - which bin folder is this?

Answer 2

It is worth remembering that by default, .Net will load a matching assembly from the GAC over one from the local app folder.

In addition, if the assembly is strong name signed, then it is more performant to load it from the GAC. This is because in order to get into the GAC in the first place, the strong name was checked, which means your app doesn't need to do it again when it loads it. If you load a strong named assembly from a local folder, then it will have its strong name checked each time (doesn't take long, but it all adds up). You can only install strong name signed assemblies into the GAC and you'll need admin privilege to do so.

Answer 3

At the risk of drawing downvotes I'm going to fly in the face of popular opinion and say that the GAC should only be used as a last resort (one example I can think of is when you are using biztalk which doesn't give you a bin folder for each application).

The GAC initially seems like a nice way of sharing files between multiple applications. But what happens when you want to update one of these applications? You either have to risk breaking all the apps on the server that make use of it or end up with multiple versions in the GAC. Multiple versions in the GAC is no better than different versions packaged with the individual apps, in fact I'd say it's more confusing.

When you are running a web farm you end up with one GAC per server so deployment of an app to a new server added to the farm is made more complicated if the GAC is used. You also lose the advantage of having a single copy of an assembly on your server.

But forgetting about the multiple servers issue for now, let's say you have a server with 10 apps all making use of the same assembly. You identify a problem with this assembly that only affects two of the apps. Do you update the assembly for all 10 meaning you will have to test all 10 and you might possible break several otherwise working applications? Or do you just update the assembly for the broken applications and update it for the others during the next development cycle? If you prefer the latter approach then I'd say the GAC should be avoided.