https://github.com/egorikas/dot-net-core-shared-configuration
Example of the shared .net configuration project.
https://github.com/egorikas/dot-net-core-shared-configuration
asp-net-core asp-net-mvc configuration dot-net shared shared-configuration
Last synced: about 2 months ago
JSON representation
Example of the shared .net configuration project.
- Host: GitHub
- URL: https://github.com/egorikas/dot-net-core-shared-configuration
- Owner: egorikas
- License: mit
- Created: 2017-07-21T14:05:12.000Z (almost 9 years ago)
- Default Branch: master
- Last Pushed: 2017-07-23T18:07:21.000Z (almost 9 years ago)
- Last Synced: 2025-08-15T03:03:23.959Z (10 months ago)
- Topics: asp-net-core, asp-net-mvc, configuration, dot-net, shared, shared-configuration
- Language: C#
- Homepage:
- Size: 9.77 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# .NET Core shared configuration example
[](https://ci.appveyor.com/project/EgorGrishechko/dot-net-core-shared-configuration)
[](LICENSE.md)
## What is the reason?
New configuration system for .NET Core is really awesome.
But in official stylyguides it always uses in the main ASP.NET Core app.
But what if we have other apps in the solution? Or we need to share configuration settings between projects?
Additional info in my [blog-post](http://egorikas.com/asp.net-core-shared-configuration/).
### Entity Framework Core
It's even getting worse, when we want to use `Migrations` from [EF Core](https://docs.microsoft.com/en-us/ef/).
If we don't have parameter less constructor in our `DbContext`, there is a need for implementing `IDbContextFactory`.
And in this case we star to face off a problem with passing `connection string` to our context.
[Official documentation](https://docs.microsoft.com/en-us/ef/core/miscellaneous/configuring-dbcontext) contains an example with hard-coded connection string
```csharp
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Infrastructure;
namespace MyProject
{
public class BloggingContextFactory : IDbContextFactory
{
public BloggingContext Create()
{
var optionsBuilder = new DbContextOptionsBuilder();
optionsBuilder.UseSqlite("Data Source=blog.db");
return new BloggingContext(optionsBuilder.Options);
}
}
}
```
I don't think, that this is a flexible and right way to do this kind of fabric.
So, with the solution has been written by me, it looks in the next way
```csharp
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Infrastructure;
namespace MyProject
{
public class BloggingContextFactory : IDbContextFactory
{
public BloggingContext Create()
{
var configurationRoot = SettingsProvider.GetConfigurationRoot(new EnvironmentProvider());
var optionsBuilder = new DbContextOptionsBuilder();
//In my project I put "mainDb" to ConfigurationConstants class
optionsBuilder.UseSqlite(configurationRoot.GetConnectionString("mainDb"));
return new BloggingContext(optionsBuilder.Options);
}
}
}
```
There is the [article](https://www.benday.com/2017/02/17/ef-core-migrations-without-hard-coding-a-connection-string-using-idbcontextfactory/) with the alternative way for solving this problem. But I don't like it due to low flexibility of configuration settings.
## Build
Install [.NET Core SDK](https://www.microsoft.com/net/download/core "official site")
Open folder with `Configuration.sln` in the shell.
Then
```
dotnet restore
dotnet build
```
## Tests
Open folder with `Configuraion.Test.csproj` in the shell.
Then
```
dotnet test
```