Config File vs. Registry

  • Thread starter Thread starter Paul R
  • Start date Start date
P

Paul R

Hi,

I have an application with a few settings that need to be external. I
understand I can do it a few different ways, including using the registry ir
an app.config fie. Can anyone offer any recommendations as to when it's
best to use one or the other?

What are the advantages and disadvantages of each?

Thanks!
 
I would generally use a config file unless you have some sensitive
information to store (but the configuration application block released by
microsoft can help here) as its much easier and has broader support. The
registry is a good central place to hold things but yu have to make sure
your process/user has enough privileges to read the specified registry key.
Also, when hosting components in COM+, you either need to have the config
file in \windows\system32 (which I dont like) or have the settings in the
registry (which is what I typically do when hosting components in COM+).

- Paul Glavich
 
Hi Paul

If there is the slightest possibility that your code will one day be ported
to another OS (e.g. Linux or MAC), then use a config file. The registry is a
windows-only "feature"

Regards

Ron
 
You could also use Isolated Storage (System.IO.IsolatedStorage) - its a
private virtual store (physically held within a user's "Documents And
Settings" area). The trouble with the registry is that the user/app need
permissions to access. Also, .NET apps running in a secure sandbox, for
example executing off a web site, have limited rights.

However, Isolated Storage is available to most .net apps and its seen as a
safe place to put stuff since apps and uses can't interfere with each other.

using a config class to store properties etc., this is serialised into a
file and stored. To get it back, use the Deserialise method and voila - the
class is back.

See the .net tool StoreAdm to manpilate the contents of users
IsolatedStorage.

Hope this helps

Shaun


[System.Serializable]
public class config
{
public string DatabaseName;
public string ServerName;
}

public void Save()
{

// create a handle onto the store for this user/assembly
System.IO.IsolatedStorage.IsolatedStorageFile
file=System.IO.IsolatedStorage.IsolatedStorageFile.GetStore(System.IO.Isolat
edStorage.IsolatedStorageScope.Domain |
System.IO.IsolatedStorage.IsolatedStorageScope.User |
System.IO.IsolatedStorage.IsolatedStorageScope.Assembly,null,null);

// binary formatter will be responsible for converting my class to a binary
representation that can be put in a file
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter formatter=new
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
System.IO.IsolatedStorage.IsolatedStorageFile
file=System.IO.IsolatedStorage.IsolatedStorageFile.GetStore(System.IO.Isolat
edStorage.IsolatedStorageScope.Domain |
System.IO.IsolatedStorage.IsolatedStorageScope.User |
System.IO.IsolatedStorage.IsolatedStorageScope.Assembly,null,null);

// open (create) a file in the store
System.IO.IsolatedStorage.IsolatedStorageFileStream stream=new
System.IO.IsolatedStorage.IsolatedStorageFileStream("MyFile.Dat",System.IO.F
ileMode.Create,System.IO.FileAccess.Write,System.IO.FileShare.None,file);

// convert class into the file stream
formatter.Serialize(stream,this);
stream.Close();
file.Close();
}
 
thanks for the help everyone!

Noonu said:
You could also use Isolated Storage (System.IO.IsolatedStorage) - its a
private virtual store (physically held within a user's "Documents And
Settings" area). The trouble with the registry is that the user/app need
permissions to access. Also, .NET apps running in a secure sandbox, for
example executing off a web site, have limited rights.

However, Isolated Storage is available to most .net apps and its seen as a
safe place to put stuff since apps and uses can't interfere with each other.

using a config class to store properties etc., this is serialised into a
file and stored. To get it back, use the Deserialise method and voila - the
class is back.

See the .net tool StoreAdm to manpilate the contents of users
IsolatedStorage.

Hope this helps

Shaun


[System.Serializable]
public class config
{
public string DatabaseName;
public string ServerName;
}

public void Save()
{

// create a handle onto the store for this user/assembly
System.IO.IsolatedStorage.IsolatedStorageFile
file=System.IO.IsolatedStorage.IsolatedStorageFile.GetStore(System.IO.Isolat
edStorage.IsolatedStorageScope.Domain |
System.IO.IsolatedStorage.IsolatedStorageScope.User |
System.IO.IsolatedStorage.IsolatedStorageScope.Assembly,null,null);

// binary formatter will be responsible for converting my class to a binary
representation that can be put in a file
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter formatter=new
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
System.IO.IsolatedStorage.IsolatedStorageFile
Click to expand...
file=System.IO.IsolatedStorage.IsolatedStorageFile.GetStore(System.IO.Isolat
edStorage.IsolatedStorageScope.Domain |
System.IO.IsolatedStorage.IsolatedStorageScope.User |
System.IO.IsolatedStorage.IsolatedStorageScope.Assembly,null,null);

// open (create) a file in the store
System.IO.IsolatedStorage.IsolatedStorageFileStream stream=new
System.IO.IsolatedStorage.IsolatedStorageFileStream("MyFile.Dat",System.IO.F
ileMode.Create,System.IO.FileAccess.Write,System.IO.FileShare.None,file);

// convert class into the file stream
formatter.Serialize(stream,this);
stream.Close();
file.Close();
}

Paul Glavich said:
I would generally use a config file unless you have some sensitive
information to store (but the configuration application block released by
microsoft can help here) as its much easier and has broader support. The
registry is a good central place to hold things but yu have to make sure
your process/user has enough privileges to read the specified registry key.
Also, when hosting components in COM+, you either need to have the config
file in \windows\system32 (which I dont like) or have the settings in the
registry (which is what I typically do when hosting components in COM+).

- Paul Glavich

registry
Click to expand...
Click to expand...
 
My project is planning to have a base class to allow to read and write any
app setting to a database instead of using configuration files.

The rationale is that we have a few app and web servers so we do not want to
manage so many config files. Hence we want to consolidate all setting in a
centralized database.

Any comment?
 
I have an application with a few settings that need to be external. I
understand I can do it a few different ways, including using the registry ir
an app.config fie. Can anyone offer any recommendations as to when it's
best to use one or the other?
What are the advantages and disadvantages of each?
Click to expand...

The biggest PRO for an external config file (vs. the registry) is the
fact you can easily move all the files to a new computer and run the
app, without having to fumble around with the registry. This makes
life just that much easier!

I'd use Registry stuff only for backwards compatibility - I'd put new
stuff only into external config files.

Marc

================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
Paul said:
Hi,

I have an application with a few settings that need to be external. I
understand I can do it a few different ways, including using the
registry ir an app.config fie. Can anyone offer any recommendations
as to when it's best to use one or the other?

What are the advantages and disadvantages of each?
Click to expand...

Config files
Pros:
- automatically read by framework classes
- store information in a file associated with the app (and only with that
app) so you can copy or delete the files associated with a single app
Cons:
- not user specific, one file for all users of the app
- essentially read-only, and 'read-once' (once you have read a section in a
config file it is cached in memory, and the cached value is used for all
other reads).
- not secure, anyone with read access to the file can read *anything* in the
file, so its not a good place to store cleartext passwords, connection
strings etc.
- not designed to be multi user, so you cannot have more than one thread
accessing the config *file* at one time

Registry
Pros:
- multi user, multiple threads can access the same hive at a time
- security on a per value basis, so that a value can store a setting that
can only be accessed by a specific user
- read/write and 'read-anytime'. By 'read-anytime' I mean that if you write
a value to the registry, when you read it at a later stage you get the *new*
value, not the original value.
- per user sections, anything you write to HKCU is specific to the current
user and is only accessible to that user (and admins, of course)
Cons:
- need to have specific code to remove registry entries when app is
uninstalled
- need to have specific code to persist registry entries into a portable
format if you want to move the app to another machine and then code that
will install those entries when the app is installed
- registry bloat

The config file approach is preferred by Microsoft, but unfortunately they
didn't try to give us the facilities that the registry has. You can simulate
per user values using Isolated Storage (see
http://www.c-sharppro.com/features/2003/09/cs200309rg_f/cs200309rg_f.asp),
but only with your own classes - the framework classes won't try and get
per-user config settings. Of course, a similar solution could encrypt values
to keep them secure. The problem with this approach is that if you delete
the app you will have to delete the isolated storage file too (use the
storeadm tool).

Using a config object is another option, and I have attached a code fragment
that shows one way to do this and store the serialized data in a folder
specific to the user. Again, you have the issue of deleting this file when
the app is deleted. You could add a file watcher for this file so that if
the values are changed by external code the config object can re-read the
values and then informa any interested code to update their values.

Another solution (that you suggested) is to use a database. This has similar
advantages (and disadvantages) to using the registry (which is, after all, a
database).

Richard
 
Back
Top