devrexlabs / fig Goto Github PK

Be able to bind / convert to these types. IPEndpoint seems to be .NET Core 3 only.

CompositeSettingsDictionary.AsString() fails when the dictionary is empty because it calls IEnumerable.Max() on the key.Length.

Changing Settings.Environment should reload from SettingsDictionary into the cache and fire PropertyChanged for any properties that change de to the Environment change.

Change name of Environment to Configuration, make it readonly property
and provide a method to change it, such as SwitchConfiguration(string)

Look at the builder method UseCommandLine. Add a source that takes a string array and parses into key/values. Maybe use an optional prefix like the other providers? So the following should result in 2 key/value pairs:

"--CoffeeshopSettings.EspressoMachineEnabled=true"
"--CoffeeShopSettings.TimeBetweenRefills=00:10:00"

Do we want this format: "--key=value"
Or do we want two consecutive array slots: "--key" "value"
Maybe support both?

Add a SettingsSrouce based on Hashicorp Vault. New project and new nuget

requireAll means that all properties on the bound object must be present in the configuration data which is not a sensible default.

Actual code:

var settingsBuilder = new SettingsBuilder().UseAppSettingsXml();
var settings = settingsBuilder.Build();
var serviceSettings = settings.Bind<ServiceSettings>(requireAll: true, prefix: "");

Exception:

System.Collections.Generic.KeyNotFoundException: ServiceSettings.SipEnabled
   at Fig.Settings.Get(Type propertyType, String propertyName, String key, Func`1 default)
   at Fig.Settings.Bind[T](T target, Boolean requireAll, String prefix)
   at Fig.Settings.Bind[T](Boolean requireAll, String prefix)

Notice the class name is included in the missing key: ServiceSettings.SipEnabled
This should not be the case when passing an empty string as prefix.

Our team is now bigger than ever :) Where should we hang out and chat? Slack? gitter? whatsapp?

Returns a string with the current configuration and which source each property came from or if default was used. Useful for diagnostics or in the log during startup

A bug with CompositeProvider.TryGet that will always return false. When this is fixed we should also attach some tests to the PR to handle all the scenarios.
https://github.com/rofr/Fig/blob/9e5b91d5fa1ae38829a2811f5dac578c7cbaec35/Fig.Core/CompositeProvider.cs#L31-L44

add this project to up for grabs

Provider that uses a relation database source,

There is no public or protected constructor making it impossible to declare a subclass. Test works because assembly:InternalsVisibleTo

Binding to POCOs supports nested types, but binding for classes that inherit Settings do not. Ideally the binding behavior should be identical but the the implementations are separate and use entirely different approaches due to the how the actual values are kept in memory.

So we could either change the inheritance binding to have the same behavior or integrate so that both approaches use the same code.

Here is a nested type example:
ie:

class MySettings
{
    public MyNestedSettings MyNestedProperty{get;private set;}
}

class MyNestedSettings
{
    public bool WidgetFlag{get;set;}
}

Given the above classes the setting MySettings.MyNestedProperty.WidgetFlag=true will be bound to the corresponding path on objects of type MySettings

Add more tests to StringConversionTests for various types:

• float
• short
• byte
• ushort
• uint
• long
• ulong
• Enumerations

What else?

Write unit tests for the ini file format

key1=This is a string with spaces
[Section.A]
ScanInterval=00:25:00
#comment
[OtherSection]
key3=300

should yield these 3 keys:

• key1
• Section.A.ScanInterval
• OtherSection.key3

What are your thoughts on adding these to the IProvider interface?

bool TryGetValue<T>(string key, out T value);
T Get<T>(string key);

If it's ok with you, I can add them along with some tests.

The environment qualier is appended using a ':' as separator. This works in INI-files and XML files but perhaps not appSettings.json because ':' is used as a path separator in JSON. I think it could be put it inside the attribute name like this:

{
   "MySetting" : 42,
   "MySetting:PROD" : 43
}

So the question is: Does the above already work and is it a good approach? I think the colon inside the attribute might cause some confusion.

A simple unit test answer the 'does it work' question. One thing that does not work though, if we decide to go this path, is having the qualifier above a nested object. (see #22 )

{
    "MySetting:PROD" : {
      "a":1,
     "b":2
    }
} 

this would translate into keys:
MySetting:PROD.a
MySetting:PROD.b

It seems like a rewrite of each key where the qualifier is moved to the the end would do trick. Actually, we could use the rewrite hack for INI files (#22 again) and other hierarchical sources as a postprocessing step on the settings dictionaries.

Given the following key/value pairs, we want Config to be used to set the current configuration.

ENV=PROD
ServiceUrl=http://localhost:8080/
ServiceUrl:PROD=https://myserver.com/
ServiceUrl:TEST=https://test.myserver.com/

We could do this with code like this:

var settings = new SettingsBuilder()
   .UseAppSettingsJson()
   .Build<MySettings>();
settings.SetEnvironment(settings.Get("Config"));

but it would be elegant to do this directly on the builder, allowing the setting to take effect in subsequent steps, ie:

var settings = new SettingsBuilder()
   .UseCommandLine(),
   .UseEnvironmentVariables()
   .SetEnvironment("${ENV}")
   .UseAppSettingsJson()
   .Build<MySettings>();

The following should be equivalent:

[MySection:PROD]
mySetting1=a
mySetting2=b

[MySection:TEST]
mySetting1=c
mySetting2=d

[MySection]
mySetting1=e
mySetting2=f

[MySection]
mySetting1:PROD=a
mySetting2:PROD=b
mySetting1:TEST=c
mySetting2:TEST=d
mySetting1=e
mySetting2=f

An array in JSON translates into keys with numeric indexes, ie:

"brokers" : ["10.0.0.1", "10.0.0.2"]

will translate into the key/value pairs:

brokers.0=10.0.0.1
brokers.1=10.0.0.2

When we retrieve we want to be able to convert to array, ie:

var brokers = settings.Get<string[]>("brokers");

and a typed settings class:

class MySettings
{
   public string[] Brokers => Get<string[]>();
}

settings.ExpandVariables("this is ${KEY} fun") will replace the key if it exists and return a new string. This is on the settings dictionary class but expose it on the Settings class so the user can benefit as well

Populate the properties on a POCO that match the keys in the SettingsDictionary by using reflection.

Get this thing on AppVeyor or Azure Devops or similar so we can build, run tests and push packages on commit to master

Or just shove it all into a single project/package.

Currently, the AppSettingsXml source is in a separate project (and separate nuget package).
The reason is to minimize dependencies in the core package. In this case System.Configuration is the additional dependency.

All the other sources are in the core project: ini, json,env vars, command line. The json source uses the new System.Json so to follow the pattern this should have gone to a separate project as well.

What's your opinion here @myty ?