The root problem here is that your C# and C++ assemblies are using two different transparency models (see http://blogs.msdn.com/b/shawnfa/archive/2009/11/11/transparency-models-a-tale-of-two-levels.aspx and http://blogs.msdn.com/b/shawnfa/archive/2009/11/12/differences-between-the-security-rule-sets.aspx for details of the two levels). This is because the C# assembly compiles to level 2 by default, but the C++ assembly is automatically forced down to level 1 by the compiler for some apparently undocumented reason. Unfortunately, it seems that the latter behaviour isn't overridable. To make things worse, it doesn't appear to have changed in VS2012, and it doesn't look like the product team is considering changing it any time soon.
Given that you can't move the C++ assembly to level 2, you have a couple of potentially viable choices if you want to keep the executable in C++ and it must contain the interface implementation:
- Move the C# assembly to level 1 via use of the SecurityRulesAttribute. This would presumably only be acceptable if the C++ console app is the only consumer of the C# library.
Reproduce the level 2 "escalation" of security criticality to a full trust link/inheritance demand via the use of PermissionSetAttribute. e.g.:
[SecurityCritical] [PermissionSet(SecurityAction::LinkDemand, Unrestricted = true)] [PermissionSet(SecurityAction::InheritanceDemand, Unrestricted = true)] virtual void WriteSomething();
It might also be worthwhile to submit another bug report on Connect (voting for closed ones doesn't seem to be very useful) or a feature request on UserVoice to request that the compiler behaviour be changed. (Locking into level 1 is pretty darn odd given that level 2 is supposed to be the default for .NET 4.0 and higher.)