Bug 323605 (MONO80920) - CodeCompiler.CompileAssemblyFromSource fails with GenerateInMemory == true
Summary: CodeCompiler.CompileAssemblyFromSource fails with GenerateInMemory == true
Status: RESOLVED FIXED
Alias: MONO80920
Product: Mono: Class Libraries
Classification: Mono
Component: System (show other bugs)
Version: 1.2
Hardware: Other Linux
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-21 14:11 UTC by Jörg Rosenkranz
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Test Case (2.73 KB, text/plain)
2007-02-21 14:12 UTC, Thomas Wiest
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 20:28:48 UTC


---- Reported by JoergR@voelcker.com 2007-02-21 07:11:28 MST ----

Description of Problem:
If you are compiling C# source code using new
CSharpCodeProvider().CreateCompiler().CompileAssemblyFromSource(...) and
you set the parameter GenerateInMemory to true and OutputAssembly parameter
is empty the compiler will fail.


Steps to reproduce the problem:
1. Compile attached sample
2. Run

Actual Results:
using System; namespace MyNamespace {
        class Message
        {
                public void MSGOutput()
                {
                        Console.WriteLine("Hello world");
                }
        }
}
With file as output assembly
Hello world
Without file as output assembly

Unhandled Exception: System.ArgumentException: Name is empty 
in <0x004d7> System.IO.FileStream:.ctor (System.String name, FileMode mode,
FileAccess access, FileShare share, Int32 bufferSize, Boolean isAsync,
Boolean anonymous) 
in <0x0001f> System.IO.FileStream:.ctor (System.String name, FileMode mode,
FileAccess access, FileShare share) 
in (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor
(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
in <0x00021> System.IO.File:OpenRead (System.String path) 
in <0x002f8> Mono.CSharp.CSharpCodeCompiler:CompileFromFileBatch
(System.CodeDom.Compiler.CompilerParameters options, System.String[]
fileNames) 
in <0x00181> Mono.CSharp.CSharpCodeCompiler:CompileFromSourceBatch
(System.CodeDom.Compiler.CompilerParameters options, System.String[] sources) 
in <0x00022> Mono.CSharp.CSharpCodeCompiler:CompileAssemblyFromSourceBatch
(System.CodeDom.Compiler.CompilerParameters options, System.String[] sources) 
in <0x0003c> Mono.CSharp.CSharpCodeCompiler:CompileAssemblyFromSource
(System.CodeDom.Compiler.CompilerParameters options, System.String source) 
in <0x0035f> CompilerTestEx.CompilerTest:Main (System.String[] args) 

Expected Results:
using System;
namespace MyNamespace
{
        class Message
        {
                public void MSGOutput()
                {
                        Console.WriteLine("Hello world");
                }
        }
}
With file as output assembly
Hello world
Without file as output assembly
Hello world


How often does this happen? 
Always

Additional Information:
There should be created a temporary assembly file internally for this case.



---- Additional Comments From JoergR@voelcker.com 2007-02-21 07:12:07 MST ----

Created an attachment (id=171529)
Test Case




---- Additional Comments From gert.driesen@pandora.be 2007-02-21 14:13:09 MST ----

The specific issue you reported (for the CSharpCodeCompiler) is now 
fixed in SVN.

I'll leave the bug report open until I've verified whether we need a 
similar fix for the VBCodeCompiler.  I'm pretty sure we do.



---- Additional Comments From gert.driesen@pandora.be 2007-02-21 16:45:45 MST ----

VBCodeCompiler is now fixed too.

Imported an attachment (id=171529)