Do you install your domain DLLs in GAC?

Question

I've been a ASP.NET/WCF developer for most of my .NET developer career so I'm very used to the idea of just having all DLLs sitting in the bin folder of the IIS directory.

However, in a recent project we have to share several DLLs (around 50) between a WCF web service and several .exe programs so one of our team member suggested that we can install these DLLs into the GAC.

I can't see anything wrong with this idea but I just have a feeling that installing domain DLLs such as data access and business logic for a specific product into GAC is wrong because these DLLs are not like System.Data, which is reusable across many different products.

Do you install your product's DLLs into GAC?

Answer 1

Warning, this is a holy war area

I have seen it both ways, if a DLL is shared we generally GAC it( that's our simple rule of thumb ). Basically we dont want multiple occurrences of the same DLL laying around. However, we bypass this rule if the library is unstable aka constantly undergoing changes/new versions.

Some people argue it is better to silo yourself (place in bin), to prevent someone from reinstalling a gac'd dll that could potentially crash your app. In general, whenever you use a shared library, you need to take care when making changes. If you are going to break someone else, you probably want to think about incrementing the version. Then you can deploy both versions to the GAC.

Another argument against placing bin is if you want to install a new version, you have to place it in N different locations.

My bias shows through my answer(I prefer gac over duplication)

Answer 2

Most of the time we don't put application .DLLs on the GAC, this leads to some duplication but, overtime, simplifies problems as versioning (the more apps you have, the more they will evolve at different speeds) which are harder than wasting some (cheap) disk space.