为何两个.NET Framework 4.6.1应用的System.Configuration引用不一致？

1. 命名空间冲突+程序集引用缺失 #

• 命名空间冲突：NLog程序集内部存在同名的ConfigurationManager类型，当项目引用NLog且未显式指定命名空间时，编译器会优先解析NLog的内部类型，导致代码中的ConfigurationManager指向NLog.Internal.ConfigurationManager。
• 程序集引用缺失：异常项目虽代码里写了using System.Configuration;，但并未添加对独立System.Configuration.dll程序集的引用。此时编译器会把System.Configuration解析为System.dll里的同名命名空间（仅包含ClientSettingsSection等少量类型，无ConfigurationManager），而非真正承载ConfigurationManager的System.Configuration.dll。

2. 两应用引用方式不同的原因 #

• 正常应用显式添加了System.Configuration.dll引用：项目引用列表中存在该程序集，编译器优先加载其包含的System.Configuration命名空间，因此能正确识别ConfigurationManager。
• 异常应用未添加对应程序集引用：可能是项目创建时未自动引入，或后续操作中误删了引用；加上NLog的依赖不会自动触发System.Configuration.dll的引用，导致编译器只能找到System.dll里的同名命名空间。

• 步骤1：添加System.Configuration.dll引用
  右键项目 → 选择「添加」→「引用」→ 在「程序集」→「框架」列表中找到System.Configuration（版本4.0.0.0，对应.NET Framework 4.6.1的Reference Assemblies路径），勾选后确定添加。
• 步骤2：解决命名空间冲突
  可选两种方式：
  1. 使用完全限定名调用：直接写System.Configuration.ConfigurationManager.AppSettings["KeyName"]，明确指定系统程序集的类型。
  2. 给系统命名空间加别名：在代码顶部添加别名指令，示例：

     using SysConfig = System.Configuration;
     

     之后用SysConfig.ConfigurationManager访问，避免与NLog内部类型冲突。
• 步骤3：清理并重新生成项目
  执行「Build → Clean Solution」清理缓存，再执行「Build → Rebuild Solution」，确保编译器加载正确的程序集。

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