Friend assemblies

In the previous post, we’ve seen the difference between type visibility and member accessibility. A type can be visible to all the other types defined in the same assembly (internal) or it can be visible to any type, independently from the assembly where it’s defined. On the other hand, member accessibility controls the exposure of a member defined by a type.

By default, internal types cannot be instantiated from types defined in other assemblies. That’s why you’ll typically define your helper types as internal so that they can’t be consumed by types defined in other assemblies. There are, however, some scenarios where you’d like to grant access to all the types defined in another assembly and, at the same time, block access to all the other types defined in other assemblies. That’s where friend assemblies can help.

When you create an assembly, you can indicate its “friends” by using the InternalsVisibleToAttribute. This attribute expects a string which identifies the assembly’s name and public key (interestingly, you must pass the full key – not a hash – and you’re not supposed to pass the values of the culture, version and processor architecture which you’d normally use in a string that identifies an assembly). Here’s a quick example which considers the LA.Helpers assembly a friend:


As I’ve said before,you *do* need to pass the full public key (if the assembly isn’t strongly signed, then you just need to pass its name). In practice, all the types defines in the LA.Helpers assembly can now access all internal types defined on the assembly which contains the previous instruction. Besides getting access to all the internal types, friend assemblies can also access all of internal members of any type maintained in that assembly.

You should probably think carefully about the accessibility of your type’s members when you start grating friend access to other assemblies. Notice also that creating a friend relationship between two assemblies ends up creating a high dependency between  them and that’s why many defend that you should only use this feature with assemblies that ship on the same schedule. Notice that in my experience, I’ve ended up using this feature *only* for testing helpers that I don’t want to expose publicly from an assembly.

I think that most of us don’t use the command line for building any projects, but this post wouldn’t really be complete without mentioning some interesting details about the C# compilation process. When you’re building the friend assembly, you should use the /out parameter and pass the name of the assembly. This should improve your compilation experience since because you’re giving the compiler what it needs to know to check if the types defined in the assembly can access the internal types of the other assemblies. If you’re compiling a module (is anyone doing this in a regular basis?), then don’t forget to use the /moduleassemblyname parameter to specify the name of the assembly that will contain the module (the reason is the same as the one presented for the /out parameter).

And that sums it up quite nicely (I think). Stay tuned for more.


~ by Luis Abreu on September 7, 2010.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: