[Mono-bugs] [Bug 56564][Nor] Changed - Incorrect description for CS1548 when the strongname file doesn't contain the private key
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 email@example.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 firstname.lastname@example.org 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 email@example.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
+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