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 us

Answer 1

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 2

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 3

Microsoft suggested both ways, because they have different capabilities. For example if you create some application for using in Active Directory, you can easily modify settings for thousands computers, even your application installed to different directories. If you choose xml you should know application folders for every PC or create some smart script to find them. But as many people said xml better for portability, settings backup and other.

So, there is no best way. Developers who need registry - using it directly. It is not so difficult. Probably that's why Microsoft didn't make app settings in registry.

Answer 4

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 5

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

Answer 6

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.