In last post, we covered the basics of CoreCLR security model (aka Transparency). I also mentioned that there are instances where NETCF breaks parity from CoreCLR. We’ll explore one of them in this post.

As per Transparency rules, SecurityCritical virtual methods can only override SecurityCritical base virtual methods. Any attempt to override a SafeCritical or Transparent virtual method will result in an exception. Conversely, SafeCritical and Transparent virtual methods can only override other SafeCritical and Transparent virtual methods.

This table should make it more clear:

Need for this rule: A virtual call will often result in invoking a method that is different from the one that is compiled. We want to make sure that the Transparency(and hence accessibility) of the method called at compile time is same as that of the method actually invoked. Not doing will open a security hole, where user compiles in a Transparent method and ends up calling a Critical method.

The rift:

In case the above rule is violated, CoreCLR(or Silverlight 3.0 on desktop) will result in a TypeLoadException for the type that contains the derived method. On NETCF, type load will succeed but a MethodAccessException will be thrown at the time the virtual method is actually invoked.

What this means for WP7 app developers:

When overriding a platform class(one shipped by Microsoft), you shouldn’t override any of the virtual methods marked as SecurityCritical. If you do by mistake, the exception behavior will be different on Desktop Silverlight and on WP7.

For detailed explanation of all Transparency rules, go read: Security in Silverlight 2