[Mono-bugs] [Bug 74251][Wis] New - Unknown assembly reference while compiling an ASP.NET page with Chrome code

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Wed, 30 Mar 2005 21:12:05 -0500 (EST)


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 rogerio.araujo@gmail.com.

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

--- shadow/74251	2005-03-30 21:12:05.000000000 -0500
+++ shadow/74251.tmp.5439	2005-03-30 21:12:05.000000000 -0500
@@ -0,0 +1,63 @@
+Bug#: 74251
+Product: Mono: Class Libraries
+Version: 1.1
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: Sys.Web
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: rogerio.araujo@gmail.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Unknown assembly reference while compiling an ASP.NET page with Chrome code
+
+I'm having a strange problem with our ASP.NET/XSP CodeDom provider for
+Chrome, that occurs whenever two separate .dlls are involved in the
+build - for example a global.asax and a .aspx page, or a .ascx file
+referenced from an .aspx page.
+
+What happens is that the first dll is compiled just fine, and then i get
+the request to build the second dll, but the list of references is
+wrong: instead of the temporary name of the first dll (ie
+"...\mh-temp-aspnet\739b53cf\46251.dll"), i get a reference such as
+"data-033B2970" passed - that dll of course does not exist.
+
+Fwiw, i've seen almost the exact same problem with the Microsoft ASP.NET
+implementation (it was passing <Unknown> instead of the dll name) -
+until i noticed that ASP.NET doesn't like me returning a
+CompiledAssembly reference when it passed GenerateInMemory = false. Once
+i fixed that, the problem for ASP.NET went away.
+
+However, the Mono XSP runtime seems to always expect the
+CompiledAssembly (and looking at
+System.CodeDom.Compiler.CodeCompiler.Compile the C# CodeDom always seems
+to return one), so this fix didn't apply to XSP.
+
+Do you have any idea what could be going wrong? I could provide you with
+a copy of our CodeDom provider and debug symbols, and a test case, if
+that would help narrowing things down on your side.
+
+Steps to reproduce the problem:
+1. Untar the file that is attached to this bug report
+2. Install all assemblies in the gac
+3. Put the hello.aspx and global.asax in a virtual directory that handles
+ASP.NET pages.
+
+
+Actual Results:
+The error above
+
+Expected Results:
+A page sucessfully loaded.
+
+How often does this happen? 
+Ever
+
+Additional Information:
+The first attachment contains the assemblies with codedom provider and the
+testcases...