[Mono-bugs] [Bug 71887][Wis] Changed - detect .NET binaries and automatically invoke them with mono
Sat, 29 Jan 2005 14:18:52 -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 firstname.lastname@example.org.
--- shadow/71887 2005-01-29 06:38:02.000000000 -0500
+++ shadow/71887.tmp.30560 2005-01-29 14:18:52.000000000 -0500
@@ -95,6 +95,37 @@
------- Additional Comments From email@example.com 2005-01-29 06:38 -------
> "Binary compatibility" depends on users code
The effect of "binary compatibility", I mean. I never mean, the
meaning (definition) of "binary compatibility" depends on users.
+------- Additional Comments From firstname.lastname@example.org 2005-01-29 14:18 -------
+Suppose a user writes code for MS.NET that uses Process.Start() to
+start another .NET program. Then, later, a different user wishes to
+use this program under mono. At best, the process invocation starts
+the process under a different runtime. This can affect Remoting
+compatibility. At worst, the process invocation fails because the
+system is unable to recognize that the binary should be started with
+When there are multiple runtimes installed (e.g. .NET + mono on
+Windows), it is important that the process be started with the same
+runtime. When there is only 'mono', it is important that the process
+be started at all. Without any changes, it will fail.
+To resolve this problem, many programmers tell mono to invoke "mono
+Program.exe". This makes the problem worse, because the program
+developed using mono won't ever work properly on a system with the
+Microsoft .NET Framework.
+It was also noted on mono-devel-list that binfmt-misc isn't able to
+tell the difference between a .NET program and a regular Windows
+program. This means that binfmt-misc can't be effectively used when
+the user wants to be able to transparently invoke both mono and WINE,
+depending on the binary's type.
+Can you think of a situation where it would be desirable for the
+child process to run under a different framework than the parent