Ways to manage configuration in project with multiple tiers

.net-core asp.net-core c# entity-framework-core


ASP.NET Core project template comes with appsettings.json and appsettings.Development.json and it is added by default in CreateDefaultBuilder.

Because the project with DbContext is separate from my ASP.NET Core project (MyProject.Data) I am required to implement IDesignTimeDbContextFactory for my context in order for commands like Add-Migration and Update-Database to work. I don't want to hardcode my connection string for my IDesignTimeDbContextFactory but re-use the config in both projects.

I have few solutions for it but I want to know what's the most reasonable based on your experiences and opinions.

  • Implement IDesignTimeDbContextFactory in my ASP.NET Core (UI layer) project.
  • Implement IDesignTimeDbContextFactory in my MyProject.Data project, and move appsettings.json to some root directory, or configuration (located at root) directory shared between projects.
  • Create separate configuration file for database like database.json put it alongside my .sln file.

How should I share this?


There's similar question and answer here: ConnectionString from appsettings.json in Data Tier with Entity Framework Core but it doesn't answer my question. It doesn't say anything about data tier at all. I don't want to re-use logic for adding db context. I want to re-use connection string in two projects to avoid duplicating connection strings.

6/11/2018 10:54:32 AM

Accepted Answer

While is it usually advised to have configuration in a central location, there is nothing restricting individual projects from managing their own configuration.

In the following example the connection string information is stored in an external datasettings.json file

  "ConnectionStrings": {
    "DefaultConnection": "connection string here"

A simple example of a self contained setup extension for the layer could look like

public static class MyServiceCollectionExtensions {
    public static IServiceCollection AddMyDataLayer(this IServiceCollection services, string name = "DefaultConnection") {
        var builder = new ConfigurationBuilder()
            .AddJsonFile("datasettings.json"); //<<< just an example

        var connectionStringConfig = builder.Build();

            .AddDbContext<YourDbContext>((serviceProvider, options) =>
         return services;

And added in Startup

using my.data.layer;


public void ConfigureServices(IServiceCollection services) {




The data layer in this case manages its own configuration. Its settings file external to the application settings.

There is room for expansion as additional options could be managed locally as well and works well for drop-in turn key plug-in solutions for example.

The module nature of Configuration in ASP.NET Core allows for such flexibilities.

6/11/2018 12:48:49 PM

Popular Answer

My approach/opinion to this topic:

Use a connection String in every top layer application using your DbContext like API/Backend/Frontend because they could run on different servers. So they should have their own settings file.

To handle Migrations from the Library without connection string you can use the following approach:

cd /projectWithContextImpl

dotnet ef -s "../projectWithConnString/" migrations list -c NameOfContext

I hope this somewhat answers your question.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow