Proper place for custom CONFIG file

  • Thread starter Thread starter Vagif Abilov
  • Start date Start date
V

Vagif Abilov

Hello,

We have a set of applications and assemblies that belong to one project.
Some of the configuration settings are supposed to be shared between various
assemblies on the same machine. After long discussions we finally decided
that the best alternative for us is to create a custom configuration file
<OutProject>.config and place it in a common directory. Then we can write
our own configuration parser that will return NameValueCollection settings.

There seems to be two good places to install such file:
<Windows>\Microsoft.NET\Framework\<CurrentVersion> and
<Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them
contain several configuration files. My first impression was that the latter
one is the best (since it's called CONFIG), however it contains only system
specific configurations files like machine.config. All application-based
config files are located one level up, inside
<Windows>\Microsoft.NET\Framework\<CurrentVersion>.

Do you know what is the best practice?

Thanks

Vagif Abilov
Contopronto AS
Oslo Norway
 
We have a set of applications and assemblies that belong to one project.
There seems to be two good places to install such file:
<Windows>\Microsoft.NET\Framework\<CurrentVersion> and
<Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them
contain several configuration files.
Click to expand...

Yes - but those are system directories - I'd stay away from those if
ever possible!
Do you know what is the best practice?
Click to expand...

If I were you, and I had a bunch of applications for a given project,
I'd put all of those into a specific directory, e.g. c:\program
files\myApp, and put common config files there, too.

Stay out of system directories if you ever can!

Marc
================================================================
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch
 
Thanks Marc, I see your point. However, I am not sure I fully share it.
Microsoft lists Machine.Config as one of the potential places to add global
configuration information (althouth they recommend to think twice before
adding your own stuff there). Putting your own file in that directory is
surely a better option than writing directly into Machine.config. On the
other hand, if I select some other place to place config file, I need to
agree about some common shared folder. In my case it's not just one
application. It's a series of appications and subprojects from them same
company that are installed using different installers and folders, some of
them are Web applications, others are regular Windows applications. To me
using one of Framework directories in such case is not that bad comparing to
hard-coding another folder name.

Just my 2 cents.

Vagif
 
Hi,

I agree with marc.
What about if there is allready a config file with the same name than yours
in a directories that you can't control ? you can erase it, or yours can be
erase by error ...

I have the same problematic than you, vagif.
To work around this i put my config file in the My c:\Program
Files\MyCompany\Config\ . I reference it in the registry, with the complete
path. I think the place where it is has no importance, it is just important
to be sure to found it when necessary.

(You must also have to set the config file to be not uninstallable when the
first application you install is uninstalled.)

Hope i help.


ROM
www.maintag.com
 
Thanks Nick, there's not much discussion of such things int MSDN articles,
so your blog definitely a good help.

Vagif
 
Romain,

Thank you for the suggestion. I am _alsmost_ convinced now that I should not
place my config files under .NET framework catalog. However I am not sure
about Program Files\My Company either. Program File directory lists
individual application folders, and we need a place for our shared files
(shared between different applications and Web sites). There is another
folder called "Common Files" (under Program Files) where various Companies
store their data (available in .NET,
System.Environment.SpecialFolder.CommonProgramFiles). I am thinking of using
this one.

Vagif
 
There is another folder called "Common Files" (under Program Files) where various Companies
store their data (available in .NET, System.Environment.SpecialFolder.CommonProgramFiles).
I am thinking of using this one.
Click to expand...

That would be a wise choice - go for it.

Even if a "system" directory (or system file - remember WIN.INI ???)
looks intriguiing - it's best to keep your fingers out of there!

Marc
================================================================
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch
 
Agree. I already implemented "Common Files"-based config settings. Now I
have an extended configuration .NET class that in addition to AppSettings
implements MachineSettings and AssemblySettings properties. Looks neat.

Thanks for your input, Marc.

Vagif
 
Vagif said:
We have a set of applications and assemblies that belong to one
project. Some of the configuration settings are supposed to be shared
between various assemblies on the same machine. After long
discussions we finally decided that the best alternative for us is to
create a custom configuration file <OutProject>.config and place it
in a common directory. Then we can write our own configuration parser
that will return NameValueCollection settings.
Click to expand...

You could use XmlSerializer to serialise a serializable object in one go to
an XML file, there's no need to write a parser.
There seems to be two good places to install such file:
<Windows>\Microsoft.NET\Framework\<CurrentVersion> and
<Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of
them contain several configuration files. My first impression was
that the latter one is the best (since it's called CONFIG), however
it contains only system specific configurations files like
machine.config. All application-based config files are located one
level up, inside <Windows>\Microsoft.NET\Framework\<CurrentVersion>.
Click to expand...

No No No. Don't pollute the system folders.
Do you know what is the best practice?
Click to expand...

Here's some suggestions.

1) Store the file in a folder with the project name under the user's profile
local application settings folder. The advantage of this idea is that you
guarantee that the user of your app will have access to the file (note that
administrators may use NTFS ACLs on a machine to restrict the folders that a
user can access). The disadvantage is that every user has their own copy (so
deployment is complicated) and you no longer have XCOPY deployment.

2) Organise your applications in a folder structure, eg:

Project_Folder
|
|----App 1
|
|----App 2

Put the common settings file in Project_Folder. The advantage is that you
know where the file is, you have one copy for all users. The disadvantage is
that you are not guaranteed access to this folder, but the administrator
will be able to ensure that.

Richard
 
Richard,

Thank you for your suggestions. It's a good idea to use XmlSeializer,
althouh parsing such simple structures into NameValueCollection is also a
very simple thing (but XmlSerializer approach is more elegant indeed).
Regarding a place to store the settings, I am now convinced that I should
stay away from Framework directories. For the project of our type (the
system is configured per machine, not per user, it's a server application),
I decided to place config file inside <Program Files>\<Common
Files>\<Company Name> folder. The folder <Common Files> contains various
common settings and components for different companies, so in case we have
stuff to be shared by several of our applications, it feels a good place.

Then I wrote a class that extends functionality of ConfigurationSettings
class (although it can't inherit from it, because the original class is
sealed and only contains static methods). The new class, in addition to
AppSettings property, also has AssemblySettings and MachineSettings
properties that will return respective parts of common configuration file.
Such approach resulted in minimum changes in our code and looks like a
natural extension of standard .NET class.


Vagif
 
Back
Top