Where "should" options for our apps be placed? (or just where do u save them)

[Tygur]

Where "should" options for our apps be placed? (or just where do u save them)

 

I'm getting back into a .NET app that's been untouched for at least a year, and I noticed that it has no Options window, and not even any system of loading or saving options.

 

So far, all my apps have been saving options into the registry, but now I'm considering other options, such as a file in the user's profile (since a settings file in the app's install dir is out of the question).

 

I decided to post here and ask what was the most popular in .NET apps, and is there some "special" .NET way..

[Mike_R]

Yeah, the ".Net way" now has swung back to config files and definately away from Registry settings. Reading &/writing to the Registry should only be necessary when dealing with unmanaged components. For a pure .Net App, it shouldnt' be done.

 

The Code Library in the XVBT sister-forum has a code library sample and discussion by Reboot: Saving and Retrieving Application Settings.

 

In simple terms though, if you only have a few settings, I don't see why using a simple file (yes ini-style even) wouldn't be fine.

[snarfblam]

I was unaware that anyone expected me to save my settings any other way than registry keys. This is news to me. Well... I personally plan on continuing to use the registry until I see some sort of good reason why I shouldn't. Hmm... look at me; only twenty years old and I'm already becoming old fasioned.

[coldfusion244]

I was unaware that anyone expected me to save my settings any other way than registry keys. This is news to me. Well... I personally plan on continuing to use the registry until I see some sort of good reason why I shouldn't. Hmm... look at me; only twenty years old and I'm already becoming old fasioned.

 

Don't feel bad, I constantly use the command line interface to do most of my windows tasks. This could also be from the fact I use linux as well... Maybe it's just the blinking curser and black screen that makes me feel at home...

[snarfblam]

I remember back when I was little I had an Apple //c computer, and I programmed all sorts of things in Applesoft BASIC. All there was was the command line, until I made my own GUI programs. Oh... those were the days. Seems like I spent hours just Poking and Peeking and seeing what I could make the computer do. Hey... thinking of Applesoft BASIC just reminded me of this:

10 HOME
20 SWEET
30 GOTO 10

I can't remember where I saw that though. Or why I felt so compelled to post it. Must be delerium induced by sleep depravation.

[Tygur]

Yeah' date=' the ".Net way" now has swung back to config files and definately away from Registry settings. Reading &/writing to the Registry should only be necessary when dealing with unmanaged components. For a pure .Net App, it shouldnt' be done.[/quote']

What's wrong with the Registry in a .NET app?

[Mike_R]

I can't explain it any better than does Reboot in that link I posted above, which I'll repeat here: Saving and Retrieving Application Settings.

 

I guess that the "synopsis" would be that the current .Net approach is to use a form of INI file, but that is really XML. By being XML it's a sort of universal platform.

 

Registry settings also make it difficult for one to back up all your settings. For example, I can save all my documents, but Applications settings in the Registry are not easily backed up. If I had a crash, I could restore my stuff... but Applications settings are generally lost as they are often Registry based. I know that making a Ghost image would cover this situation, but the point is that Config files allow for settings to be saved and more easily moved from one PC to another, say having my custom settings copied from Home and Pasted at work. This is very hard or impossible with Registry settings.

 

The negative is that the User could inadvertently (or maybe even intentionally!) mess with the settings, since this is a much more visible mechanism than is the Registry, but I wouldn't worry too much about that. If some value is a licensing setting (a license expiration date maybe?), then I would simply encrypt that value or maybe the entire config file so that only your program could read it.

[Tygur]

The backing up point is a good one. My only problem with a config file is determining the format. I'd prefer to stay away from an xml format, cause it restricts what I can use to read it, if I should ever want to write something in a diff language that might not have the best XML support. I also just don't see the point in doing everything in XML..

[IngisKahn]

Hey man, where you been? Everything is XML now. There's not one active language that doesn't have good XML libraries.

 

Also, since it's the config file for your application, why would you need other programs to read it? (BTW, .NET 2.0 makes dealing with application config files even easier)

 

Oh, and another reason not to use the registry is that .NET was designed for and is moving toward platform independance.

[Tygur]

Hey man, where you been? Everything is XML now. There's not one active language that doesn't have good XML libraries.

 

Also, since it's the config file for your application, why would you need other programs to read it? (BTW, .NET 2.0 makes dealing with application config files even easier)

 

Oh, and another reason not to use the registry is that .NET was designed for and is moving toward platform independance.

I did notice that everyone's singing praises for XML. I just don't understand why. Unless some sort of a facility for reading XML is built into whatever language you're using, it's not that easy to read. On the other hand, something like an ini-style file can be read by anything at all...

 

As far as platform independance is concerned, Microsoft doesn't seem to be doing much to help it at all (i admit i can't say they aren't doing anything, tho). If you use System.Windows.Forms, you can pretty much throw platform independance out the window, at least for the time being.

[PlausiblyDamp]

Generally I would just create a class to encapsulate the user settings and use the built in XML support to serialize it. Too be honest in this respect a fairly readable output is generated with minimal effort on my part, plus if I so desired I could have more control over the output without having to get involved in the actual writing of the output.

As to where I would either use the users roaming profile for an application that was being deployed somewhere I knew the security requirements would allow this or use IsolatedStorage if there was any doubt about the capabilities to access the file system. (admittedly IsolatedStorage may also be unavailable but it offers a reasonably safe alternative)

Security is another reason I would stay clear of using the registry - a partially trusted application may not have permissions to read and write to the registry but may still have permission to use isolated storage.

 

Sample now attached, ignore the utter lack of error handling, no option strict etc as I was in a rush ;)

 

You will find the settings saved somewhere under you Documents and settings folder (C:\Documents and Settings\Instructor\Application Data\IsolatedStorage - on this PC)

SaveSettingsSample.zip

Edited February 28, 2005 by PlausiblyDamp

[IngisKahn]

If you use System.Windows.Forms' date=' you can pretty much throw platform independance out the window, at least for the time being.[/quote']

 

Never heard of Mono? :)

[snarfblam]

Mono. Thats a good point. But I would say that 99% of the users here use microsofts IDE which won't build of mono. For me, for all intents and purposes, if I'm using windows forms, i can say bye to platform independance (although I do have #Develop installed on my computer).

[Tygur]

Never heard of Mono? :)

Yes, I have heard of Mono. That's why I said what I said. They aren't done with System.Windows.Forms, so for now, if you use it, your app isn't (at least for the time being) cross-platform.