[Mono-list] Please solve .exe s conflict?

[Francisco T. Martinez]

Paulo Augusto wrote:
> Please make future Windows instalers of mono register .mono files to be
> open with the proper executor (mono.exe) and compilers compile as
> standard to output of .exe.mono files!
>
>
> I'm hoping future Windows instalers of mono register .mono files and
> assigns them a nice shiny mono icon. Unless such thing is not possible?
>   
I for one, don't think we should go that way just yet.  One of the
biggest most perverted problems in DOS/Windows is the execution of
malicious code via file extensions that the shell already has an "Open"
verb associated with.  Just as in *NIX when we create a shell script
that already associate the invocation of mono.exe and the particular
.NET executable assembly one can achieve similar results with batch or
cmd files in Windows.  Later a Windows Shortcut can be created that
points to the intended batch file and can have Icons, working
directories, and further command line arguments passed to it.

I am not even so sure that registering mono.exe with the Windows Shell
or even adding the bin directory to the System or Current User PATH
statement is a good idea.  The fact that all of a mono distribution are
contained in any one version of the Mono Combined Windows Installer
resides in its own directory structure is not a coincidence, and over
the past couple of years has been further perfected by conscious
design.  One of the benefits of having this one directory structure that
is path relative from the destination folder that the user selects when
running the Mono Combined Installer is the ability to have more than one
version of mono installed in a given computer.  As reported recently,
this isolation also permits that mono could be installed in something
like a USB keychain drive and work self contained from there.

Today the mono build system is the same for *NIX as is for Windows. 
Building an extensive system like mono is far from trivial.  To create
specialized output for anyone platform (like having .exe be .mono files
when in Windows) detracts some from cross-platform and adds new levels
of complexities to compilers and build systems.

We can create tools that are external to mono but that are well
integrated with it to handle things like launching executables and
creating installation scripts for already available Open Source
installer building systems (the likes of Inno Setup, NSIS, MSI, etc.) 
This would solve the issues of deployment of a programmer's creation to
the intended users.  I have been working on what I see is the first part
of this system which is the launching of .NET assemblies with the mono
runtime as opposed to the .NET Runtime.  See:
http://forge.novell.com/modules/xfcontent/downloads.php/monowin32/Runtime%20selector/v1.0.0

In the coming months I will go on with the implementation of the second
part of this system, a Wizard driven tool that can help programmers
create installers and distribution units specifically for .NET
applications that would be run by the mono runtime.  I go into a bit
more details here: http://www.mfconsulting.com/blog/archives/000118.html
Just before creating such system, we will probably finalize what are the
minimum requirements for a Mono Redistributable Combined Installer.

Just as Microsoft has two main installers for their versions of the .NET
Framework (one SDK installer and one Redistributable installer), mono
may want to track something similar.  Today the Mono Combined Installer
for Windows is similar in content and intent with the .NET Framework SDK
installer.  This means that it includes all of  the runtime and
development tools, libraries, documentation as well as samples.  A
redistributable version would only contain the needed pieces to allow
runtime.  Sun Microsystems also addressed this problem similarly with
their JRE and Java SDK installers.

These are my .20 cents on the subject

Paco