Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Your three assumptions are probably correct, although #2 has a bit of an odd history that might be relevant here. There is a .NET Framework CAS permission, <a href="http://msdn.microsoft.com/en-us/library/system.security.permissions.strongnameidentitypermission.aspx" rel="nofollow">StrongNameIdentityPermission</a>, that could be used to check for this sort of thing back in the .NET 1.x days. However, in .NET 2.0, fully trusted code started passing all identity permission checks, including for StrongNameIdentityPermission (<a href="http://blogs.msdn.com/b/eugene_bobukh/archive/2005/05/06/415217.aspx" rel="nofollow">http://blogs.msdn.com/b/eugene_bobukh/archive/2005/05/06/415217.aspx</a>).</p> <p>Before this behaviour change, a link demand for StrongNameIdentityPermission was one mechanism that folks used for creating semi-public APIs. The main disadvantage to this was that the types and members being "protected" had public visibility, and the verification only happened at runtime. This meant that a well-meaning user of a library containing such code wouldn't have any way to know that they were breaking intended usage rules until actually executing their code, which was pretty annoying. Since .NET 2.0, the preferred mechanism for creating a semi-public API is use of <a href="http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx" rel="nofollow">InternalsVisibleToAttribute</a> to declare "<a href="http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx" rel="nofollow">friend assemblies</a>".</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload