[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 sebastien at ximian.com.

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

--- shadow/80225	2006-12-11 17:22:20.000000000 -0500
+++ shadow/80225.tmp.22092	2006-12-11 17:58:30.000000000 -0500
@@ -62,6 +62,25 @@
 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.
+
+------- Additional Comments From sebastien at ximian.com  2006-12-11 17:58 -------
+Wrong interpretation. The "some" cases are for nulls (not for a public
+key being present). I know it because I wrote that FIXME ;-)
+
+Now it's possible that nulls may never happen with 2.0 (the comments
+predates that). However I'm pretty sure Mono itself depends, or
+depended, on the null value. So it's not a trivial change, requires
+tests to find the real issue (not just a working/not working test
+case) and reviewing Mono source code for it's usage. It may not be
+related to this FIXME but I recall some differences when S.R.E is used
+to create an assembly (versus loading one from disk).
+
+While it has nothing to do with Mono fixing the issue, I still think
+you should report the issue to NHibernate folks. Why ? because it's
+the "right thing" to do when you find a bug. It's also a simple change
+(for them), it may fix an issue for NHibernate (e.g. if MS does
+returns null in certain cases) and it also allows existing versions of
+Mono to execute NHibernate.