Why aren't .NET "application settings" stored in the registry?

Question

Some time back in the nineties, Microsoft introduced the Windows Registry. Applications could store settings in different hives. There were hives for application-wide and user-specific scopes, and these were placed in appropriate locations, so that roaming profiles worked correctly.

In .NET 2.0 and up, we have this thing called Application Settings. Applications can use them to store settings in XML files, app.exe.config and user.config. These are for application-wide and user-specific scopes, and these are placed in appropriate locations, so that roaming profiles work correctly.

Sound familiar? What is the reason that these Application Settings are backed by XML files, instead of simply using the registry? Isn't this exactly what the registry was intended for?

The only reason I can think of is that the registry is Windows-specific, and .NET tries to be platform-independent. Was this a (or the) reason, or are there other considerations that I'm overlooking?

Answer 1

Another reason is that in order to edit the registry you would have to have higher amounts of permissions. If you are just editing an app config file you would only need to have rights to that file.

Answer 2

One immediate (but important) advantage:

With plain configuration files, users can restore their settings easily in case of a reinstall / restore from backup. It's a lot harder to do this from registry values.

Answer 3

Taking a dependency on the registry prevents XCOPY Deployment.

Answer 4

I think the new way of .config file helps by:

• Give the applications the flexibility to provide their own configurations as an override to the default configurations provided - consider the case of web.config overriding the machine.config
• Sometimes, it might not be possible to change the registry settings since you might not have the rights needed. So, a config file allows you to make changes applicable for your own application without needing the additional rights
• With a registry entry, multiple application could potentially be using the same configuration. But if you change it for your application, you might cause un-intended behaviour on the other applications & you might not have complete information about this

Just some thoughts that come to mind...

HTH.

Answer 5

• The registry is huge so it can be cumbersome to locate the relevant information (even with searching).
• It is possible to affect other applications by accident when modifying the registry.
• If the registry is corrupted all applications may be affected (including the OS).
• You need special purpose tools to search, modify and even copy the registry.

I prefer config files.

Answer 6

I would venture a guess that ease of remote deployment was a deciding factor.

Answer 7

It's because the registry is an ugly nightmare to use, and people didn't like it. It also didn't support xcopy deployment. With the use of xml files for configuration, you can move an app from machine to machine without the need of an installer. This was one of the biggest complaints with writing code back in the 90s.

With the registry, you have to grant someone permission to modify it when you install the application which in many organizations is forbidden. To modify the setting for an application you also have to know where to look in the registry which is difficult at best in many instances. With the config file, it's right there segregated from most other apps. Typically all the settings you need are right there for easy view and modification.

Answer 8

I think that one of the main reasons for this was application updates. When you install an update (i.e. using ClickOnce), the new settings actually go into a new folder. When you uninstall it, the new folder is deleted and the old settings are still around. If the registry were used instead, there would be no way to do this "versioning."

Other reasons might include:

• Permissions (app settings always go into AppData/LocalAppData which requires no privileges)
• Ease of maintenance/backups
• Portability (it's rather difficult to deal with the registry using the .NET Compact Framework, and god help you if you're trying to support Mono).

Answer 9

I heard a fairly substantial rumor that the data storage format used by sharepoint and by team foundation server, backed by SQL, was originally intended to replace the windows file system in windows 7. If this was the plan, then windows would have gained / (will someday?) gain a transactional data store for storing lists of data. This data storage method would probably be superior in every way to the registry.

Given that, it's hardly suprising to see Microsoft minimize the use of the registry as they move forward with the .net framework.

Answer 10

It seems to me that the registry is one of those things that "seemed like a good idea at the time" - for all the many reasons already listed by others. There is nothing wrong with realizing that something was not such a great idea after all, and instead using an alternative that is simpler and more convenient, even if it may seem like a step backwards in certain ways.

Answer 11

Application portability can be one reason. Application folders can be copied from one computer to other and settings will go with the application. Useful when running applications from usb flash drives on multiple computers.

Answer 12

I think there is a huge security issue about Application Setting (.config files) is that can be edited in any text editor and change every thing.

Let's say that a connectionString is stored and some one deleted or changed all values in the config file then the application will have a lot of proplem so the config file should be protected.

or store Setting in DLL file for example.

Answer 13

instead of simply using the registry

The registry is NOT simple. On my PC, it's a 40MB binary mess, and I hope the bits inside it don't change their mind.

Isn't this exactly what the registry was intended for?

Yes. But then again, DLLs were intended to provide shared functionality to different applications.

Answer 14

I don't think it is one answer I think it's a combination:

• The registry at the time of creating it looked like a good idea to store all settings for all programs in one place as oppose to the .ini files generally used before. At the time this increased performance as small .ini file reads from slow hard drives were costly, a single registry file somewhat increased performance. This is now different as hard drives are far faster and more and more settings have been dumped in the registry making it a burden on the system. You will see this if you install and uninstall lots of programs in windows it begins to slow down and eventually you probably end up reformatting.
• An incorrect write to the registry even in the current user settings can ruin your system.
• The registry doesn't help xcopy deployment of programs without specific code to handle lack of registry keys... This includes removing programs by simply deleting the folder in many cases
• Greater permissions can be needed to install an application if it needs access to the registry
• A .config file easily allows default application and user setting which can be modified on first run of the program by the end user
• Allows .NET to potentially run on other systems without OS specific code. This can somewhat be seen with Silverlight and isolated storage.
• Greater security through the use of Isolated Storage for the application and users
• Gives Microsoft the possibility way in the future to have a managed code only OS without many old dependencies. Think of the framework as a layer between any OS and the managed code.

Answer 15

I dont think this is a question of being platform independant. Many applications have been developped in the past on Linux, Mac and Windows, some using config files and others the registry.

I think the main reason comes from the "COM experience". The whole principle was to have component objects registered centrally in the registry so that any application could use it without having to copy the dll. This rapidly lead us to versionning problems. Multiple applications could hardly use different versions of a same component.

With configurations in the registry you have the same problem. Having two versions of a same application can be a real problem if the development was not done right. We had this kind of problems using multiple versions of Oracle a long time ago.

With .Net and the exploding capacity of hard drives and bandwidth, file duplication is no longer a concern. Having the dependencies copied in your folder project greatly simplifies application deployment. The same applies to configurations files. You can host multiple copies/versions of the same application without having problems with the limited machine/user architecture of the Registry.

Answer 16

One big advantage of moving to config files over the registry is to allow side-by-side installs of the same program. With the registry, central configuration info would overlap for these duplicate installs, but using config files, the information is kept private to each specific install. It's true that user-specific configuration overrides might potentially overlap (since they're stored in the user's app data folder, not specific to the install path), but imagine a scenario where different users use different installs, in which case this potential problem becomes irrelevant.