.NET 6类库项目创建经典Properties.Settings的方案是否合理？

1. System.Configuration.Abstractions到底是干啥的 #

这个包是社区做的传统System.Configuration命名空间抽象层，核心目的是解决.NET Framework时代配置代码难测试的问题——它把ConfigurationManager这类静态类封装成了IConfigurationManager接口，让你能在单元测试里用模拟实现替换真实配置，不用硬依赖系统静态类。它本身不是官方用来替代经典Application Settings的方案，只是个适配工具。

2. 你当前的解决流程：权宜之计，不推荐长期用 #

• 它能消掉CS1069错误，是因为包里包含了ApplicationSettingsBase的兼容定义，但本质是绕开了.NET 6+的配置体系设计。
• 经典Application Settings是.NET Framework的老东西，.NET Core/.NET 5+之后官方已经弃用这个体系，转向Microsoft.Extensions.Configuration（支持JSON、环境变量、XML等多源配置）作为标准方案。
• 类库手动加Settings.settings和App.config会有坑：类库本身不会自动读取自己的配置文件，最终还是要依赖WPF宿主项目的配置加载逻辑，很容易出现配置读不到、读取结果不符合预期的问题。

3. 推荐的正确做法 #

方案一：改用.NET 6+官方配置系统（首选） #

1. 给类库装NuGet包：Microsoft.Extensions.Configuration、Microsoft.Extensions.Configuration.Json（根据你需要的配置源选，比如要XML就装Microsoft.Extensions.Configuration.Xml）。
2. 定义强类型配置类：

   public class LibrarySettings
   {
       public string ServiceEndpoint { get; set; }
       public int RetryCount { get; set; }
   }
   

3. 在WPF项目里加载配置（比如appsettings.json），然后通过依赖注入把配置实例传给类库，或者让类库直接通过IConfiguration接口读取配置。

方案二：硬要沿用经典Settings（不推荐，但能凑合用） #

别在类库单独建Settings，把所有配置都放在WPF项目的Settings里，类库直接引用WPF项目的Properties.Settings.Default来访问配置——这样能保证配置加载逻辑和WPF一致，也不用装第三方包。

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