Friend Assemblies


You have some types in your assembly A. And you have some assembly B. You really want assembly B to see those types. But you don’t want them to open to the world. What do you do?


In v1.0 and v1.1, you will mark those types as public, and then decorate them with StrongNameIdentityPermission.


In Whidbey+, you will say assembly B is assembly A’s friend


Note the sample in the page is incorrect. The correct syntax is:


[assembly:InternalsVisibleTo (“AssemblyB, PublicKeyToken=32ab4ba45e0a69a1”)]


The string in InternalsVisibleToAttribute’s constructor is the friend assembly’s name. 


When you declare assembly B as friend of assembly A, assembly B can access assembly A’s non public types. 


What is the difference between StrongNameIdentityPermission and friend assembly?


1. StrongNameIdentityPermission applies to individual type, while friend assembly applies to the whole assembly. 


If there are hundreds of types in assembly A that you want to share with assembly B, you have to decorate all of them with StrongNameIdentityPermission. While using friend assembly, you only need to state it once. 


2. More importantly, with StrongNameIdentityPermission, the types you want to share have to be declared as public. While in friend assembly case, those types can (and should) be non public. 


3. There can be only one StrongNameIdentityPermission on one type. But you can declare as many as assemblies as your friends. 


Friendship in Friend Assemblies is one way only. When assembly A says assembly B is its friend, it does not imply assembly A is assembly B’s friend. You will have to declare the friendship explicitly in assembly B. 


Friendship is not transitive. If assembly C is friend of assembly B, and assembly B is friend of assembly A, assembly C does not automatically becomes friend of assembly A. 


[You know, pre-released material, subject to change disclaimer applies here]

Comments (9)

  1. ToddM says:

    Does VS 2005 intellisense ‘know’ about this feature? (Both for a reference to some DLL on disk AND for a ‘project reference’ to some other project in the solution?)

    What are the performance implications of this feature? In other words, when is the permission checked, and how often?

    By the way, sweet feature, and I wish I had it 9 months ago! Glad to see that you guys continue to add high-value features that are worthwhile to those of us building truly huge .NET apps.

  2. Daniel says:

    This is cool! So does this mean we can do XML serialization without exposing our serializable classes as public for everyone to see?

  3. I have no idea about how friend assembly works with XML serialization.

    Ans to answer ToddM’s question. Myself do not use VS. But I believe they have support for that. You can try it in VS 2005 beta1 now.

    For the performance concern, it should be very minimum, and only occurs when you access non public fields/methods.