The other day I ended up making the decision to strong name a series of assemblies. It also usually means revisiting some config files somewhere and re-referencing the same dll's all over again but with a strong name. Of course there's many benefits to strong naming but that's not what this is about.
What I DIDN'T see coming was how this would throw a wrench into my unit tests. Normally when you create Unit Tests under Visual Studio if you are testing internal (friend in VB) methods it will automagically add the System.Runtime.CompilerServices.InternalsVisibleTo attribute on the assembly that is going to be unit tested. But the moment I strong named the assembly I wanted to run tests on I ended up getting the following error:
I dug through some MSDN documentation and found that it wanted me to do just that, instead of:
It took a bit of thinking for this to finally make sense to me. Strongly Named assemblies don't mind exposing their internals to other assemblies, but they'd at least like them to also be strongly named AND have have us specify the public of any assembly that's going to be digging around in its internals.
This means we have to strong name the Unit Test assembly as well.
In addition we still need to get the Public Key off of the Unit Test assembly after we strong name it.
It's important to note that the PublicKey is NOT the PublicKeyToken that you might acquire through Reflector and is part of the strong name. The PublicKey is the value of the public key extracted from the Key Pair/.snk file with the sn.exe utility.
You can extract the public key from an .snk with the sn.exe tool from the .NET SDK. First we extract just the public key from the key pair (.snk) file into another .snk file.
We end up getting a super LONG string of hex, but that's just what we want, the public key value of this key pair.
We add it to the strongly named project that we want to expose our internals from and we're good to go. Before what looked like:
And we're done.
Hope that helps,