CODEWITHSUNDEEP
c#asp.net-core.net-coreentity-framework-coreentity-framework-migrations
NP3
NP3

Reputation: 1264

Command line connection string for EF core database update

Using ASP.NET Core and EF Core, I am trying to apply migrations to the database. However, the login in the connection string in appsettings.json that the app will use has only CRUD access, because of security concerns, so it can't create tables and columns, etc. So, when I run:

dotnet ef database update -c MyDbContextName -e Development

I want to tell it to use a different connection string, but I don't know if this can be done? Basically, I want to use two different connection strings, one for deployment and one for running the app. Is this possible? Is there a better approach? Thanks.

Upvotes: 49

Views: 59479

Answers (8)

Robert
Robert

Reputation: 2208

Now in EF Core 9.0 you can have this in your code

public class BloggingContextFactory : IDesignTimeDbContextFactory<BloggingContext>
{
    public BloggingContext CreateDbContext(string[] args)
    {
        //TODO: Validate args first ...
        var connectionString = args[0];

        var optionsBuilder = new DbContextOptionsBuilder<BloggingContext>();
        optionsBuilder.UseSqlite(connectionString);

        return new BloggingContext(optionsBuilder.Options);
    }
}

Then you can

dotnet ef database update -- "your connection string"

See https://learn.microsoft.com/en-us/ef/core/cli/dbcontext-creation?tabs=dotnet-core-cli#from-a-design-time-factory

Upvotes: 0

KGC
KGC

Reputation: 141

I solved it this way, inspired by Javier Colombera's answer.

I ran the following on Windows in a Bash terminal and got the expected result:

export ASPNETCORE_ENVIRONMENT="Production"
export ConnectionStrings__DefaultConnection="SslMode=Prefer;TrustServerCertificate=true;Host=<value>;Port=<value>;Database=<value>;Username=<value>;Password=<value>"
dotnet ef database update

This lets me avoid storing my production database connection string in version control, by overwriting the ConnectionStrings.DefaultConnection value in appsettings.json via an environment variable.

Note that my project does not define a default connection string for the Staging and Production environments, only one is defined for the local Development environment.

Upvotes: 3

Mahmoud Farahat
Mahmoud Farahat

Reputation: 5485

if you are using the Package Manager Console use the following command:

Update-Database -Connection "YOUR_CONNECTION_STRING"

Upvotes: 10

smj
smj

Reputation: 466

dotnet ef database update --configuration Debug

Upvotes: -7

Javier Colombera
Javier Colombera

Reputation: 61

In a Linux terminal:

export ASPNETCORE_ENVIRONMENT="Development"
dotnet ef database update

Where ASPNETCORE_ENVIRONMENT match with appsettings.Development.json and the properly connectionstring configured.

Upvotes: 6

Vivek Nuna
Vivek Nuna

Reputation: 1

In EF Core 5.0, you will pass the connection string in the command line like this,

dotnet ef database update --connection "connection string"

Reference: https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/whatsnew#new-command-line-parameters-for-namespaces-and-connection-strings

Upvotes: 72

Ilya Chumakov
Ilya Chumakov

Reputation: 25039

Keep both connection strings in appsettings.json. Inherit a child context class from the main one and override OnConfiguring with another connection string:

public class ScaffoldContext : MyDbContextName 
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        string scaffoldConnStr = ConfigurationManager.ConnectionStrings["scaffoldConnStr"].ConnectionString;

        optionsBuilder.UseSqlServer(scaffoldConnStr);
    }
}

Then use:

dotnet ef database update -c ScaffoldContext

Upvotes: 25

superjos
superjos

Reputation: 12725

I liked the idea of a scaffolding DbContext, but I found some issues (somehow solvable, I guess) and also some consideration on where to keep connection strings. Those led me to another, more crude solution, so I thought I'd share all that here.

This is about the general approach, and consequent solution:

  1. I don't like to store staging/production connection strings under source control. So I would pass that through an environment variable set in a temporary command window (or maybe on the fly on command-line, although I was not able to make that work). At that point, if I'm setting an environment variable, I might as well override initial connection string used by MyDbContextName, instead of adding a new one. Thus the whole scaffolding DB context thing could be overcome doing this way.

Other issues I found along the way:

  1. Initial DbContext had dependencies injected into constructor, so child context had to to the same. This made dotnet ef commands complain about missing parameterless constructor.

  2. To overcome that, child context as well was registered at startup with .AddDbContext<ChildDbContext>(...). This also required for ChildDbContext to be injected both with a DbContextOptions<ParentDbContext> as well as a DbContextOptions<ChildDbContext>. After that, dotnet-ef still found issues with instantiating ChildDbContext, as that needed also a dependency on IConfiguration which could not be found. Maybe (?) this is due to the fact that dotnet-ef does not run through the whole application startup.

As I said, I guess the issues could be solved after all, but still I'm questioning the real value of a scaffolding context in case you don't want to save connection strings in dedicated appsettings files. One counter argument could be that you might forget the environment variable set to the remote connection string, but then you just have to close the command window as soon as you complete migration. HTH

Upvotes: 5

Related Questions