Should we continue to utilize the Registry going forward?

lonewolf32

Member
Joined
May 3, 2006
Messages
17
My company is finally moving to Visual Studio 2008 for development. We have been developing .NET applications for a while now but have never settled the issue of whether we should still be using the Registry to store settings.

Currently I am making use of user.settings to store user type things. But what should we do if we want to have common settings that several applications that exist in different directories (i.e. different products) need access to?

Should we continue to utilize the Registry or is there some accepted way of sharing settings? I just remember hearing things about the Registry going away in the future, so I want to plan accordingly if that is the case. (I know this wouldnt happen any time soon, but if it is going to happen someday then we want to make intelligent choices now, while we are already shaking things up.

Thanks!
Dave
 
That is an excellent question. I personally never use the registry, but have not yet come against a situation like yours where you need multiple applications to share settings.

Id probably do something like this:

C:\Program Files\MyCompany\Common\CommonSettings.xml
C:\Program Files\MyCompany\App1\App1Settings.xml
C:\Program Files\MyCompany\App2\App2Settings.xml

Althought there is probably a better way.
 
Wouldnt that violate rules in Vista about writing in the Program Files directory?

Secondly, we could "roll our own" and create a similar structure under the "All Users" directory or something, but the question is whether that is advisable, or if we need to do it in the first place.

Thanks!
 
Yes, Im thinking XP/2003. All Users is a better place to write that type of information.

I think its unlikely the Registry will go away any time soon, and even if it does, therell have to be some sort of emulation for legacy applications.

But I defer to others for more thoughts on where to store common settings.
 
There is both a user-specific and an all-users folder, each called "Application Data", which would probably be an appropriate location to store program settings. Generally, the program files folder should be considered read-only because a limited user may not be able to write to this folder, especially the all-users program files folder. (This certainly applies to XP.)

As far as the original question, the registry versus settings file issue is an ongoing debate, and each solution has its strengths and weaknesses. The registry is pretty simple and convenient, but if a user wants to migrate the settings to another computer, he would need to find the key(s) and create a registry patch, probably not worth the effort. If the settings are written in the same folder as the executable, then the user can bring the whole package around with him on a disk, but then you have to consider that whole pesky "writing to program files" thing. And if you write the settings to the application data then youve decoupled the executable and the data. For all the benefits and costs that come with that you find yourself in a situation very similar to that with the registry.

If you use a file instead of the registry, at least you can ditch the non-standard Win32 DLLs, if you care about such things. (How many of your users are running Mono?) Any solution is a mixed bag so I guess its mostly a matter of preference. I used to use the registry, but now I write a settings file, preferably in the users application data folder.
 
Back
Top