… but I still like it as a technology, that is after working with it for a few months already, and now having understood a few of its quirks.
First of all, it’s not true at all that simply using Mono leads to perfect compatibility between Windows, Linux and OSX. Not without having to write some extra code. While Microsoft did design some abstraction, like System.Environment.OSVersion.PlatformID that allows to find which OS we’re actually running on, there is an obvious design by default oriented to Windows. It’s not like that’s something surprising.
For instance, .NET has its own way to store configuration settings, but this is very Windows-centric, since, as far as I can see, the configuration file is to be store together with the executable (this, then, wouldn’t work with properly installed Linux applications, since then the executable will be in a path the user has no write access to).
Another problem is that while there are interfaces to identify some of the standard location for files (like documents, pictures, the home directory and stuff like that), and Mono obviously handle them gracefully under Unix following the XDG Base Directory Specification which is quite a nice touch, it does not have the perfect granularity yet; for instance it does not provide a transparent way to handle the path for cache files (not-too-temporary, but not even persistent).
For these things, and probably a few more issues I’m finding, I’m currently writing a library, that I called, with very little imagination, Portability, which provides some generic interfaces to this kind of stuff; my intent is, if it makes sense at the end, to release it under either LGPL-3 or BSD license, and have it as a standalone project.
There are also a few more issues, like the sgen tool that should automatically generate static serialisation code to save and restore classes on files; unfortunately for some reason it doesn’t seem to work at all here: it aborts on an IDictionary object, but the class I’m asking it to serialise does not have any Dictionary in it; sigh. But that doesn’t matter since at least the dynamic, slow, reflection-based serialisation works, mostly.
At the end, I find it much nicer to work with C# than with Java (which would have been the alternative for this project for instance).
All good points. I’ve been using mono for about a year now. Not perfect, but each release seems exponentially improved.>>since, as far as I can see, the >>configuration file is to be store >>together with the executableMaybe this might help (I haven’t tried it in mono)<appsettings file=”file name” =””></appsettings>