.NET Configuration providers for Spring Cloud Config Server & CloudFoundry
Перейти к файлу
Dave Tillman 76f09e3436 Fix project.json 2016-11-18 07:24:40 -07:00
scripts More changes for .Net Core 1.1 update 2016-11-18 06:52:35 -07:00
src Fix project.json 2016-11-18 07:24:40 -07:00
test Bump to .Net Core 1.1, Asp.Net Core 1.1, xunit 2.2-beta4 2016-11-17 16:15:42 -07:00
.gitattributes Initial CI checkin 2016-04-17 08:12:33 -06:00
.gitignore Initial Config Server provider check-in 2016-01-04 09:52:33 -08:00
.travis.yml Fixup travis build 2016-07-01 11:40:06 -06:00
Configuration.sln Bump to .Net Core 1.1, Asp.Net Core 1.1, xunit 2.2-beta4 2016-11-17 16:15:42 -07:00
License.txt Add Apache License file: License.txt 2016-01-13 06:47:06 -08:00
README.md Fix project.json 2016-11-18 07:24:40 -07:00
appveyor.yml SteelToe -> Steeltoe [#130554549] 2016-09-19 10:24:26 -04:00
global.json Bump to .Net Core 1.1, Asp.Net Core 1.1, xunit 2.2-beta4 2016-11-17 16:15:42 -07:00

README.md

.NET Configuration Providers

With the introduction of ASP.NET Core, Microsoft is providing a new application configuration model for accessing configuration settings for an application. This new model supports access to key/value configuration data from a variety of different configuration providers or sources. Out of the box, ASP.NET Core comes with support for JSON, XML and INI files, as well as environment variables and command line parameters. Additionally, Microsoft has also enabled developers to write their own custom configuration providers should those provided by Microsoft not meet your needs.

This repo contains two custom configuration providers. The Steeltoe.Extensions.Configuration.ConfigServer enables using the Spring Cloud Config Server as a provider of configuration data and the Steeltoe.Extensions.Configuration.CloudFoundry provider enables CloudFoundry environment variables to be parsed and accessed as configuration data.

Windows Master (Stable): AppVeyor Master

Windows Dev (Less Stable): AppVeyor Dev

Linux/OS X Master (Stable): Travis Master

Linux/OS X Dev (Less Stable): Travis Dev

.NET Runtime & Framework Support

Like the ASP.NET Core configuration providers, these providers are intended to support both .NET 4.5.1+ and .NET Core (CoreCLR/CoreFX) runtimes. The providers are built and unit tested on Windows, Linux and OSX.

While the primary usage of the providers is intended to be with ASP.NET Core applications, they should also work fine with UWP, Console and ASP.NET 4.x apps. An ASP.NET 4.x sample app is available illustrating how this can be done.

Currently all of the code and samples have been tested on .NET Core 1.1, .NET 4.5.1/4.6.x, and on ASP.NET Core 1.1.0.

Usage

See the Readme for each provider for more details on how to make use of it in an application.

Nuget Feeds

All new configuration provider development is done on the dev branch. More stable versions of the providers can be found on the master branch. The latest prebuilt packages from each branch can be found on one of two MyGet feeds. Released version can be found on nuget.org.

Development feed (Less Stable) - https://www.myget.org/gallery/steeltoedev

Master feed (Stable) - https://www.myget.org/gallery/steeltoemaster

Release or Release Candidate feed - https://www.nuget.org/.

Building Packages & Running Tests - Windows

To build the packages on windows:

  1. git clone ...
  2. cd
  3. Install .NET Core SDK
  4. dotnet restore src
  5. cd src<project> (e.g. cd src\Steeltoe.Extensions.Configuration.CloudFoundry)
  6. dotnet pack --configuration Release or Debug

The resulting artifacts can be found in the bin folder under the corresponding project. (e.g. src\Steeltoe.Extensions.Configuration.CloudFoundry\bin

To run the unit tests:

  1. git clone ...
  2. cd
  3. Install .NET Core SDK
  4. dotnet restore test
  5. cd test<test project> (e.g. cd test\Steeltoe.Extensions.Configuration.CloudFoundry.Test)
  6. dotnet test

Building Packages & Running Tests - Linux/OSX

To build the packages on Linux/OSX:

  1. git clone ...
  2. cd
  3. Install .NET Core SDK
  4. dotnet restore src
  5. cd src/ (e.g.. cd src/Steeltoe.Extensions.Configuration.CloudFoundry)
  6. dotnet pack --configuration Release or Debug

The resulting artifacts can be found in the bin folder under the corresponding project. (e.g. src/Steeltoe.Extensions.Configuration.CloudFoundry/bin

To run the unit tests:

  1. git clone ...
  2. cd
  3. Install .NET Core SDK
  4. dotnet restore test
  5. cd test<test project> (e.g. cd test/Steeltoe.Extensions.Configuration.CloudFoundry.Test)
  6. dotnet test --framework netcoreapp1.1

Sample Applications

See the Samples repo for examples of how to use these packages.

Known limitations

Using Options and Configuration

When using the Microsoft provided Option extension framework you will find that the Options POCO does not update with new values if the configuration is refreshed with new values from the Config server. This is a known limitation of the Options framework.

If you retrieve values from the IConfiguration directly, you will see the updated values, they just will not be reflected in the Options POCO.

Example:

Having configured a ConfigServerData POCO through IOC

public IConfigurationRoot Configuration { get; }
...
services.Configure<ConfigServerData>(Configuration);

If ConfigServerData.SomeProperty has an initial value of foo after startup, and then you change the value for the property from foo to bar in the Config Server Git repo and then somewhere in your code you call:

Configurtion.Reload();

you will find that ConfigServerData.SomeProperty will still have the value of foo. But, if you directly reference the IConfiguration, you will see the updated property value.

var value = Configuration["SomeProperty"]; // value == 'bar'

This is a known limitation of the Options framework.

Unstructured data files

Unlike the Java version of the configuration server client, the Steeltoe client currently only supports property and yaml files; not plain text.

Client decryption

Steeltoe client only supports clear text communication with the configuration server. Client decryption is on our roadmap, but not currently supported. For now, you cannot send encrypted data to the client.

Server initiated reload

Currently reloads must be initiated by the client, Steeltoe has not implemented handlers to listen for server change events.