[Mono-dev] System.Configuration 2.0 ApplicationSettings infrastructure.

[Atsushi Eno]

Hi,

Gareth Pearce wrote:
> Hi,
> 
> In the process of porting my little freeware puzzle game to mono, I've 
> found that the .Net 2.0 ApplicationSettings infrastructure is currently 
> quite incomplete. I've got one patch in bugzilla so that it at least 
> doesn't crash under normal use, but even with that, 
> LocalFileSettingsProvider is just a stub, it doesn't actually perform 
> any persistence.
> 
> I was considering fixing it all up so it worked nicely.  But wanted to 
> a) check no one was already working in the area and b) check some design 
> questions.

It would be awesome if you can contribute those missing bits :-)
Chris worked on System.Configuration stuff as part of ASP.NET 2.0
tasks, and later I implemented more a bit, but it's still incomplete.
And since we are mostly working on WinForms stuff now, no one is
likely working on it.

Usually people should have no problem unless they use new 2.0
configuration classes, since 2.0 machine.config inherits that
of 1.0.

> The .Net documentation on the location of the user scoped settings file 
> used by local file settings provider appears incorrect.  It states that 
> user scoped settings files are found in User directory/Local 
> Settings/Application Data/Company Name/Product Name/Version Number
> but in reality the product name is replaced with the <executable 
> name>_Url_<hash of file location url or something >.
> I am wondering whether I should be aiming to match the hash so that the 
> same program run under mono vs being run under .net will still find the 
> same settings files.  It would seem like a difficult job without having 
> access to the actual .net class library disassembly. The hash looks like 
> base 32 encoding - 26 lower case letters and 6 digits - 32 characters 
> gives 160bits, maybe SHA-1?  But still the question is of what.

We have some special signature identification on our own system
assemblies, so you can just use the same assembly qualified name as
that of .NET and don't have to be afraid that those assemblies
have different assembly qualified names.

> And finally, if I get this all done soon would it be likely to go in 
> before the 1.2 release?  I'm hoping that Linux and Mac OS-X users can 
> start using my puzzle game once mono 1.2 goes out and it would be good 
> if their settings actually saved.

Since 2.0 classes are provided as non-finished works in Mono 1.2,
your changes are possible to be included depending on when it is
checked in. Also, we might not want to change some significant bits
if it changes some core class behaviors (which is pulled
via machine.config) at this state. But anyways please post patches
if you already have.

Thanks,
Atsushi Eno