In certain circumstances installing  to the GAC is your only choice. For
example, event receivers can't be installed anywhere except the GAC. Having
said that there are normally two reasons developers want to install  to the
GAC instead of the bin directory of the Web Application. The first is a
reasonable reason in my opinion. The second is not. Just make sure that if
you prohibit them from installing into the GAC that you don't set Trust
Level = "Full" as an alternative to properly setting Code Access Security
(CAS). Here are the two reasons.



1) The managed code assembly will be used by more than one Web
Application. If the assembly will be used by all the Web Applications in
the Farm its not efficient to install the assembly into every local bin
directory. Code installed in the GAC can be used by every Web App. (This
is reasonable)

2) The developer  doesn't want to or can't write the appropriate CAS
policy statements. Since code in the GAC is always fully trusted you don't
need to do a CAS policy for GAC deployed code. This is either a case of
being lazy or lacking knowledge. Neither is something I would want in a
developer I hired. Code should always run with the least set of privileges
required in CAS unless it is shared code as described in #1.



By the way, #2 is quite common in the development industry. But that
doesn't mean its right.

Now I wished I had taken your developer's
class too so I would know much of this already.

No problem. As you can tell, the topic hit on one of the things I'm fairly
outspoken about. But this group is all about good discussion and learning.
So if that happened it was time  well spent.

And that's why you get paid the BIG bucks! Thank you Paul! I will take this to
my team here and start looking at minimizing our deployments to the GAC.
Thankfully none of our work goes external so the attack surface is minimized,
for now.

And, if I may add to that:

Does the behaviour of a SP solution change when you target the App Pool as
opposed to the GAC? We deploy EVERYTHING to the GAC. What's the big deal and how
should we be doing things differently?

The main change in behavior is two things.



1. Code deployed to the GAC is fully trusted. That means it can do
anything on the server. If someone hacks the assembly in the GAC they can
do anything. Code deployed to the bin is only allowed  to do what its CAS
policy specifies. If the CAS policy specifies "Full Trust" then there is no
difference. But a developer  should be writing the CAS policy to only allow
the code to have the fewest privileges required to do the job. Even if the
code gets hacked it can't do what CAS won't let it.

2. Code deployed to the GAC is available to every application  pool on
the server. It still loads and runs in a specific app pool, so if you have
lots of app pools it will load several times. Code in the bin can only run
in the app pool associated with that web application. To run it in a second
web app it must be re-deployed.



When a solution targets a specific web app it deploys the code to that bin
directory only. If you target multiple web apps, it will re-depoly the code
to each web app. Code deployed to the GAC only deploys once.

I'm a little confused. "If the code gets hacked", doesn't the malicious
party already have power to mess up the whole system? I'm pretty sure if
they're already changing code in the GAC, you're not going to stop them from
doing much else.

Ok, then let's just say if the code has a BUG. The bottom line is code in
the GAC can do anything, code in the bin can only do what CAS allows. It is
a security Best Practice to always employee "least privilege". After all,
you wouldn't make all your user's Farm administrators would you? Why should
you give that kind of power to every piece of code. Writing CAS policies is
more work, but it is the "Right" way to do it from a Security Best Practices
approach.

For more info, read the following article:

store.bamboosolutions.com/kb/article.aspx?id=10405

For the record, I'm not a GAC man; just wanted to make sure
I hadn't missed part of the rationale here.

Here is another reason why GAC deployment is sometimes unavoidable:
calling web services that require access to a certificate. I've tried
in WCF and with WSE2 to call services that required signed or XML
encrypted messages, requiring access to the local certificate store
and the private key file of a cert. This just isn't possible using
CAS. There's no option or field that can be specified as such. GAC
deployment is the only option.

I'm not really convinced that this is a problem per say, as the
private key is protected from non trusted deployments, but it can be
annoying.

As I mentioned in the original reply there are times when a GAC deployment
is unavoidable. Web Services is another instance of that.