title: InternalsVisibleTo for dynamically generated assembly, but with strong naming
body: <p>I have a project that uses dynamic code generation to create a proxy class.  This proxy class makes use of internal classes of the project (so that implementation details are not exposed) and so I use InternalsVisibleTo with the name of my dynamically generated assembly.  This worked fine until recently, when my client imposed the requirement that all shipped assemblies be strong-named.</p>
  
  <p>The issue arises because, in order to use InternalsVisibleTo with a strong-named assembly, the assemblies it references must also be strong-named and you must provide a public key.  Where I'm getting stuck is how to provide a strong name for the dynamically generated assembly.  Here is what I've done so far:</p>
  
  <ol>
  <li>I've created a new key pair for dynamic assemblies, so that the .snk can be shipped with the product (obviously we don't want to ship the .snk being used for signing the rest of the project assemblies.)</li>
  <li>I've extracted the PublicKey and updated my InternalsVisibleTo to use the new dynamic PublicKey for dynamically referenced assemblies.</li>
  <li><p>I've attempted to sign the dynamically-generated assemblies like this:</p>
  
  <pre><code>    var name = new AssemblyName("ProxyBuilderAssembly");
      var attributes = new CustomAttributeBuilder[1];
      attributes[0] =
          new CustomAttributeBuilder(typeof(AssemblyKeyFileAttribute).GetConstructor(new[] {typeof(string)}),
                                     new object[] {"Dynamic.snk"});
      _assembly = AppDomain.CurrentDomain.DefineDynamicAssembly(name, AssemblyBuilderAccess.RunAndSave, attributes);
      _module = _assembly.DefineDynamicModule("ProxyBuilderAssembly", "ProxyBuilderAssembly.dll");
  </code></pre></li>
  </ol>
  
  <p>Unfortunately this is not working and I have been having a very hard time finding any documentation on how this should work.  Does anybody know how to sign a dynamically generated assembly so that it can be given access via InternalsVisibleTo?  I can just make the necessary classes public, but that ends up leaking implementation details that would be better left encapsulated.</p>