OT: Do you use the Registry?

MadGerbil posted on Wednesday, July 26, 2006

I'm reading through some basic .NET 2.0 Stuff trying to get a grasp on all the different places a person could store configuration data. One of the places would be the registry, of course - and the new My.Computer.Registry namespace makes this pretty simple.

However, XCopy is so dang convenient - I have to wonder if anyone else finds it necessary to use registry entries, and if you do, why? I'm just kicking this around to learn about it, so feel free to chime in with your thoughts on the matter.

How about Environmental Variables (just learned about those today) - anyone using those?

ajj3085 replied on Wednesday, July 26, 2006

What about Application Settings? You can specify defaults, and then provide a way for the user to override those defaults, which are stored on the local config. I believe they also work with ClickOnce deployment. You could do the same with registry (by hard coding defaults if you can't find values), but Application Settings seems a much 'nicer' way to do so. Alternately, if your settings are user modifiable, just stick them in the .config file for your application. I wouldn't use the registry unless I really had to; there are other, easier ways to store configuration data in .Net.

I don't think configuration settings really belong in Environment vairables; they are a throw back to the days of DOS; I've tacked on some Path information, but that's about all I've done for configuration.

HTH
Andy

MadGerbil replied on Wednesday, July 26, 2006

I've just discovered the beauty of the Settings area - however, it can be a little confusing at first.

If the setting is of type Application it is read only and stored in the app.config file. Everyone who uses that workstation gets the same values.

If the setting is of type User it is read/write and the file is stored in the Documents and Settings/[user id]/Local Settings/Application Data/[App name] folder and is different for each user.

What was confusing about this is the App.Config file only shows the default values for those settings - so if you change those values through the My.Settings namespace the App.Config file isn't changed at all - the User.config file stored in the Application Data file folder is what is changed.

Interesting stuff.

ajj3085 replied on Wednesday, July 26, 2006

Well, it can't show values for a file which likely doesn't even exist yet. Smile [:)]

Actually if you remember how .Net configuration works, its not confusing at all. Enterprise settings are stored in a .config file which is pushed to all workstations in the domain (if you set it up). Those settings are read first. Then, machine.config is loaded next, its purpose being to override values from the Enterprise level, but these changes are machine specific. Finally, you can have user level settings which in turn override those settings. Your application and then user application settings work in a similar manner.

Make more sense now?

MadGerbil replied on Monday, July 31, 2006

Well, it can't show values for a file which likely doesn't even exist yet. Smile <img src= " src="/emoticons/emotion-1.gif">

Actually if you remember how .Net configuration works, its not confusing at all. Enterprise settings are stored in a .config file which is pushed to all workstations in the domain (if you set it up). Those settings are read first. Then, machine.config is loaded next, its purpose being to override values from the Enterprise level, but these changes are machine specific. Finally, you can have user level settings which in turn override those settings. Your application and then user application settings work in a similar manner.

Make more sense now?

------------------------------------

Yes, that does make sense. I dunno why it is that I can read multiple books on .NET and yet never read something this simple in any of them. I really do hate how most books are written.

Massong replied on Thursday, July 27, 2006

Hi,

We store all user settings in the database connected with the user’s login data. Some of our employees work on different computers and so they can take their settings to the client they are actually working with. My first attempt was to use an xml structure in my BO and to save it as a string in the database. But this makes it difficult to change settings in a stored procedure (SQL Server 2000). So I use an own table for the settings now.