tags:

views:

262

answers:

4

I was recently given a heap of programs to maintain and I am trying to find some help in adopting some best practices. They are essentially three independant softwares which use a common DLL to manage a series of settings the apps all share. The DLL works this way: it swaps the user settings file (XML file buried deep in the user's configurations folder in Windows), with a fix file, specified by a hardcoded (egad!) path.

The rationale behind keeping it as user settings and not app settings is that the DLL can be found in several locations (one for each app that will use it), and so the user settings file is common (if all copies of the DLL are the same compile), whereas by using application settings there would be as many app.config files as there are copies of the DLL.

I'm trying to conceive of a better way to centralise these configurations and end the senseless file swapping. One approach (actually, most likely the best approach) would be to redesign all 3 apps so they all use a central dll with its own "app.config". Are there other more recommendable venues?

+6  A: 

Have you considered using the Windows Registry? We all hate it, but maybe it's the best option in this case as it is centralized and you could share settings easily across applications.

EDIT: If you don't like the Registry (and I don't blame you for it), you can create an XML or some other configuration file in a directory under the Application Data special folder. This is how this is done these days as far as I know.

string appData = Environment.GetFolderPath(
    Environment.SpecialFolder.LocalApplicationData));
string folder = "MyApplicationName";
string fileName = "settings.xml";
string path = Path.Combine(Path.Combine(appData, folder), fileName);
DrJokepu
Have, would rather not though. I thought the general idea was to move away from registry. It's not a bad idea, but I'd like to see other options.
MPelletier
Hate to give the registry another leg up, but this is probably the best answer. Trumped mine. ;)
jrista
@MPelletier: As far as centralized configuration goes, I think the registry is the best option. You could use a database, write your own configuration framework and store your configuration in a custom way, etc. etc. Thing is, the registry is ubiquitous in windows...its just there, and easily accessible. Hard to go wrong with it. I would recommend writing a wrapper around the registry access, in case you come up with a better solution in the future. Would be less impactful to your application that way.
jrista
+1  A: 

For this precise problem, if it's a .Net DLL, you could use the GAC, this would centralise your DLL. All software would know where they could access this DLL. And in this way, you could have less refactoring to do.

This is only a patch for this problem only. I would not recommend this, for new developpement.

GAC in Wikipedia

Stéphane
The different apps would still have separate working directories and config files, so the problem with locating the settings will remain.
Tor Haugen
As I understands it the DLL is the central point for the configuration. Since all reside in the DLL if he was to put into the GAC, all would be centralised
Stéphane
+2  A: 

You can use settings in a common file - most likely stored under AppData in the users settings folder

The advantage here is that you do not have to modify any code whatsoever.

The application would store its settings in its normal config file and refer to the common file for the dll settings:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings file="commondll.config">
    <add key="KeyToOverride" value="Original" />
    <add key="KeyToNotOverride" value="Standard" />
  </appSettings>
</configuration>

then in the common file commondll.config:

<appSettings>
  <add key="KeyToOverride" value="Overridden" />
  <add key="KeyToBeAdded" value="EntirelyNew" />
</appSettings>
dice
A: 

Perhaps this solution that shares configuration settings between an ASP.NET app and Console app will contain useful information.

John K