Registry vs Config files

[Tim Blizard]

I know this topic has been discussed before but I couldn't find any
thread more recent than about 18 months and was interested in what
conclusions people had come to recently.

Invariably 3 advantages of XML config files are promoted;

1. The .NET framework provides built-in support for reading
application configuration data from .config files very easily

2. Using these files makes it possible to deploy an application using
XCOPY and remove it using DEL directory

3. Storing application data in config files may allow it to be
executed on a non-Microsoft .NET platform

However it seems to me that there are strong arguments that invalidate
much of these advantages.

Firstly, the .NET framework support for .config files provides
read-only support but no support for writing data. This makes it more
difficult to save runtime application data (such as form position or
MRU file list). While the .config file could be treated as a standard
XML file and written to, they can be quite complex and most people
seem to agree that you might as well save your data to a custom XML
file instead.

This raises the issue of where to store this new custom XML file. If
it is not stored in the application directory then it is likely to be
overlooked in any subsequent deployment or application removal.
Storing it in the application directory requires the user to have
write access to the application directory. This is often undesireable
and counter to efforts by Microsoft to remove write access to the
Program Files directory tree from 'ordinary' users.

Furthermore, often runtime application data like this is expected to
be saved on a user-by-user basis. This either results in a single
large 'multi-user' save file in the application directory, or many
individual user save files in the application directory (both
requiring the user to have write access) or saving the data in a file
in the user's My Documents area (back to the file getting left
behind).

Many people seem to keep coming back to being able to deploy an
application using XCOPY but I fail to see why this is so important.
Most applications are deployed using an installation scripting tool
and will this will continue as far as I can tell. Beyond copying the
application's files, there are many other tasks that may need to be
completed to fully install a typical application;

a. Associating file types with the application
b. Registering any legacy COM objects (at least for a while yet)
c. Ensuring that any required assemblies are installed
d. Setting up .NET security (such as Code Access Security)
e. Installing a service perhaps

All this suggests to me that the only truly legitimate benefit is the
'possible' ability to run the application on a non-MS platform.

But on the flip side, the Registry seems to continue to offer
significant benefits;

a. Automatically looks after user-by-user data stroed in HKCU and
,when coupled with roaming profiles, ensures that user data is
available wherever the user logs on to the network
b. Provides a single centralised repository for this information
allowing Administrators to reasonably easily locate such data without
having to search the hard drive
c. Coupled with network policies, standard user registry settings can
be setup automatically
d. Provides a ready-built management application (regedit) for
maintaining this information
e. Administrator may be able to access the registry remotely to make
adjustments
f. Registry keys are securable objects allowing the Administrator to
establish who can have access to make changes
g. The registry has a semi-secure area for the storage of sensitive
information

I am about to start porting an existing application framework to .NET
and it currently makes extensive use of the registry. I am interested
in what other developers are doing and what you think about my logic
outlined above.

Beyond platform portability which is not high on my list at this time,
why shouldn't I continue to use the registry?

 

[Cor Ligthert]

Hi Tim,

There is nowhere written that you should use one approach you can use by
instance the registry for
the last form settings
last path when it is Access

You can use by instance an XML file for language dependable texts which are
not standard in the framework or the OS (advantage, later when needed
someone who speaks a language you do not know can add that language to your
program)

Just some thoughts,

Cor

 

[Ketchup Kerry]

Firstly, the .NET framework support for .config files provides
read-only support but no support for writing data. This makes it more
difficult to save runtime application data (such as form position or
MRU file list). While the .config file could be treated as a standard
XML file and written to, they can be quite complex and most people
seem to agree that you might as well save your data to a custom XML
file instead.

This raises the issue of where to store this new custom XML file. If
it is not stored in the application directory then it is likely to be
overlooked in any subsequent deployment or application removal.

So, all you have to do is to (1) check for it's existance on the start of
your application and (2) write a fresh copy if it's not there.

PS -- This same problem would apply to the config file, or an INI file, or
with the Registry for that matter if you moved the app to a new computer or
had a new user log in and try to use it ( assuming that the entries are not
system wide ).

and counter to efforts by Microsoft to remove write access to the
Program Files directory tree from 'ordinary' users.

There are plenty of sanctioned places to put it then. How about the
Temporary Files folder inside of Local Settings ?

application's files, there are many other tasks that may need to be
completed to fully install a typical application;

And that is why .NET and Visual Studio provide for creating a setup
application as part of a solution.

But on the flip side, the Registry seems to continue to offer
significant benefits;

The Registry is the "dll hell" of configuration. XML is the obvious way to
go.