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

[Paulo Augusto]

I didn't understood everything you wrote but:

> ... 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. ...

I don't see how that can be any more dangerous than having to run a mono
program from a special console or any diference from running a batch
file that automatically loads the program through mono.



> ... 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.

The examples i've seen of creating such scripts are based on the
assumption that mono is installed into path c:\x\x\x . I don't want to
assume anything. Not assuming anything, i have to go around searching
for where mono instalations might be. And, for sure, i will end up
failing because some system will have it installed in some weird place.
Or i'll have to write major code to search, like the whole filesystem,
and have a tremendously slow installer.



> ... 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, ...
> One of the benefits of having this one directory structure ...
>  is the ability to have more than one
> version of mono installed in a given computer. ...

And how would such thing prevent mono from having more than one version
installed on the system?
For start, once you have mono 1.2, in principel, you wouldn't be using
mono 1.1 no more.
Also, you seem to be saying that, since we can't have the .exe.mono
files associated with more than one version of mono, it's better to not
have them associated with any version at all. That doesn't makes sense.

If mono programs are suposed to be run from a comand line (be it inside
a batch file or not), if the .exe.mono file is associated with a version
of mono, it can still be run from that same method of a comand line.



> 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) ...

No, not only for windows. That would lead to major problems, like ..
whatever, enough writing.
I meant, as a default ALL compilers compile with a extension
of .exe.mono . Although the .exe.mono instead of .mono is kind of
excesive information and doesn't change much.

Compiling to .exes may be part of the "ECMA/ISO standards" and that may
make it so that they would not be willing to change that. Or maybe the
mono team is hoping on having the executables created by mono be used
often directly under MS's .NET (even though i don't think this is a good
idea because MS's .NET doesn't have Gtk#, etc, etc).

I'l try to check those links, sometime, but, until some better reasons,
i'm planning on distributing the program as a .exe.mono and will tell
windows users to choose "open with" and "always open with".

> 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  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list