如何在现有EF6项目中保留SQL Server并新增PostgreSQL支持

核心配置修正（先解决提供程序错位问题） #

自动生成的配置存在致命错误：将默认连接工厂设置为Npgsql会导致所有未显式指定提供程序的数据库连接默认走PostgreSQL客户端，直接破坏原有SQL Server逻辑，也是后续连接串解析错位的核心诱因。请先将entityFramework配置节修改为以下内容：

<entityFramework>
    <!-- 保留SQL Server作为默认连接工厂，不要修改为Npgsql -->
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
    <providers>
      <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
      <provider invariantName="Npgsql" type="Npgsql.NpgsqlServices, EntityFramework6.Npgsql" />
    </providers>
</entityFramework>

system.data下的DbProviderFactories配置可以保留，不需要修改。

解决加密/明文连接字符串共存报错 #

该报错触发原因是.NET的配置节加密机制要求connectionStrings节必须全加密或全明文，不支持单节内混合加密和明文条目，对应两种解决方案：

• 开发调试阶段：临时解密原有SQL Server连接字符串，待PostgreSQL连接字符串写入配置后，重新对整个connectionStrings节做加密，生产环境部署时两个连接串同属加密节就不会触发该错误。
• 无侵入方案：运行ADO.NET实体数据模型向导时，选择不将连接字符串保存到web.config，后续通过代码硬编码或自定义配置源加载PostgreSQL连接串，完全不触碰原有加密的配置节。

解决连接串解析错位、参数不识别问题 #

出现“用SQL Server提供程序解析PostgreSQL连接串”的问题，核心原因是EF6默认会读取连接串配置的providerName属性选择对应提供程序，未显式指定时默认使用System.Data.SqlClient，必然无法识别PostgreSQL的连接参数。

配置文件存储连接串的正确写法 #

必须给PostgreSQL的连接串条目显式添加providerName="Npgsql"属性：

<add 
  name="PostgreSqlDbContext" 
  connectionString="Server=你的PG地址;Port=5432;Database=库名;User Id=账号;Password=密码;Persist Security Info=true;" 
  providerName="Npgsql" 
/>

硬编码连接串的正确写法 #

如果不走配置文件，需要在PG对应的DbContext构造函数中显式传入Npgsql连接实例，避免EF走默认的SQL Server工厂解析：

public class PostgreSqlDbContext : DbContext
{
    // 显式传入Npgsql连接实例，第二个参数true表示EF接管连接生命周期
    public PostgreSqlDbContext() 
        : base(new NpgsqlConnection("Server=你的PG地址;Port=5432;Database=库名;User Id=账号;Password=密码;"), true)
    {
        // 注册Npgsql的EF拦截器，保证SQL生成正确
        DbInterception.Add(new NpgsqlEFInterceptor());
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        // PostgreSQL默认schema为public，必须显式指定，否则会去dbo schema找表报错
        modelBuilder.HasDefaultSchema("public");
    }

    // PG数据库对应的DbSet定义在此处
}

VS2022环境下无需回退VS2019的模型生成方案 #

官方停更的Npgsql PostgreSQL Integration扩展不是必须依赖，直接安装社区维护的EF6 Power Tools扩展即可在VS2022下连接PostgreSQL生成Database First的EDMX模型，操作逻辑与原官方扩展完全一致，不需要回退VS版本。

注意事项 #

• Npgsql版本不要选择7.x及以上的大版本，EntityFramework6.Npgsql最高兼容Npgsql 6.x稳定版，过高版本会出现类型映射、SQL生成的兼容性问题。
• 原有SQL Server的DbContext和新增的PostgreSQL的DbContext必须完全独立，不要在同一个上下文内混合两个数据库的实体，EF6不支持单上下文跨提供程序查询。
• 部署时注意应用程序池的32/64位架构要和引用的Npgsql程序集目标架构一致，否则会出现找不到NpgsqlFactory的启动错误。

内容的提问来源于stack exchange，提问作者edgar_is