[Mono-bugs] [Bug 76655][Nor] Changed - Assembly loading problems are not reported in a System.CodeDom compile.

[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 grompf at sublimeintervention.com.

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

--- shadow/76655	2005-11-09 12:12:00.000000000 -0500
+++ shadow/76655.tmp.9087	2005-11-09 12:49:16.000000000 -0500
@@ -1,14 +1,14 @@
 Bug#: 76655
 Product: Mono: Class Libraries
 Version: 1.1
-OS: 
+OS: unknown
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: System
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: d.moonfire at mfgames.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
@@ -142,6 +142,38 @@
 Additional Information:
 
 ------- Additional Comments From d.moonfire at mfgames.com  2005-11-09 12:11 -------
 Created an attachment (id=16041)
 Zip file with test case.
 
+
+------- Additional Comments From grompf at sublimeintervention.com  2005-11-09 12:49 -------
+The basic problem here is that mcs is running but the TestNamespace.dll reference isn't 
+locatable so the runtime crashes with:
+
+** (/Library/Frameworks/Mono.framework/Versions/Current/bin/../lib/mono/1.0/
+mcs.exe:23166): WARNING **: The following assembly referenced from /Users/plasma/
+Desktop/test-case-3/TestNamespace2.dll could not be loaded:
+     Assembly:   TestNamespace    (assemblyref_index=0)
+     Version:    0.0.0.0
+     Public Key: (none)
+The assembly was not found in the Global Assembly Cache, a path listed in the 
+MONO_PATH environment variable, or in the location of the executing assembly (/Users/
+plasma/Desktop/test-case-3).
+
+
+** ERROR **: file class.c: line 2418 (mono_class_setup_parent): should not be reached
+aborting...      
+
+Since this doesn't match the regex on line 266 of class/System/Microsoft.CSharp/
+CSharpCodeCompiler.cs we return null as a result the crash is gobbled and the code 
+continues trying to load the assembly that was never compiled.
+
+Microsoft throws a CS0011 in this case; but this is a little more difficult for us to do.  I've 
+attached a patch that will propogate up unmatched output from the compiler; but it may 
+have unexpected consequences. 
+
+We definately shouldn't be treating runtime crashes as ok; perhaps we should check the 
+return code from the process and handle it there instead?
+
+-kangaroo
+