Tag Info

New answers tagged

0

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 ...


2

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 ...


2

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 (http://blogs.msdn.com/b/webdev/archive/2014/05/13/asp-net-vnext-the-future-of-net-on-the-server.aspx). Some other reasons the GAC is a bad idea: Deploying assemblies ...


3

So, I'm not sure if what I'm about to tell you is still correct but according to Mark Seeman in his book "Dependency Injection in .NET" he states that: Although the correct usage pattern concerning ADO.NET connections should be common knowledge, it's far less known that the same is true for WCF Clients. They should be closed as soon as we're finished ...



Top 50 recent answers are included