I have an ASP.NET Core 2 Web API using Entity Framework code first. My DbContext
is not in the same assembly as the API itself so to allow me to use the Microsoft.EntityFrameworkCore.Tools.DotNet
tooling I've added an implementation of IDesignTimeDbContextFactory<MyDbContext>
to the DbContext
's project:
public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<MyDbContext>
{
private static IConfiguration _configuration;
public static IConfiguration Configuration
{
get
{
if (_configuration != null) return _configuration;
_configuration = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddJsonFile($"appsettings.{EnvName ?? "Production"}.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
return _configuration;
}
}
public MyDbContext CreateDbContext(string[] args)
{
var builder = new DbContextOptionsBuilder<MyDbContext>();
var connectionString = Configuration.GetConnectionString("MyConnString");
var migrationsAssembly = typeof(MyDbContext).GetTypeInfo().Assembly.GetName().Name;
builder.UseSqlServer(connectionString, b => b.MigrationsAssembly(migrationsAssembly));
return new MyDbContext(builder.Options);
}
}
I don't have an appsettings.json
in this project, but I have added a system environment variable with the name ConnectionStrings:MyConnString
and the value of my connection string.
When I run a tooling command such as dotnet ef migrations add "Whatever"
then I get an error saying connection string cannot be null. So I guess the configuration builder is not reading my environment variable. If I replace the variable connectionString
with a hard-coded connection string it works fine.
Can anyone tell me how to get this working? Is there an alternative to using environment variables perhaps which still keeps my connection string secret? As far as I'm aware, user secrets can only be used with web projects.
IDesignTimeDbContextFactory
is, as the name implies, only for development . It doesn't support, or really have any concept of, environments. It's simply a way to run migrations against a class library, which because it's not a startup project, has no way to actually have the DbContext
injected in.
Long and short, the docs hard-code the connection string for a reason. There's no reason to not hard-code it as it can only ever be that one connection string that's used.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.