Sample code in framework\'s AssemblyInfo.cs
:
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
(\"Test.Com
I would say it is bad practice because if you have used the SOLID principles then you really shouldn't have to use "InternalsVisibleTo". However i know in the "real world" you get all sorts of code.....so the pragmatic approach is best.
Also "InternalsVisibleTo" is not ideal in scenarios where you use obfuscation. Obfuscators tend to obfuscate the "internal" stuff. Therefore any external dll that attempts to reference the internals of an obfuscate dll will fail. You can obviously configure the obfuscator to ignore externally referenced items, but that would refuce the effectiveness of any obfuscator.
In my opinion, avoid "InternalsVisibleTo" if you can. But if you have to use it then theres something wrong with how the code is structured (which you tend to get a lot off)