C# in Depth

202 CHAPTER 7 Concluding C# 2: the final featuresListing 7.12Demonstration of friend assemblies// Compiled to Source.dllusing System.Runtime.CompilerServices;[assembly:InternalsVisibleTo("FriendAssembly")]public class Source{internal static void InternalMethod(){}Grantsadditional access}public static void PublicMethod(){}// Compiled to FriendAssembly.dllpublic class Friend{static void Main(){Source.InternalMethod();Source.PublicMethod();}}Uses additionalaccess withinFriendAssembly// Compiled to EnemyAssembly.dllpublic class Enemy{static void Main(){// Source.InternalMethod();Source.PublicMethod();}}EnemyAssembly hasno special accessIn listing 7.12 a special relationship exists between FriendAssembly.dll andSource.dll—although it only operates one way: Source.dll has no access to internalmembers of FriendAssembly.dll. If we were to uncomment the line at B, the Enemyclass would fail to compile.So, why on earth would we want to open up our well-designed assembly to certainassemblies to start with?7.7.2 Why use InternalsVisibleTo?I can’t say I’ve ever used InternalsVisibleTo between two production assemblies.I’m not saying there aren’t legitimate use cases for that, but I’ve not come acrossthem. However, I have used the attribute when it comes to unit testing.There are some who say you should only test the public interface to code. PersonallyI’m happy to test whatever I can in the simplest manner possible. Friend assembliesmake that a lot easier: suddenly it’s trivial to test code that only has internal access withouttaking the dubious step of making members public just for the sake of testing, orincluding the test code within the production assembly. (It does occasionally meanBAccesses publicmethod as normalLicensed to Rhona Hadida