On InternalsVisibleTo

time to read 2 min | 372 words

Some people pointed out that the distinction between public and published can be done using InternalsVisibleTo. This is sort of possible, I agree, but it only works if you think about this as a unit testing measure.

Jon Skeet asked about good usages of InternalsVisibleTo aside from unit testing, and I decided to check and see what the framework is using it for. From cursory observation, it appears to be heavily misused. Just from observing the allowed dependencies make me cringe.

  • System.Data allows:
    • System.Data.Entity
    • SqlAccess
    • System.Data.DataSetExtensions
  • System.Web allows:
    • System.Web.Extensions
  • System.Xml allows:
    • System.Data.SqlXml
  • System.Data.SqlXml allows:
    • System.Xml <-- I don't want to know how they got this cycle
  • Microsoft.NETCF.Tools allows:
    • System.Web.Services <-- This one really scares me
  • Microsoft.Office.Tools.Common.v9.0 allows:
    • Microsoft.Office.Tools.Word.v9.0
    • Microsoft.VisualStudio.Tools.Office.Designer.Office2007
    • Microsoft.VisualStudio.Tools.Office.Designer.Office2007Tests
    • Microsoft.VisualStudio.Tools.Office.Outlook.UnitTests
  • Microsoft.Build.Conversion allows:
    • Microsoft.Build.Conversion.Unittest
  • Microsoft.Build.Engine allows:
    • Microsoft.Build.Engine.Unittest
  • PresentationCore allows:
    • System.Windows.Presentation
  • PresentationFramework allows:
    • PresentationFramework.Luna
  • System.Core allows:
    • Dlinq.Unittests <-- this is annoying, I don't get internals access to that, and I am also writing a linq provider
  • System.Design allows:
    • System.Web.Extensions.Design <-- well, if I want to write a designer, I have better work for MS...