2

Possible Duplicate:
When should [assembly: InternalsVisibleTo()] be used?
Access to dll methods

I have two assemblies, A.dll and B.dll. A.dll has some common features, and B.dll uses it. I have to distribute A.dll and B.dll for other users eventually.

However, there are some methods in A.dll that I marked as public (for use by B.dll), but I don't want anyone else to use them.

Is there a good way to achieve this? Is the use of InternalsVisibleToAttribute a good practice to achieve this?

Community
  • 1
  • 1
Anash P. Oommen
  • 607
  • 3
  • 10
  • 2
    why don't you want others to call it? Why did you put them in seperate assemblies? – Emond Jul 25 '12 at 13:44
  • They are undocumented methods, that I don't want my 3rd party consumers to call - or call if you may using reflection, but don't complain that they changed in a future version of my code. – Anash P. Oommen Jul 30 '12 at 07:48

3 Answers3

9

Mark the items as internal in A.dll and add the following assembly property

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo( "B" )]

Be warned though, you can still access internal stuff through reflection so it's not 100% sealed.

James
  • 2,445
  • 2
  • 25
  • 35
  • +1 for the comment on the fact InternalVisibleTo is not really preventing access, but just hinting other assemblies "this method is not really for you..." (kind of Courtesy) – Tomer W Jul 25 '12 at 13:46
  • yes, this is exactly what I need - telling my users that "this method is not really for you, if you call it using reflection or likes, don't come to me telling I broke your application in a new library version". – Anash P. Oommen Jul 30 '12 at 07:46
1

InternalsVisibleTo is the way to go.

The title of your question was a bit confusing at first, but after reading it was clear that what you want is to have some internal (not public) members accessible by a specific assembly.

Diego Mijelshon
  • 52,548
  • 16
  • 116
  • 154
1

The InternalsVisibleToAttribute attribute is one way to do this but you have to realise that it exposes all internals to the other assembly.

Also note that if you're not using signed assemblies, the InternalsVisibleToAttribute will allow access to internals from any assembly with that name. That may not be desirable.

Another option could be to use tooling to inject the required code from assembly "A" into assembly "B". That would allow "B" to function independently without accessing internals. It depends on how your assemblies are used whether that's a desirable solution or not.

Finally, you could access the code in assembly "A" using reflection. It's a bit fiddly but if there is just a couple of things you need it may be enough. This will also allow you to provide nice fallback or error handling when assembly "B" is present but A is missing.

As others have pointed out, reflection can provide access to anything in your assembly internal or not. If you need to protect your code you should look into obfuscation.

Marnix van Valen
  • 13,265
  • 4
  • 47
  • 74
  • Well, obfuscation is not a use case for me, since my code is open-sourced. What I want to do is to hide the internal methods I use to communicate between the 2 assemblies (e.g. install a monitor hook) to the rest of the world. – Anash P. Oommen Jul 30 '12 at 07:44
  • @AnashP.Oommen So then your only concern is keeping your public API clean. I'd go with the `InternalsVisibleToAttribute`. – Marnix van Valen Jul 30 '12 at 11:43