[Mono-bugs] [Bug 56564][Nor] Changed - Incorrect description for CS1548 when the strongname file doesn't contain the private key

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Wed, 7 Apr 2004 10:03:26 -0400 (EDT)

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@ximian.com.


--- shadow/56564	2004-04-07 08:47:09.000000000 -0400
+++ shadow/56564.tmp.26973	2004-04-07 10:03:26.000000000 -0400
@@ -78,6 +78,33 @@
 on Windows. But we wont be able to put ECMA assemblies compiled with
 CSC in the GAC.
 ------- Additional Comments From gert.driesen@pandora.be  2004-04-07 08:47 -------
 In that case, wouldn't it be better to use mcs to build the Mono 
 assemblies on Windows too (like we do on Linux) ?
+------- Additional Comments From sebastien@ximian.com  2004-04-07 10:03 -------
+Well the problem is a little different than I expected.
+a. CSC can compile assemblies using the ECMA key (so this is better
+than expected).
+b. Microsoft AssemblyBuilder doesn't support delay-signing (at least
+no the way we're using it). So either CSC is using something else to
+build it's assembly - or I'm missing something. 
+This means that MCS on MS runtime is gonna have a problem to
+delay-sign assemblies. So we should keep CSC as default to build
+assemblies (at least for the time being).
+Also the CS1606 error is given by CSC when using the ECMA key without
+the AssemblyDelaySign(true) attribute. This means that CSC use CS1548
+when the public key is used (not ECMA) but CS1606 when ECMA key is used.
+Attached is an updated patch that make sure that
+- CSC under MS runtime; and
+- MCS under Mono runtime
+gives the same results.
+I'll open a new bug for the MCS under MS runtime to investigate if
+this is really an MS limitation or if we have a bug somewhere in our
+class library.