InternalsVisibleTo and strong names
I just stumbled upon a funny problem related to the new .NET 2.0 attribute InternalsVisibleTo in conjunction with a strong-named assembly.
The situation is this: I have that assembly that exposes its internals to another assembly (for unit testing) using InternalsVisibleTo. Now I decided to sign that assembly with a strong name. Suddenly, I got the following error message at compile time:
Friend assembly reference ‘UnitTests’ is invalid. Strong-name signed assemblies must specify a public key token in their InternalsVisibleTo declarations.
So what to do about this? Well, first the UnitTests assembly needs to be signed with a strong name, too. Then the tricky part is using the correct string to pass to the InternalsVisibleTo attribute. Problem is, you won’t be able to compile either of the two assemblies before you get that syntax right: the UnitTests assembly doesn’t compile because it references the other assembly, which can’t be compiled because the attribute is not correctly configured.
The trick is to find out the public key token of the strong name key pair you are using to sign the UnitTests assembly. There are several ways to do that:
- Find any other assembly in the GAC that has been signed with the same strong name and copy the public key token from the properties dialog.
- From the command line, use the sn.exe tool to show the public key token for an assembly that’s already signed:
sn.exe -T assembly.dll(note the capital T) - From the command line, use the sn.exe tool to show the token for a public key that you have saved in a file:
sn.exe -t mykey.pubIf you have your key pair together in one file, you’ll need to extract the public key into a separate file first:sn.exe -p mykey.snk mykey.pub
There are other ways, especially if you’re using a key pair stored in a container. Use the sn.exe command without parameters to get some helpful information on parameter syntax. In either case, you should end up with your public key token, which is a string representing an eight byte hexadecimal number.
The final step to get the assembly combination to compile correctly is to include the public key token in the parameter to the InternalsVisibleTo attribute in the correct syntax (use your own public key token, obviously):
Unfortunately, this doesn’t work for me. My method was to edit the unittest code to comment out all references to the main dll. Then compile it with a strong key that I created with sn.exe. I then used sn.exe to get the public key. I included this in the main dll assembly exactly as above, but when I compile I still get the same error. I even GACed the unittest.dll file. Is there anything wrong with my approach?
Comment by Brad Thompson — 19/10/2005 @ 11:31 pm - 2 years, 11 months ago
It does sound correct. What is the error you’re getting? The same message I showed above?
I just double-checked and I find there has to be something funny going on on your end. The thing is this: the compiler checks only for the valid syntax of the string passed to the InternalsVisibleTo attribute. For example, you can even use the string shown above, with the nonsense public key token in it, to make the compiler happy. So if you’re still getting errors, there must be another reason… are you sure you’re not seeing old messages? VS is sometimes great at this… To be sure, the best way is to switch to the Output tab after a compiler run (not the Error list tab!) and check the output carefully - maybe there’s some other problem and VS is showing you the old error.
Comment by Oliver Sturm — 20/10/2005 @ 8:49 am - 2 years, 11 months ago
Hi, I have come across your same error but with the difference being none of my assemblies were strongly signed.
At first I thought that the documentation included was incorrect and that the final release would only allow you to use the InternalsVisibleTo attribute on strongly signed assemblies. I was in the middle of writing something to MS when I tried to compile their example and was surprised when it worked.
So after much headscractching I discovered that if I removed the following three attributes from my ported AssemblyInfo.cs file:
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("")]
[assembly: AssemblyKeyName("")]
Then my error went away. It seems that if the compiler detects the presense of these attributes, for the purposes of the InternalsVisibleTo, it seems to think that the assembly is strongly signed.
Comment by Andrew Davey — 23/11/2005 @ 4:36 am - 2 years, 10 months ago
Hi
The InternalsVisibleTo attribute now uses the public key of the assembly, rather than the public key token. This can be extracted by running:
sn -tp mykey.pub
and using PublicKey= rather than PublicKeyToken=
Comment by Neil Mosafi — 13/3/2006 @ 3:38 pm - 2 years, 7 months ago
Hey Neil -
Certainly an interesting hint, but do you find this more useful? I tried it with my own key and while the token has 16 chars (8 bytes), the complete key string is more than 320 chars long. If I have the choice, I’ll still go with the token
Comment by Oliver Sturm — 13/3/2006 @ 3:44 pm - 2 years, 7 months ago
Command is slightly wrong:
Try this:
[assembly: InternalsVisibleTo("UnitTests, PublicKeyToken=<123456789abcdef0>")]
Comment by Justin Scott — 3/12/2007 @ 6:44 pm - 10 months, 1 week ago
Scratch that; I am not able to get PublicKeyToken to work as desired in Orcas.
However, PublicKey still works A-OK.
Use
sn -Tp assembly.dll
which will return:
PublicKey=00240000048…9
PublicKeyToken=123456789abcdef0
Then in code:
[assembly: InternalsVisibleTo("UnitTests, PublicKey=00240000048…9")]
Comment by Justin Scott — 3/12/2007 @ 7:08 pm - 10 months, 1 week ago
Thank you very much!
Specifying [InternalsVisibleTo("MyDll, PublicKey=…")] worked beautifully.
Visual Studio 2008 just simply refused to accepted [InternalsVisibleTo("MyDll, PublicKeyToken=…")]
Thanks again!
Comment by Andrew — 8/1/2008 @ 3:52 am - 9 months, 1 week ago
Just wanted to confirm Andrew’s comment — VS 2008 requires PublicKey; PublicKeyToken does not work.
Comment by Michael Flanakin — 17/1/2008 @ 2:07 pm - 8 months, 4 weeks ago
Im working with the Data Block of the Enterprise Library.
Both PublicKey and PublicKeyToken didnt work for me. There seems to be an endless nesting of referenced assemblies that I have to add this attribute to. What is the workaround if any?
Comment by nev — 4/3/2008 @ 10:25 am - 7 months, 1 week ago
Thanks for the info. Very helpful.
new -
The latest version of the Enterprise Library comes strong named. Otherwise, you just have to download the source, go into each project and sign each. Its a PITA, but once you’re done, you have a nice set of signed Enterprise Library dlls.
Comment by Jeremy — 4/3/2008 @ 11:29 pm - 7 months, 1 week ago
"The latest version of the Enterprise Library comes strong named.". I found the lastest version of the Library doesn’t includes strong name
<a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=4C557C63-708F-4280-8F0C-637481C31718&displaylang=en"> latest library</a>
Is this link correct?
Thank you!
Comment by Michael — 18/3/2008 @ 9:10 pm - 6 months, 3 weeks ago
Firstly thanks for the article, im new to c# and .net (came from php5), and this has helped me get InternalsVisibleTo working.
I do have one slight ‘odity’ in VS2008 however. I have a solution with 2 projects, one is the library code the other a unit test project for the library. When I build the library code all works fine but I don’t get the internal class appearing in the intellisense when using the unit test code. It all compiles fine however - anybody else experiencing this?
Comment by Gareth — 25/3/2008 @ 3:34 pm - 6 months, 2 weeks ago
I could not get mine to compile and see the internals until I found another post which said to use PublicKey (instead of PublicKeyToken) and use the actual hex public key (extracted from my unitTest binary using sn -Tp myunitTest.dll
Comment by Pspallone — 8/4/2008 @ 11:12 pm - 6 months ago