Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=75246 --- shadow/75246 2005-06-13 15:07:22.000000000 -0400 +++ shadow/75246.tmp.25044 2005-06-13 16:02:03.000000000 -0400 @@ -81,6 +81,37 @@ split the tests. ------- Additional Comments From [EMAIL PROTECTED] 2005-06-13 15:07 ------- Created an attachment (id=15320) bug75246.diff + +------- Additional Comments From [EMAIL PROTECTED] 2005-06-13 16:02 ------- +Sebastien, + +Not sure if I'll have time to look into it today, but here's already +a little feedback on your first remark: + +For a "manually" instantiated AssemblyName, MS.NET returns NULL for +GetPublicKey and GetPublicKeyToken (unless these have been explictly +set using SetPublicKey/SetPublicKeyToken, I assume). + +For an AssemblyName constructed from AssemblyBuilder or for a +previously emitted assembly, MS.NET 1.x returns NULL for +GetPublicKey and GetPublicKeyToken if the assembly is not signed. +MS.NET 2.0 returns a zero-length byte array in this case. + +I think, we really need to make a difference between +- an AssemblyName that is constructed "manually" +- an AssemblyName for an AssemblyBuilder +- an AssemblyName for a previously emitted assembly + +and in some cases we need to have a different behaviour depending on +the profile (1.x/2.0). + +I'd be happy to assist in creating unit tests and modifications in +managed code, but I'm not enough familiar with the runtime (and I'm +afraid most of the work must be done there). + +Note: I have not verified this yet !! But I'm pretty sure lots (?) +of our AssemblyName tests (if they're not disabled)fail on MS.NET +1.x (and definitely on 2.0) _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
