迁移至.NET Standard的NuGet包如何兼容读取Web.config与appsettings.json？

一、优雅的跨框架实现方式 #

最合理的方案是抽象接口+多框架适配，结合.NET Standard作为目标框架，通过依赖注入或自动检测机制适配不同环境的配置源：

1. 定义抽象配置读取接口 #

先抽离核心配置读取逻辑，让上层代码完全依赖抽象而非具体实现：

public interface IAppSettingsReader
{
    // 获取字符串配置
    string GetString(string key);
    // 获取强类型配置
    T GetValue<T>(string key);
}

2. 针对不同框架实现具体逻辑 #

• .NET Framework 实现：基于ConfigurationManager读取Web.config/App.config

public class FrameworkAppSettingsReader : IAppSettingsReader
{
    public string GetString(string key)
    {
        return System.Configuration.ConfigurationManager.AppSettings[key];
    }

    public T GetValue<T>(string key)
    {
        var value = GetString(key);
        return value == null ? default : (T)Convert.ChangeType(value, typeof(T));
    }
}

• .NET Core/.NET 5+ 实现：基于IConfiguration读取appsettings.json

public class CoreAppSettingsReader : IAppSettingsReader
{
    private readonly IConfiguration _config;

    public CoreAppSettingsReader(IConfiguration config)
    {
        _config = config;
    }

    public string GetString(string key)
    {
        return _config[key];
    }

    public T GetValue<T>(string key)
    {
        return _config.GetValue<T>(key);
    }
}

3. 适配与注册逻辑 #

• 自动检测方式：通过工厂类判断当前运行环境，返回对应实现（适合无DI的场景）

public static class AppSettingsReaderFactory
{
    public static IAppSettingsReader Create()
    {
        // 通过类型检测判断是否为.NET Core环境
        var isCoreEnv = Type.GetType("Microsoft.Extensions.Configuration.IConfiguration, Microsoft.Extensions.Configuration") != null;
        
        if (isCoreEnv)
        {
            // .NET Core下自动构建配置（或允许外部传入已配置的IConfiguration）
            var config = new ConfigurationBuilder()
                .SetBasePath(Directory.GetCurrentDirectory())
                .AddJsonFile("appsettings.json", optional: true)
                .Build();
            return new CoreAppSettingsReader(config);
        }
        else
        {
            return new FrameworkAppSettingsReader();
        }
    }
}

• 依赖注入方式：提供扩展方法让用户在各自框架的DI容器中注册对应实现（推荐）
  • .NET Core扩展：

    public static class ServiceCollectionExtensions
    {
        public static IServiceCollection AddAppSettingsReader(this IServiceCollection services)
        {
            services.AddSingleton<IAppSettingsReader, CoreAppSettingsReader>();
            return services;
        }
    }
    

  • .NET Framework可结合Unity、Autofac等DI容器注册FrameworkAppSettingsReader。

替代方案：统一使用Microsoft.Extensions.Configuration #

直接基于Microsoft.Extensions.Configuration库（支持.NET Framework 4.6.1+、.NET Standard），统一配置读取逻辑：

• .NET Core下读取appsettings.json的逻辑不变；
• .NET Framework下通过AddXmlFile读取Web.config/App.config的AppSettings节点：

  var config = new ConfigurationBuilder()
      .AddXmlFile("Web.config", optional: true, reloadOnChange: true)
      .Build();
  

这种方式无需自己实现抽象层，直接复用官方配置体系，兼容性更强。

二、跨框架兼容方案的合理性 #

这种方案完全合理，原因如下：

• 符合开闭原则：抽象层隔离了底层配置源的差异，上层业务代码无需修改即可在不同框架运行；
• 依托.NET Standard的跨框架能力，单一NuGet包即可覆盖所有目标框架，减少维护成本；
• 适配现代.NET开发模式（如依赖注入），同时兼容旧版.NET Framework的传统配置方式。

三、拆分独立NuGet包的合理性 #

如果核心目标是实现独立于.NET版本的配置读取能力，则不建议拆分两个独立包：

• 拆分包会增加维护成本：功能更新需同步修改两个包，易出现版本不一致；
• 增加用户使用成本：用户需要根据自身框架选择对应包，不符合"版本无关"的核心目标；
• 仅当两种框架的实现差异极大（如无法通过条件编译或抽象层兼容）时，才考虑拆分，但这种场景极少。

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