Winform app: Compiled App.Config-like file?

Question

I would like to know if there is some kind of built-in compiled "App.Config" file?

The goal is to be able to have one of our library which can have some of its default values overriden when being used in some client application. Thoses DLL are loaded dynamically, so I cannot just give a parameter in the constructor.

I don't want to use the App.config file because the user can edit those values(otherwise it would have been just fine).

From what you describe, maybe a [Resource File .resx](https://msdn.microsoft.com/en-us/library/gg418542%28v=vs.110%29.aspx) could be a solution to store default values. — Filburt, Nov 24 '15 at 12:29
How would they be "overridden" though? If it's a rebuild, then it just seems like it could be done purely in code. You can always make a settings class interface, and then make different implementing classes for that for each of your different use cases. Then you can just change which implementation to instantiate into your interface-typed "settings" variable in your constructor and rebuild the dll. — Nyerguds, Nov 24 '15 at 12:34
Give them a Settings class with overridable values having property getters and setters, and, readonly values having only getters returning hard-coded default values. It will be the client's responsibility to store the overridden values to be able to set them again when the application is re-started. — Oguz Ozgul, Nov 24 '15 at 12:41
@Filburt: Okay, but how would you access this? Because we should have different values depending on which client, so how to provided the content of this Resx without knowing the type of the resx? — J4N, Nov 24 '15 at 13:45
@Nyerguds By "overriden", I mean that the library has some default values, and the goal is to check if something has been specified by this specific client application, if yes, use the specific value, otherwise use the default value. There is something like 4-6 layers between the dynamically loaded DLL and the client project, so giving a settings in all the chain is really pain(and one of the layer is provided through a singleton). Also, most of the dynamically loaded DLL doesn't need this file — J4N, Nov 24 '15 at 13:49
Well, either you can somehow do that check and select the relevant settings, or you can't. That's all your own problem; we don't have enough information to help you on how to get that done. The only thing we can do is help you with ways of selecting different settings sets, as you asked. — Nyerguds, Nov 24 '15 at 14:17

score 1 · Accepted Answer · edited May 23 '17 at 11:45

There are several different ways to solve this.

If you like the idea of config-files, but do not want to have it accessible by end users in the compiled application, perhaps you can create your own settings-file in a format that suits your needs, and include it as an embedded resource?

An upside of this would be that you can access it as a regular XML or config file or whatever in Visual Studio, while it will be hidden from the end user. Personally I think I would prefer this to using special code / classes to store config-data.

To include a file as an embedded resource, include it into one of your Visual Studio projects, right click the included file and select Properties. Now under Build Action, select Embedded Resource. When you build your project now, the file will be included internally in the produced .dll-file.

I'm sure you'll be able to find lot's of info about how to access an embedded resource from code. As an example, there are some useful examples in this SO question. Note especially this answer, which also mentions an alternative way to include a resource.

My question was more about a built-in way of solving this, I've plenty of idea if I've to do it myself(through custom XML). But anyway, I got your point. If I would do it myself, I would do a custom XML file, that is loaded within a Singleton object that could be accessed anywhere — J4N, Nov 24 '15 at 13:52

score 0 · Answer 2 · answered Nov 24 '15 at 14:13

Expanding on my comment... you could just make an interface for a settings class with hardcoded values, and then make different implementations of that interface. To actually change which one to use, all you'd need to do is comment/uncomment the line that instantiates an object into your settings variable before you build the dll:

public class MainDllProject
{
    ISettings m_Settings;

    public MainDllProject()
    {
        // Change this before compiling
        this.m_Settings = new DebugSettings();
        //this.m_Settings = new DeploySettings();

        // use settings from the settings class
        String setting1 = this.m_Settings.Setting1
        Int32 setting2 = this.m_Settings.Setting2
        //...
    }
}

public interface ISettings
{
    String Setting1 { get; }
    Int32 Setting2 { get; }
}


public class DebugSettings: ISettings
{
    public String Setting1
    { get { return "data_debug";} }
    public Int32 Setting2
    { get { return 2;} }
}

public class DeploySettings: ISettings
{
    public String Setting1
    { get { return "data_deploy";} }
    public Int32 Setting2
    { get { return 1;} }
}

On finding "a built-in way of solving this", as you said, maybe this will be useful for you...

You can actually use the Visual Studio build configuration manager to build with different settings. Using the #If directives, you can automatically make it select which lines of code to use based on the configuration. A simple example based on the default debug configuration, which adds the "DEBUG=True" variable automatically:

public MainDllProject()
{
    #If DEBUG Then
    this.m_Settings = new DebugSettings();
    #ElseIf
    this.m_Settings = new DeploySettings();
    #End if
}

You can actually make your own custom-named variables to check on just like that DEBUG one: after making a configuration, open the Project properties window, go to the Compile tab, select that specific configuration in the dropdown, and then at the bottom select "Advanced Compile Options". In there is a line "Custom constants" in which you can add such variables. For simple if-statements, you can just make a boolean like "CLIENTDEPLOY=True", and then you can use #If CLIENTDEPLOY Then in your code.

I appreciate, but it would mean that `ISettings` has to contains an exhaustive list of every property that could be used(in any application of our solution) — J4N, Nov 24 '15 at 14:32
Well, going for actual settings files, the simplest solution is just embedding them as text file resources, with your filter system selecting the right one and then parsing it. But you _specifically_ asked for _compiled_ settings. This is the way to get compiled settings. — Nyerguds, Nov 24 '15 at 14:35

Winform app: Compiled App.Config-like file?

2 Answers2