Client library for .NET

[tnicolaysen]

As a developer
I want to integrate ConfigRemedy in my codebase
So that I can use it

Idea 1: Reflection-magic

All the user needs to do is create a interface without any implementation, and the library will create a proxy at run-time. This proxy will connect to the REST API and get the keys.

The benefits with this solution is that we get type-support, that it's easy to find usage in code and it's unobtrusive (transparent that there'a a library doing all the hard work).

In order to create such a proxy, we could use a simple factory. I.e.

ConfigRemedy.GetInstance<IApplicationSettings>();

// Should be baked into a IoC-framework like Castle Windsor.
// I imagine it can be registered in the container like so:
container.WithConfigRemedyFacility();
// and then when it tries to resolve a component implementing IProvideConfiguration
// it would create a factory.

The goal is to be as unobtrusive as possible and have all the wiring "outside" of the application.

Here is an example of what one interface could look like:

[ApplicationName("MyFantasticApp")]
public interface IApplicationSettings : IProvideConfiguration
{
  int SomeProperty { get; } 
  string AnotherProperty { get; }

  [Key("differentKey")]
  string NameThatHasMoreMeaning { get; }

  [DateFormat("yyyy-MM-dd")] // same as in .NET (can be avoided if dates are normalized in DB)
  DateTime ADifficultProperty { get; }
}

So, what about special conventions in string names that are not valid C# property name?
You might see properties like <add key="aspnet:FormsAuthReturnUrlVar" value="" />
Well, it's not a problem. It should still be possible to reference such variables by using the attributes shown in the example above, but it should be possible to use it without attributes.
My initial take on this is to support the namespace by replacing : with _ leaving the interface property named something like string Aspnet_FormsAuthReturnUrlVar { get; }

Then, what about <add key="Some.Scoped.Variable-WithWierdChars" value="" />. Again, the fallback to the attribute is viable here, but another method is applying a canonicalization scheme. In the case above, it would match a query for the string Some.Scoped.Variable-WithWierdChars as well as the interface property Some_Scoped_Varialbe_WithWierdChars.
Note: Property names would need to be validated against C#'s rules on what is a valid property name. Based on the language spec, there's a lot of valid choices, but it can probably be simplified to allowing something like the regex I've created on this page.

As a bonus, the user could copy/paste the appSettings section into the web application and get a suggested interface he then can copy/paste back into his code and use immediately. The main effort would be to replace the code that calls ConfigurationManager directly, but hey, search and replace works :)

Idea 2: Shim ConfigurationManager

It might be possible to replace ConfigurationManager.AppSettings Property using Microsoft Fakes or something else.

The benefit with this approach is that you could migrate your existing App.config into ConfigRemedy without doing any code changes. It would work as a drop-in replacement.

The way I imagine it to work is to intercept the "Get" method and redirect the call to the configuration system. You would off-course have two variables present in the appSettings for this to work.
"ConfigRemedy.BaseUrl" = "https://configsystem:8080/"
"ConfigRemedy.Environment" = "DEV"
(These two environment-specific variables should be replace during the deploy process. Octopus Deploy is excellent at handling this kind of job.)

If the client code calls ConfigurationManager.AppSettings["SomeProperty"] it would do a synchronous request to the API and retrieve this value (as well as caching it). Assuming the network is set up properly, this should be a very quick operation. The configuration values already present in the App.config would be ignored, and should be replace to "(set in ConfigRemedy)" or something similar.

This might be a good first step.

A bonus would be to create a feature on the client page which would parse the appSettings section and create those settings.