NACK the GAC Chris Sells goes over the very few reasons why the GAC should be employed. We've run into most of the issues here at Outtask:
The one where I can only come up with two reasons for using the GAC, the first being very difficult to pull off correctly and the second to happen more and more rarely as we move to SOA and .NET.
This post feels very much like "Why do we still need duals?" so if you've got a reason for using the GAC that I didn't list, by all means, let me know!
This smells to me like more MS technology that's been hyped to be the greatest thing since sliced bread but really only solves a small set of problems. Sort of like MTS/COM+. Other than its support for really good distributed transaction processing with no coding, MTS/COM+ buys you nothing except giving you a toolkit for solving a bunch of thorny COM thread isolation/system reliability problems that are really Microsoft design problems you shouldn't have had to care about to begin with. Having said that, the built-in distributed transaction handling really is nice. You can get really far with it before you have to branch out and write any sort of custom distributed transaction code. But that is only a fraction of what MS was promising in 1998-1999 that COM+ was going to do for you.