title: Pros/Cons of strong-named/signed assemblies
body: <p>We have a solution with many projects in it (probably 20 or more). Recently we've made some changes that require a couple of those assemblies to be callable from COM, which means we need to strong-name them. Those assemblies reference others in our project, which means they need to be strong-named as well. They also have InternalsVisibleTo attributes, so the assemblies that are granted that must also be strong-named.</p>
  
  <p>Rather than hunt-and-peck trying to find just which assemblies need signing/strong-naming, I recommended we simply strong-name them all. This has put a couple of people in a tizzy about risk. I'm arguing that there is no risk, but they want pros and cons of signing assemblies. The only things I've been able to come up with are:</p>
  
  <p>Pros</p>
  
  <ul>
  <li>It's a requirement to call the
  assembly from COM</li>
  <li>It would allow us
  to put the assemblies in the GAC (we
  don't do that now)</li>
  <li>It prevents
  tampering (we host the application,
  it's not installed on client sites,
  so not that big an issue)</li>
  </ul>
  
  <p>Cons</p>
  
  <ul>
  <li>It requires that every assembly we use in the future be signed</li>
  </ul>
  
  <p>I have two specific questions:</p>
  
  <ol>
  <li>Would you say, in general, it's a good idea to sign/strong-name assemblies?</li>
  <li>Can you think of any other pros or cons?</li>
  </ol>