How to use “InternalsVisibleTo” attribute with Strongly named assembly?

47
votes

I am using the "InternalsVisibleTo" attribute with an assembly to expose the internal methods/classes to my unit test project.

I now need to install that assembly into the GAC, so I need to give it a strong name. When I try doing that, I get the following error in Visual Studio.

Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations

A bit of Googling brought me to the article below:

https://msdn.microsoft.com/en-us/library/bb763089.aspx

This article states:

"Determine the public key for the strong-named friend assembly."

This article does not say how to determine the public key. Where do I find the public key for the assembly? Also, once I have the public key, would this be the correct way to declare the attribute? 

[assembly: InternalsVisibleTo("Namespace.Assembly.Example.Name, PublicKey=ThePublicKey")]
3
c#.net-assembly
I tried that. It says to use SN.exe, but that only works when the assembly is strongly signed. I can't get my assembly to compile as strongly typed due the above error. SN.exe gives the error ".dll does not represent a strongly named assembly" – Dave
Seems you have the chicken and the egg reversed, you need the public key of the other assembly. – Hans Passant
Your "friend" assembly must be strongly signed to be usable in "internals visible to" and you need token of that other assembly. – Alexei Levenkov
The public key of my unit test assembly? – Dave

3 Answers

26
votes

To use InternalsVisibleTo with strongly signed assembly your "friends" assemblies must be strongly signed too. Public token of the test assembly need to be specified as part of InternalsVisibleTo value.

Note that the attribute is not used for actual validation of assembly at compile time - it only specifies that run-time checks (and compile-time checks for friend's assembly) should validate that identity. So if you just need to compile your main assembly you can specify any public key token (i.e. one from Microsoft's assemblies as found on all assembly references in your Web.Config for example).

Generally since you'll be signing assemblies you'd know the public key. I.e. if you have snk file than sn -t youSnk.snk would show the public key. Or you can follow steps in Getting Public Key Token of Assembly Within Visual Studio to configure your VS to show public token for any assembly which uses sn -Tp {path to assembly} to get public key from the assembly. (If document is gone steps are copied to the other answer to this question)

78
votes

UPDATE May 2019 : It works perfectly with Visual Studio 2019.

To anyone that is using Visual Studio 2017, there is the latest method :

From our beloved IDE, go to "Tools > External Tools..." and "Add" a new tool with those settings :

  • Title : Get PublicKey
  • Command : "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools\sn.exe" (/!\ choose the NETFX tool version that match your assembly NETFX version, here it's 4.6.2)
  • Arguments : -Tp $(TargetPath)
  • Check the "Use Output window" checkbox

Apply/OK those changes.

In the "Solution explorer" click on your project assembly name, and then head to "Tools > Get PublicKey". The Output window should display the (quite long) Public Key, along with the Public Token Key.

Finally, in the project that holds the internal class (i.e. the tested project) you want to expose, open the "AssemblyInfo.cs" file and add the line :

[assembly: InternalsVisibleTo("MyCompany.SolutionName.ProjectName, PublicKey=Paste your public key here")]

/!\ You have to remove the line breaks from your public key.

It worked perfectly for me, so hopefully it'll do the trick for you as well !

2
votes

I use an old good method from classic fiction movies: "hacker always guesses password in a second attempt". It's simple technique and it doesn't require any tools besides what you already have - some unit test framework. And yes, assembly under test must be signed, as mentioned here multiple times.

Copy and paste this class below to your test DLL. It's xUnit test but the same approach works well with any unit test framework.

public class FindOutAssemblyPublicKey
{
    const string AssemblyPK = "Swordfish";

    /// <summary>
    /// Fake test to find out a correct PublicKey in InternalsVisibleTo for assembly under test.
    /// </summary>
    [Fact]
    public void AssemblyPublicKeyIsAsExpected()
    {
        byte[] publicKey = GetType().Assembly.GetName().GetPublicKey();
        var sb = new StringBuilder();
        foreach (byte @byte in publicKey)
            sb.AppendFormat("{0:x2}", @byte);

        // Set breakpoint here to find out what's in sb
        Assert.Equal(AssemblyPK, sb.ToString());
    }
}

The idea here is quite simple: test fails at first run but reveals a correct public key of the test assembly. To double check replace "Swordfish" with what you've got as actual value, run test second time to make sure it's green and here you are.