4

It seems like using this attribute for anything other than unit testing of non-public methods/properties would be a huge code smell. Are there any legitimate uses of the InternalsVisibleTo attribute to achieve something that might be otherwise impossible/too cumbersome using standard design patterns?

Joel B
  • 12,082
  • 10
  • 61
  • 69
  • This question assumes that the alternative is acceptable. Making a class *public* is not exactly a great alternative, that breaks *everybody* when you make drastic changes. Including code from programmers you don't know. The attribute helps to restrict the damage you'll inflict. – Hans Passant Aug 26 '13 at 14:32
  • @HansPassant - I agree that `public` everything won't fly. So I'm not really debating the necessity and merits of violating encapsulation in unit test scenarios. `InternalsVisibleTo` gives the developer the option to selectively violate the C# semantics for encapsulation (or maybe a better way to say it is "create some sort of hybrid encapsulation scheme") and I'm just wondering is this acceptable to use or is it generally frowned upon in favor of some other design pattern (if any exists). – Joel B Aug 26 '13 at 14:47

2 Answers2

6

We used it in building the Microsoft Surface SDK so that certain platform assemblies could talk to each other without opening up unwanted public APIs. Though this did create a burden of having manually ensure that these libs were only using "approved" internal things from each other.

Robert Levy
  • 28,747
  • 6
  • 62
  • 94
  • This is what I was thinking. Instead of putting everything into one uber-assembly or making everything they need to share `public`, just use `InternalsVisibleTo`. – Gabe Aug 26 '13 at 15:00
  • @JoelB Yup. You can probably verify this by opening up the old Surface SDK in Reflector :) – Robert Levy Aug 27 '13 at 21:05
4

Could be used to share code between your own assemblies that you do not want to publicly expose to the outside.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928