Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I would like to know practically what kind of Assemblies should I deploy in GAC.
Case 1: If in my Solution multiple project uses log4net.dll then should it be deployed in GAC?
Case 2: If I have multiple application deployed in a machine each using log4net.dll is this the reason enough to deploy log4net.dll into GAC?
Question: When should I deploy my assemblies into the GAC?
Answer: Never
Actual, honest, Real Answer: Hardly Ever
Discussion
Only drop things into the GAC when multiple apps on the machine will use the assembly, and when the assembly is foundational (likely to be used by multiple apps), when it is signed, and when you expect to almost never update that assembly. Maybe add into that, when having multiple independent versions of a DLL deployed with each application would actually be harmful.
An example of the latter is: suppose you have 2 independent applications, independently developed and independently deployed. Nevertheless, there is a possibbility that they will inter-communicate. They will exchange … something… over .NET Remoting on the local machine. If you have a single assembly in the GAC, these apps are assured that the inter-communication will just work. If, however, they each have a separate version of an assembly, they may not be able to exchange objects. This is such a rare occurrence that you probably don’t need it. If you’re not sure, then you don’t need it.
The base GAC scenario is the .NET Base Class Library. These assemblies are shipped by Microsoft. They are authoritative. They are foundational. and signed. They rarely change. All apps should use the same copies of those DLLs. Therefore, they belong in the GAC.
In contrast, your application DLLs are not from Microsoft, they are not foundational, and probably not signed. They change more often, and there are only few apps (maybe only one!) that use each DLL. No GAC.
I could imagine a hardware device, let’s say a digital camera, that installs a .NET assembly to allow programmability. That’s a scenario where the assembly might fit well into the GAC. It allows arbitrary .NET apps to access the digital camera programmatically.
Your log4net example is not, in my opinion, enough to justify putting the assembly in the GAC. Imagine the scenario where one of the apps gets an update, and as part of the update it uses a new version of log4net. Now what? Should the new log4net assembly be placed into the GAC? Probably not.
The whole idea of sharing DLLs across applications was rooted in the premise that memory and disk storage was scarce. Once upon a time, that was true. It is not true, any longer. When in doubt, don’t use the GAC.