How can I make all projects in a solution use a single application configuration file?

Question

Our application is currently a mix of legacy C++ apps, C# .NET apps, and a variety of DLL and other supporting files. We recently ran into a problem where we needed to change a setting that appears in the Windows UI under Internet Options; it's called generatePublisherEvidence.

So my question is really two-fold:

Is there a better way to deal with this setting other than by using a file in our application directory named myEXE.exe.config? Here's the content of the file, by the way:
```
<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <runtime> 
        <generatePublisherEvidence enabled="false"/> 
    </runtime> 
</configuration>
```
If the .exe.config file is the appropriate choice, then is it possible to avoid having to include one of these for every EXE in my application (we have 18 of them)? In other words, is there some equivalent mechanism to a file *.exe.config that they all go looking for? A setting in every project perhaps?

Related: http://stackoverflow.com/questions/15181969/common-app-config-for-multiple-applications — George Johnston, May 31 '13 at 13:46
you could put it in the machine.config file. This will effect all .Net apps running on that machine though. — Liam, May 31 '13 at 13:47
@Liam And that would be bad because this is a Windows Certificate issue. The manifestation is that a long delay occurs when the EXE is launched when `generatePublisherEvidence` is `true`. We don't sign our EXE, so we need it to be `false`. — DonBoitnott, May 31 '13 at 13:49
Is this setting changed interactively by the user or by the devs depending of the deployment? Could it be potentially stored in the db? How are you deploying the .exe? Even if more than 1 config...Could it be automatically setup as part of the deployment? — TonyS, May 31 '13 at 13:52
@TonyS It is not changeable by the user(s). It cannot be stored because it's not DB specific. And I can't set it permanently because it's a setting for the Windows user that affects every EXE on the machine, potentially. So it must be a transient change only for my EXEs. — DonBoitnott, May 31 '13 at 13:57
@GeorgeJohnston Reading that other SO item looks like the right answer. But what about that part about the file locking? It is expected that any number of my EXEs could be starting up in any order, and many running all at once. So if I did setup the sharing as described...is it likely I will have access conflicts? — DonBoitnott, May 31 '13 at 14:00
You might want to look at this link: http://stackoverflow.com/questions/426245/how-to-share-app-config. Or you can consider setting a registry value. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms724875(v=vs.85).aspx. — JDennis, May 31 '13 at 14:56
Are there 18 separate .EXE's? or 18 separate projects with a single .EXE? Or? — Metro Smurf, May 31 '13 at 15:30
@MetroSmurf You would be at least partially correct either way. Two solutions in reality because one is legacy C++ code and the other is .NET C# code. Each has projects, and each project in all cases generates an EXE. In practice, I only need to be concerned with the .NET solution because the C++ code is involved only because it indirectly uses a managed DLL. — DonBoitnott, May 31 '13 at 15:32
@DonBoitnott I ask because it sounds like you don't need 18 app.config's, rather, maybe 2-3? If that's the case, then I'd just add them in manually as there is very little maintenance after that. FWIW, I've used pre-build events in the past to copy over app.config files as needed from a single source to multiple targets. — Metro Smurf, May 31 '13 at 16:06
@MetroSmurf I think it's either one or 18. The mechanism is looking for [assembly name].config, thus each one must have a file. Or one file and redirect each in code. The former is ugly in the folder, the latter seems messy and overkill in code. Given those choices, I think I will go with the former. — DonBoitnott, May 31 '13 at 23:43

score 0 · Answer 1 · edited May 23 '17 at 11:58

I think the easiest way is as George mentioned it (Common app.config for multiple applications), but if your applications need to write into that config file locking errors might indeed be an issue. The example you gave has only one key, but I assume it will get significantly larger soon if you want to use it as the central configuration for all your applications which belong together.

That all depends on how frequently you read/write the config - the more often and concurrently your applications are doing it, the more important is it to synchronize access. Usually, applications tend to read config values once and are caching it, but since you did not specify that I will give some ideas how you can deal with it:

To avoid concurrency issues you could write a windows or web service which writes into / reads from the central config file synchronized with locking mechanisms, and your applications are using a WCF contract to read/write values. The implementation effort for this is significantly larger than for option 2. If you want to read more about it, you can find an article here.
Or, you could use a SQL database with a config table, which uses transactions and thus does not have such issues. You could use the EF with Linq to easily read/modify the values. The advantage is that you can use POCO classes - for a quick start how to do it please look here.

score 0 · Accepted Answer · answered Jul 23 '13 at 19:25

0

Just to give this an answer, we elected to stay with what we have been doing. There doesn't appear to be an easy/better alternative given our simplistic need.

answered Jul 23 '13 at 19:25

DonBoitnott

10,787
6
49
68

How can I make all projects in a solution use a single application configuration file?

2 Answers2