[Mono-bugs] [Bug 80225][Nor] Changed - AssemblyName.GetPublicKey() should not return null

[bugzilla-daemon at bugzilla.ximian.com]

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 knocte at gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=80225

--- shadow/80225	2006-12-11 17:14:38.000000000 -0500
+++ shadow/80225.tmp.21274	2006-12-11 17:22:20.000000000 -0500
@@ -10,13 +10,12 @@
 Component: CORLIB
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: knocte at gmail.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
-Cc: 
 Summary: AssemblyName.GetPublicKey() should not return null
 
 The new beta version of the (OSS) NHibernate project (which now supports
 2.0 stuff like Generics and Nullables) relies on the behaviour of the
 GetPublicKey() method of AssemblyName class about not returning null, but a
 vector of 0 bytes (so as to be able to query the Length property); so it
@@ -46,6 +45,23 @@
 
 Please provide test cases to ensure we won't regress Mono (or other
 software) that can depend on a null check.
 
 Also, if not already done, it would be nice to fill a bug against
 NHibernate too.
+
+------- Additional Comments From knocte at gmail.com  2006-12-11 17:22 -------
+Yeah, what I believe is that MS.NET implementation returns new byte[0]
+in the cases where there is no public key (hence the "some" cases),
+and then never returns null.
+
+I will attach two testcases, one that returns a non-empty key in
+MS.NET, and one that returns new byte[0]. I don't know of any case
+where MS.NET returns null.
+
+BTW, I don't think NHibernate developers would like to patch their
+work in order to work with Mono (perhaps yes as only a temporal
+workaround), or then we could get into a similar world as the web
+developers are in, where they have to take care of each browser that
+exists in the world.
+
+Thanks for your answer.