https://bugzilla.novell.com/show_bug.cgi?id=375370
User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=375370#c3 Andy Hume <[EMAIL PROTECTED]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | --- Comment #3 from Andy Hume <[EMAIL PROTECTED]> 2008-04-07 03:12:57 MST --- No this _is_ a compiler fault. Its the equivalent of the bug referenced from that bug, bug 315667 was 62358 "MCS doesn't encode SecurityAttributes properly". See below for the way vbnc writes such attributes. Now I do understand that Mono doesn't support CAS, so this has no effect when the assembly is run on the mono runtime. The question is whether we care that *if* the assembly is run on the MSFT, the security attribute will have no effect there too...? MSFT vbc writes: [[ .method public static void RemoveRights() cil managed { .permissionset deny = {[mscorlib]System.Security.Permissions.FileIOPermissionAttribute = {property bool 'Unrestricted' = bool(true)}} .. ]] But vbnc writes: [[ .method public static void RemoveRights() cil managed { .custom instance void [mscorlib]System.Security.Permissions.FileIOPermissionAttribute::.ctor(valuetype [mscorlib]System.Security.Permissions.SecurityAction) = ( 01 00 04 00 00 00 01 00 54 02 0C 55 6E 72 65 73 // ........T..Unres .. ]] As I understand that it a wrong compile, and thus the security attribute will not be used at run-time. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
