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 _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
