InternalsVisibleTo is interesting attribute. It will make all it’s internal (or friend) fields open to the special one. In this case “special one” is another assembly.
Let’s try to elaborate this with example. Assembly A.exe has reference to B.dll. A.exe can see all public fields and nothing more. However, if designer of B.dll adds InternalsVisibleTo attribute, A.exe will be able to see his fields marked with internal also.
One can argue that this violates “black box” principle and I would agree. This attribute is not to be used regularly. I can think only two reasons why you should use this.
First one is component test. If you “befriend” your test assembly (A.exe) and B.dll this means that testing of target assembly is not limited to public interface. You suddenly have power to test internal workings.
Another usage is for those solutions that have multiple projects in different language. Sometimes you just have components already available in one language (e.g. C#) while main project is in another (e.g. VB.NET). Instead of rewriting everything, simple make new assembly and have all it’s content internal with InternalsVisibleTo exception for main project.
For this case benefits are doubtful since you might as well make those classes public and everything will work as it should. However, I like to make it internal in order to prevent others accessing it. If you just leave public assemblies laying around chances are that someone will use it.
That may be new guy on project that doesn’t know history of that class and he will just see opportunity to hook into already existing interface. He will not know that this was not intended to be public interface and that it wasn’t tested as such and probability is high that something will break.
While public assemblies hopefully get interface testing that they deserve, original idea of this assembly was to be glue between languages. It may be that everything works great while it has benefit of all calls being made from main project but, once you directly access it, you will stumble on quite a lot of problems and border case error that weren’t issue before. And if you ship it, you get to support public interface that was never designed as such.
If you still want to use this attribute after all this warnings, just add it in AssemblyInfo.cs (or your own favorite place):
[assembly: InternalsVisibleTo("A, PublicKey=00240000048000009400000006020000002400005253413100040000010001002de64bdf2fb7ba60913800e843fe50288f7c1467051bb0a70eca140d1e3900530a51931ead28a80d50c7b4bd7a6ec868f601dee366fef644d129a43d6eb8090c1fd097d4e13b80b1069eafab518233e0f21e14e89ee73e47486a7faf4ea2a4ad5dd48a80d1477fdd3c1715c8b46e876bbc2c27595914a0c1437d44e656e4c2d3")]
As you can see, attribute will take one argument consisting of two parts separated by comma (,). First is name of your project (in this case “A”) and other is public key of that strong-signed assembly (yes, this attribute will not work on assemblies that are not strong-signed).
In order to get that last piece of puzzle, one can use Microsoft’s Strong Name utility:
sn -Tp .\A.exe
Microsoft (R) .NET Framework Strong Name Utility Version 3.5.30729.1
Copyright (c) Microsoft Corporation. All rights reserved.
Public key is
00240000048000009400000006020000002400005253413100040000010001002de64bdf2fb7ba
60913800e843fe50288f7c1467051bb0a70eca140d1e3900530a51931ead28a80d50c7b4bd7a6e
c868f601dee366fef644d129a43d6eb8090c1fd097d4e13b80b1069eafab518233e0f21e14e89e
e73e47486a7faf4ea2a4ad5dd48a80d1477fdd3c1715c8b46e876bbc2c27595914a0c1437d44e6
56e4c2d3
Public key token is b80ce85f4244428f
Of course, to do this you will need to have “C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin” (or whichever directory holds sn.exe on your system) in path.
