Linked by Thom Holwerda on Sun 11th Jan 2009 10:54 UTC, submitted by Hiev
Mono Project Arstechnica reports that Mono, an open source implementation of .NET runtime, is bringing Microsoft's development technologies to some unexpected places, including the iPhone, Android, and the Wii.
Permalink for comment 343139
To read all comments associated with this story, please click here.
Member since:

I meant 2 things:
1. Mono/.Net apps compile to EXE/DLLs.
2. The above mentioned apps tend to expect the existence of a Windows registry.

I personally don't find anything odd about using dll/exe in Linux. At least not odder than using .class or other extensions tied to languages or frameworks. Exe/dll files are based on the Portable Executable (PE) format, which is used by Windows, but not deeply tied to it (in fact, it is based on a modified version of the Unix COFF file format).

The Java .class files are bytcode files. They do not contain ELF sections or headers. They are only executable by the command-line java utility and jvm programatically. Similar concepts are used by Python, TCL, etc.

Now PE files are different from the above. PE files for example contain a RES section that is not useable elsewhere except on Windows. PE files also include a header that is used by Windows to determine how to execute it. On Mono this is not supported, you need to use ilrun to execute your apps. I can't for example execute a Mono app on Linux like this: ./mono_app.exe
So why bring this format to other platforms with little to no benefit? Why can't the Mono folks create them as ELF (when targeting Linux) and other executable formats for other platforms? Wouldn't this be more natural? Or at least settle on a cross-platform format that does not bring the PE baggage to other platforms.

...The System.Configuration api provides all you need for reading/writing application settings, and you are not forced to read/write configuration files from "Program Files". The settings infrastructure stores user specific settings into the users directory...

I was rebuking a poser that suggested to use App.Config to store configuration info. Doing what he/she suggested requires access to "Program Files". Which I described would be a problem for non admin users.

What you seem to be referring to here is User.Config. This configuration is accessible through the LocalFileSettingsProvider class. This class did not exist prior to .Net 2.0 and apps written using Mono prior to 2.0 did not have this interface either. So guess what most .Net apps were using all this while to store their configurations? ;-)

Here are my references:

Also, I do not see any KB/MSDN articles from MS stating that using the registry for .Net apps is discouraged and that the System.Configuration API is the better way that should be used instead. Care to provide some official pointers on this?


Reply Parent Score: 1