Visual Studio and .NET Framework Home
Thank you for your feedback!
ILASM: permission set not deserialized without appearing reason
- by Gael.Fraiteur
as By Design
The product team believes this item works according to its intended design.
A more detailed explanation for the resolution of this particular item may have been provided in the comments section.
10/20/2009 4:43:55 AM
A permission set is not deserialized when another, very similar, is.
ATTACH A FILE
EDIT THIS ITEM
Item can only be reassigned when it is active.
to post a comment.
Please enter a comment.
on 10/26/2009 at 1:19 PM
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=22.214.171.124, 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.
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?
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!
Developer, CLR team
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.
Developer, CLR team.
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.
to post a workaround.
Please enter a workaround.
Attach a file
© 2017 Microsoft