views:

264

answers:

2

Hi,

I'm not quite sure how .NET and C# 3.5 handles the settings of applications spanning over multiple projects as well as multiple solutions. Maybe someone can help me clear things up.

I've got 2 solutions, both containing several projects. Some of those projects contain a Setttings.settings file under the Properties folder, containing specific configuration variables required by the source files in this project.

Something like

  1. JobManager Solution
    • Manager.Core (with settings file)
    • Manager.UserInterface (with settings file)
    • Manager.Extension
  2. Importer Solution
    • Importer (with settings file)
    • Service (with settings file)

As can be seen, Manager.Core contains its own configuration file to store database connection information and other stuff, whereas the Importer contains its own configuration files storing the paths to the import directories to know where to get the files it needs to import into the database using Manager.Core to do so. (that's what Manager.Core is there for, it contains all the queries and inserts to work with the DB)

Service, on the other hand, is a Windows Service which uses the Importer and let's it run every hour or so, containing its own configuration settings for error logging paths.

Now when I compile the Service, there is only 1 configuration file called Service.exe.config, containing only the configuration parameters specified in the Service project. My first approach was to duplicate every setting entry of Manager.Core and Importer in Service.exe.config. But testing showed that, somehow, the parameters of the Importer are present and used.

Where are the settings for Manager.Core and Importer stored when they are not present in Service.exe.config?

Are the settings of Manager.Core present, too, meaning it's unnecessary to duplicate the entries of those configuration settings in the Service settings file?

Kind regards, Michael

A: 

Not used these but could you replace them with links to a single file in the solutions?

Preet Sangha
Could do that, though I would prefer to utilize what's already there. It's not like it isn't working, I just don't understand how it works exactly. ;)
Michael Barth
+1  A: 

Settings defaults are normally generated into code which is then compiled into the resulting dll

They have a setting a CustomTool property of 'SettingsSingleFileGenerator'

For a Setting file called Foo.settings containing a single value 'MyName' with scope Application of type string with value "Shuggy" in namespace Company.Properties (the default location for a project called 'Company') if you looked at the dll in reflector you would find a class in the Company.Properties namespace looking like this:

[GeneratedCode(
"Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator"
,"9.0.0.0")] 
[CompilerGenerated]
internal sealed class Foo : ApplicationSettingsBase
{
    private static Settings defaultInstance = 
        ((Settings) SettingsBase.Synchronized(new Settings()));

    public static Settings Default
    {
        get { return defaultInstance; }
    }


    [ApplicationScopedSetting]
    [DefaultSettingValue("Shuggy")]
    [DebuggerNonUserCode]
    public string MyName
    {
        get
        {
            return (string) this["MyName"];
        }
    }
}

This is how settings structure and default values are persisted within the dlls which they are relevant to. The actual values are read from various config files depending on the scope (and possibly what programmatic changes the app decides to do)

For a higher level view on how these are intended to be used see this article

ShuggyCoUk
Does this mean, when I have external DLLs included in an application, that I can't change their application settings without recompiling the external DLL?
Michael Barth
The settings can be changed via the standard user level or application level files, I do not believe user settings can be changed from the foo.exe.config file but the Application scoped ones can beSee http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx for the overview of how these settings things work.
ShuggyCoUk
Thank you for the answer!
Michael Barth