[Mono-bugs] [Bug 71887][Wis] New - detect .NET binaries and automatically invoke them with mono

[bugzilla-daemon@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 4lw0e0402@sneakemail.com.

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

--- shadow/71887	2005-01-27 17:26:55.000000000 -0500
+++ shadow/71887.tmp.21308	2005-01-27 17:26:55.000000000 -0500
@@ -0,0 +1,79 @@
+Bug#: 71887
+Product: Mono: Class Libraries
+Version: unspecified
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: System
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: 4lw0e0402@sneakemail.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: detect .NET binaries and automatically invoke them with mono
+
+This suggestion is from the mono-devel-list thread: "Calling one Exe From 
+another"
+
+Under mono, currently, the "correct" way to spawn a new .NET child process 
+is this:
+
+Process proc = new Process();
+proc.StartInfo.FileName = "mono";
+proc.StartInfo.Arguments = "WindowTest.exe";
+proc.Start();
+proc.WaitForExit();
+
+However, this won't work when the user's program is not running under 
+mono; this breaks binary compatibility, which is the primary goal of .NET. 
+In addition, it assumes that 'mono' can be seen on the path. While this is 
+commonly true, it is entirely possible to configure the system so 
+that 'mono' is not on the path and the user must specify the full path to 
+invoke it.
+
+Currently, with Microsoft .NET, invoking another .NET executable is no 
+different from invoking a non-.NET executable:
+
+Process proc = new Process();
+proc.StartInfo.FileName = "WindowTest.exe";
+proc.Start();
+proc.WaitForExit();
+
+Under mono, though, this fails unless the system has some other, OS-level 
+means of detecting that the binary is a .NET executable. Under Windows, 
+this will mean that a mono process invoking another .NET executable will 
+result in that executable running under Microsoft .NET. While in general 
+mono tries to be as compatible as possible, if, for instance, the two 
+processes then wish to communicate using remoting, they probably won't be 
+100% compatible. It's a fair assumption that if the original process is 
+running under mono, then the child process should also be running under 
+mono. Under linux, where mono is in most cases the only .NET framework 
+installed, the executable will not run at all, so the ethics of the matter 
+are out of the question.
+
+This "Wishlist" suggestion, then, is for mono's proc.Start() to read the 
+signature of the specified binary and determine whether it is a .NET 
+executable. If it is, then it should behave as though the user code had in 
+fact said this:
+
+proc.StartInfo.FileName = "mono";
+proc.StartInfo.Arguments = "WindowTest.exe";
+
+..but with the added benefit of being able to automatically locate 
+the 'mono' binary on the current system. This will also mean that if the 
+user has multiple versions of 'mono' installed, the child process will 
+always be invoked with the same version as the parent, which is, I think, 
+desirable :-)
+
+I am unsure of ways in which this could be worked around in the rare case 
+that the code author *knows* the binary will be running under mono and 
+wants the child process to be executed with a different runtime. One 
+possibility is a program such as the START.EXE which Win9x is bundled 
+with; invoking "start WindowTest.exe" is effectively identical to 
+invoking "WindowTest.exe" directly, and would provide an "escape hatch" 
+for user code that wanted to bypass common sense. ("START.EXE", which the 
+FileName property would point at, would not be detected as a .NET binary.)