ILASM: permission set not deserialized without appearing reason

ILASM: permission set not deserialized without appearing reason by Gael.Fraiteur

Closed

as By Design Help for as By Design

Type:	Bug
ID:	498716
Opened:	10/20/2009 4:43:55 AM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

A permission set is not deserialized when another, very similar, is.

Details (expand)

English

.NET Framework 4 Beta 2

Windows 7

English

Execute:
ildasm C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Core.dll

Then open
System.Security.Cryptography.CngKeyCreationParameters::set_UIPolicy

.permissionset demand
             = {class 'System.Security.Permissions.UIPermissionAttribute, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' = {property enum class 'System.Security.Permissions.UIPermissionWindow, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' 'Window' = int32(1)}}
.permissionset linkcheck
            bytearray (2E 01 80 80 53 79 73 74 65 6D 2E 53 65 63 75 72 // ....System.Secur
                     69 74 79 2E 50 65 72 6D 69 73 73 69 6F 6E 73 2E // ity.Permissions.
                     48 6F 73 74 50 72 6F 74 65 63 74 69 6F 6E 41 74 // HostProtectionAt
                     74 72 69 62 75 74 65 2C 20 6D 73 63 6F 72 6C 69 // tribute, mscorli
                     62 2C 20 56 65 72 73 69 6F 6E 3D 34 2E 30 2E 30 // b, Version=4.0.0
                     2E 30 2C 20 43 75 6C 74 75 72 65 3D 6E 65 75 74 // .0, Culture=neut
                     72 61 6C 2C 20 50 75 62 6C 69 63 4B 65 79 54 6F // ral, PublicKeyTo
                     6B 65 6E 3D 62 37 37 61 35 63 35 36 31 39 33 34 // ken=b77a5c561934
                     65 30 38 39 80 8C 02 54 55 77 53 79 73 74 65 6D // e089...TUwSystem
                     2E 53 65 63 75 72 69 74 79 2E 50 65 72 6D 69 73 // .Security.Permis
                     73 69 6F 6E 73 2E 53 65 63 75 72 69 74 79 41 63 // sions.SecurityAc
                     74 69 6F 6E 2C 20 6D 73 63 6F 72 6C 69 62 2C 20 // tion, mscorlib,
                     56 65 72 73 69 6F 6E 3D 34 2E 30 2E 30 2E 30 2C // Version=4.0.0.0,
                     20 43 75 6C 74 75 72 65 3D 6E 65 75 74 72 61 6C // Culture=neutral
                     2C 20 50 75 62 6C 69 63 4B 65 79 54 6F 6B 65 6E // , PublicKeyToken
                     3D 62 37 37 61 35 63 35 36 31 39 33 34 65 30 38 // =b77a5c561934e08
                     39 06 41 63 74 69 6F 6E 02 00 00 00 54 02 02 55 // 9.Action....T..U
                     49 01 )                                         // I.

     = { [mscorlib]System.Security.Permissions.UIPermissionAttribute = {property enum [mscorlib]System.Security.Permissions.UIPermissionWindow 'Window' = int32(1)}}
    .permissionset linkcheck
     = { [mscorlib]System.Security.Permissions.HostProtectionAttribute = {property enum [mscorlib]System.Security.Permissions.SecurityAction 'Action' = int32(2)
         property bool 'UI' = bool(true)}}

0 attachments

Posted by Gael.Fraiteur on 10/26/2009 at 1:19 PM

Thank you.

Posted by Microsoft on 10/26/2009 at 11:48 AM

The byte array refers to types in mscorlib in this format: "System.Security.Permissions.HostProtectionAttribute, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089". Ildasm has some functionality that takes this string and attempts to find an AssemblyRef for mscorlib and a TypeRef for HostProtectionAttribute, so that it ends up displaying "[mscorlib]System.Security.Permissions.HostProtectionAttribute" instead of the original string. Due to a peculiarity in our build tools, there is no TypeRef for one of the types named in the blob in System.Core.dll, so Ildasm fails to turn the original string into the shorter form, and it ends up displaying the byte array instead.

My comment, "the metadata blob to contain additional bytes in the presence of unusual source inputs" is actually incorrect in this instance - I was thinking about another recent bug in this area. Sorry about the confusion, in this particular case, the metadata blob is correctly formed and has the right length.

Posted by Gael.Fraiteur on 10/23/2009 at 11:24 AM

I would like to reproduce this behavior. However, PostSharp is able to deserialize the byte arrays correctly. Could you precise what was wrong with this byte array?

Thanks.

-gael

Posted by Microsoft on 10/23/2009 at 10:29 AM

The second permission set is displayed as a byte array because it doesn't have a proper textual representation. You found a bug in one of our build tools that causes the metadata blob to contain additional bytes in the presence of unusual source inputs; the presence of the additional bytes has no impact at runtime, and the only thing affected is the way ildasm displays the blob.

As such, we decided to resolve this bug as "By Design" (ildasm simply displays what's in the metadata), and we'll track the build tool issue with a separate bug, that will be triaged and resolved appropriately. Thank you for reporting this!

Ovidiu Platon
Developer, CLR team

Posted by Microsoft on 10/22/2009 at 11:28 AM

Thanks for the bug report. I'll investigate and I'll have a resolution in a few days.

Ovidiu Platon
Developer, CLR team.

Posted by Gael.Fraiteur on 10/20/2009 at 4:46 AM

The point is that I don't understand why the first permissionset is deserialized and not the second.