tags:

views:

50

answers:

6

I have a Solution with 3 projects in, each project needs access to certain settings. I'm looking for a way to have these setting values available to any project from 1 distinct source. I cant use the .Config file as that is relevent to that particular project.

I could use the database but have been told this is not good practice (Without an reason)

Any ideas?

+3  A: 

You could do this:

  • create a solution.config in your solution folder
  • in each project's app.config, add this to your <appSettings> node:

    <appSettings file="solution.config">
      ....
    </appSettings>
    

You would have to put symbolic links to your common solution.config in each project folder - but you could have one single physical file that you share amongst the projects.

The <appSettings> node is the only one that allows that sort of "cummulative" settings - those from the file specified in the file= will be added to your app settings, but potentially overwritten by anything you specify explicitly in your app.config.

On the other hand, yes, of course, you could use the database. We do that, too, in most of our projects, since we typically do have access to the database, but not to the file system in the client's server machines. I don't see why that should necessarily be a bad thing - we have settings for DEV, TEST and PROD in a table - so you have all your settings in one place - and we pick those settings we need when we need them. Works just fine - of course, some settings like the connection strings to the database cannot be stored there - but the bulk of our config info is. Again: I really don't see any reason why this should be a bad choice per se - so unless your source can back his/her statement up with some facts and reasons, I'd ignore it.

marc_s
+1 - pretty much what I was going to suggest.
Oded
+1  A: 

You can define configSource attribute in a defined configSection, to reference an external file from which to load your properties. Here you can find an example:

http://stackoverflow.com/questions/487991/is-there-any-way-for-an-app-config-file-to-reference-another-full-config-file

You can also use a DB of course, but that would probably involve developing some kind of configuration console, since it's not a good practice to manage config attributes directly into DB.

Otherwise you can create your config file (an xml, or yaml for example) and create your own shared config parser.

mamoo
A: 

You could add an entry into each projects .config file that points to the global one. You would need to read that in three places though.

Another solution that springs to mind is to put your common settings into their own assembly with it's own .config file. You then include that assembly in each of your projects. The .config file is read in the assembly and you can read out those values you need.

ChrisF
@ChrisF I've found that if you add the setting to the .config of another assembly and then use call a function in that assembly to read it, it ues the config of the local project
Pino
@Pino - I'm sure I've done this before, but it was at an old company so I don't have the source to double check. I'm going to have to investigate now.
ChrisF
A: 

What kinds of settings?

You can use the system wide machine.config and web.config files for settings that apply across an entire machine.

\Windows\Microsoft.NET\Framework[64]\[version]\config\machine.config
\Windows\Microsoft.NET\Framework[64]\[version]\config\web.config
Jason
A: 

You could use the registry if you have access to it. Then all you would need is a class to read them out (and possiblty one to put them in) and each project could use that class to read them.

The major downside though is that you would have to add the settings to each machines registry that you run your solution on.

w69rdy
Oh boy - the registry - that's so 1990's ..... this is really dead technology - get over it. Use something more manageable than the registry.....
marc_s
+1  A: 

I create a class to hold system-wide settings using either a Singleton pattern, or a Global instance (whichever you preference is).

If another project is in the solution, it can see the class (when references are added).

This also decouples the presentation of the settings from the storage mechanism (database, config file, custom XML file, whatever), and if you design to the interface, it makes unit testing more flexible, too.

Dr Herbie