在迁移期间使用存储在环境变量中的数据库连接字符串答案

【问题标题】：Using a database connection string stored in environment variable during migrations在迁移期间使用存储在环境变量中的数据库连接字符串
【发布时间】：2020-03-09 14:31:27
【问题描述】：

我有 ASP.NET Core 项目，我将 PostgreSQL 连接字符串存储在环境变量中。当我尝试进行初始迁移时，项目的构建成功，但随后抛出异常：

System.ArgumentNullException：值不能为空。（参数'connectionString'）。

所以我假设它没有正确读取连接字符串。我在 ConfigureServices 方法中为我的 DbContext 提供连接字符串，如下所示：

services.AddDbContext<GoalsContext>(options =>  
  options.UseNpgsql(Environment.GetEnvironmentVariable("CONNECTION_STRING")));

我还尝试通过创建 IDesignTimeDbContextFactory 的实现来解决此问题，如下所示：

public class GoalsContextFactory : IDesignTimeDbContextFactory<GoalsContext>
{
  public GoalsContext CreateDbContext(string[] args)
  {
    var optionsBuilder = new DbContextOptionsBuilder<GoalsContext>();
    optionsBuilder.UseNpgsql(Environment.GetEnvironmentVariable("CONNECTION_STRING");

    return new GoalsContext(optionsBuilder.Options);
  }
}

任何帮助将不胜感激。

更新： 我已经按照 cmets 中的建议阅读了有关环境变量和配置的官方文档，并且我首先通过使用一种方法创建控制器来检查变量是否存在，该方法返回如下连接字符串：

[HttpGet]
public string GetConnectionString()
{
  return _config["CONNECTION_STRING"];
}

当我启动浏览器时，确实会在浏览器中显示正确的连接字符串，但是当我尝试将初始迁移添加到数据库时，仍然会抛出我已经提到的异常。

我还尝试注释掉我的 IDesignTimeDbContextFactory 实现，并在我的 Program.cs 中手动添加对 .AddEnvironmentVariables 方法的调用（我阅读的是自动完成的，但我仍然想尝试），但这些都没有任何效果 - 我的控制器仍然发出连接字符串，而 Entity Framework Core 的迁移仍然没有收到它。

简而言之，是的，连接字符串存在，我什至可以输出它，但是由于同样的异常，迁移仍然失败。

【问题讨论】：

环境变量是否存在？不要使用单行，将环境变量值存储在临时变量中并调试代码。异常表明它为空，这意味着它在运行此代码时根本没有设置
顺便说一句，这与 EF 或 EF 迁移无关。甚至没有 ASP.NET Core，因为您直接调用 Environment.GetEnvironmentVariable。这意味着没有CONNECTION_STRING 环境变量。
正确的方式是在.NET Core中使用环境变量，一般来说是使用Environment variable configuration provider，它允许你将EF之类的服务与配置源解耦，并通过文件、数据库、cli或环境变量提供设置
感谢您的回复，我将阅读您链接的文章的更多内容，并尝试实现这些内容并进行更多调试。我会在完成后发布更新。
我的主要观点是现在没有这样的环境变量。你设置了吗？你是如何测试代码的？

标签： c# asp.net-core entity-framework-core connection-string entity-framework-core-migrations

【解决方案1】：

根据我的评论。

见Command Line Environment Variables

另外，如果你想绕过变量的设置，你需要查看 Context 的 OnConfiguring 方法重载，并在传入的 DbOptions 参数上使用 IsConfigured 标志以仅从当没有有效的配置传递给上下文时文件。

我需要提醒的是，当其他开发人员使用该解决方案时，这也会导致问题，而且，您不应将读取的文件检查到公共源代码控制存储库中，因为这是人们获取事物凭据的一种方式他们不应该，看看User Secrets

【讨论】：