Setting the InternalsVisibleTo Attribute
Your code might contain classes, interfaces, or structs that have the internal access qualifier, in Visual C#, or the Friend access qualifier, in Visual Basic. Types have this qualifier for one of two reasons:
You have explicitly marked them as internal.
By default, top-level classes, interfaces, or structs that have no explicit access qualifier are treated as internal.
By default, private, internal, and friend elements in your code under test are not visible to your test code, but you can still test them. For information about how to test private methods, see How to: Test a Private Method.
Testing Elements with the Internal Access Qualifier
When you generate unit test methods for code that contains internal types, you might see the Add InternalsVisibleTo Attribute dialog box. It contains the following yes-no question:
You have chosen to generate tests for a type that is marked as Friend, or Internal. Would you like to add the InternalsVisibleTo attribute to project <project name>?
If your source project has strong name signing enabled, you will need to also enable signing for your test project. If you do not, you will receive a compilation error.
In this message, <project name> refers to the project that contains your code-under-test. If you answer yes, the assembly of your code under test is marked with the InternalsVisibleTo attribute, which makes the internal types in that assembly visible to your test project. This lets you perform unit tests on those internal types.
Note
The InternalsVisibleTo attribute can take two forms. The simple form specifies the assembly to which to grant access. The more complex form also includes a public key that is used for strong name signing. For more information, see the following section.
If you answer no, the internal types in your code-under-test assembly are treated as if they have the private access modifier. In this case, the test generation procedure creates a private accessor, which enables the test assembly to access those types, both internal and private. You will see the private accessor assembly in the Test References folder of your test project.
InternalsVisibleTo or a Private Accessor: Which to Use?
You can use a private accessor assembly to access both private members and internal members. If your code-under-test has internal members but no private members, it is best to use the InternalVisibleTo attribute on your code-under-test and forego the creation of a private accessor assembly. But if your code has both private and internal members that you want to test, use the private accessor, because it provides access to both. For more information, see Unit Tests for Internal, Private, and Friend Methods.
Strong Name Signing Requirement
The second paragraph of the Add InternalsVisibleTo Attribute dialog box contains information about strong-name signing. It means that building your solution will produce a compiler error unless you correctly enable strong-name signing:
If strong-name signing is enabled for your code-under-test assembly, it must also be enabled for your test assembly. In this case, you must use the signed form of the InternalsVisibleTo attribute. For example:
[InternalsVisibleTo(“OtherAssembly, PublicKey=12435234fsdaf;l457fwi248ew843872r892r”)]
If strong-name signing is not enabled for your code-under-test assembly, it does not have to be enabled for your test assembly. In this case, you can use the unsigned form of The InternalsVisibleTo attribute:
[InternalsVisibleTo(“OtherAssembly”)]
Note
If you click yes in the Add InternalsVisibleTo Attribute dialog box, Visual Studio adds the simple form of the InternalsVisibleTo attribute, the form without the public key.
Instrumenting a code-under-test assembly to enable the gathering of code coverage data also affects strong-name signing. For more information, see Instrumenting and Re-Signing Assemblies.