silverlight coreclr uses an attribute-based security model, as opposed to the code access security (cas) model of the desktop version of .net framework. assemblies are marked with a security attribute, which can be "transparent" (codice_16), "safecritical" (codice_17) or "critical" (codice_18). methods in "transparent" assemblies run with partial trust, and codes within such assemblies cannot call "critical" methods (methods which can cause system-wide changes); neither can "transparent" assemblies contain unverifiable code (use the "unsafe" c# keyword or use pointers) or invoke system functions by means of p/invoke. code in both "critical" and "safecritical" assemblies run with full trust, and are therefore not subject to such limitations. however, a "transparent" method can call a "safecritical" method, and a "safecritical" method can call a "critical" method. in such a case, the "safecritical" method will verify that the call is both safe and within the limited rights of the caller; if so, then the "safecritical" method will proxy the call to the requested "critical" method. in fact, the isostorage apis are exposed as "safecritical" methods. an assembly whose security attribute is unset is run as a "transparent" method. analogous limitations also apply to type-inheritance; namely, in the cases of virtual-method calls and interface-method calls. silverlight assemblies can contain members that are not usable by coreclr, as long as they can be processed by the .net framework clr; such methods will not be loaded when the assembly is being executed by coreclr.