WPF 项目中的配置陷阱：NewLife 与 MSBuild 的双轨机制

编译期 MSBuild 复制一份文件到输出目录，运行时 NewLife 又在同一个路径创建另一份——它们真的是"覆盖"关系吗？

---

问题背景

在维护一个 WPF 项目（.NET 4.8，旧式 csproj）时，遇到了一个看似诡异的现象：编译完成后，输出目录 bin\Debug 下同时出现了 Data.json 和 Config\Data.json 两个配置文件，它们的内容相同，来源却完全不同。

进一步排查后发现，这个现象与 WPF 框架本身无关，也非 Visual Studio 的界面特性导致——它本质上是两套独立机制的产物：编译期的 MSBuild 与 运行期的 NewLife 配置系统。

项目实况

项目结构如下：

WpfApp1/
├── WpfApp1.csproj          // <None Include="Config\Data.json"> + PreserveNewest
├── Config\
│   └── Data.json            // 25B，初始默认配置
├── bin\Debug\
│   ├── Config\
│   │   └── Data.json        // MSBuild 复制的结果
│   └── Config\              // NewLife 运行时自动创建
│       └── Data.json        // 同一个文件，NewLife 读写同一位置

注意：项目里只有一份 Data.json，bin\Debug 根目录下并没有多余的 json。所谓"两个文件"是运行时的视觉误解——实际上它们指向的是 bin\Debug\Config\Data.json 这一个物理文件。

双轨机制拆解

轨道一：MSBuild 编译期复制

旧式 csproj 中的配置：

<None Include="Config\Data.json">
  <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>

MSBuild 的处理链路：

1. 解析项目文件，Config\Data.json 匹配到 None 集合
2. Build Action 为 None，不参与编译，但 CopyToOutputDirectory=PreserveNewest 触发后置复制任务
3. 按相对路径拼接输出目录：Config\Data.json → bin\Debug\Config\Data.json
4. 确保目标目录存在，然后执行复制

关键点：MSBuild 不会"复制文件夹"，它复制文件时保留的是文件在项目中的相对路径。因为源文件在项目中的路径是 Config\Data.json，输出路径自然就是 bin\Debug\Config\Data.json。

轨道二：NewLife 配置系统

项目使用了 NewLife.Core 的 Config<T> 机制：

[Config("Data", "json")]
public class Data : Config<Data>
{
    public bool Debug { get; set; } = true;
    public string LogPath { get; set; } = "Log";
}

核心链路在 Config<T> 的静态构造函数中：

static Config()
{
    var attr = typeof(TConfig).GetCustomAttribute<ConfigAttribute>();
    var name = attr?.Name ?? typeof(TConfig).Name;  // "Data"
    var provider = ConfigProvider.Create(attr?.Provider);  // JsonConfigProvider
    (provider as ConfigProvider).Init(name);  // Init("Data")
    Provider = provider;
}

Init(name) 是路径解析的唯一入口，以 FileConfigProvider.Init 为例：

步骤	操作	你的场景
1	名字是否以 Config/ 开头？	"Data" 不是 → 加前缀 → "Config/Data"
2	补扩展名	"Data" 无后缀 → 补 .json → "Config/Data.json"
3	取程序运行基目录	bin\Debug\
4	拼接完整路径	bin\Debug\Config\Data.json
5	FileName 赋值完成	后续 Load/Save 全部基于此路径

Config<T>.Current 的 get 访问器完整流程：

public static TConfig Current
{
    get
    {
        if (_Current != null) return _Current;
        lock (typeof(TConfig))
        {
            if (_Current != null) return _Current;
            TConfig val = new TConfig();
            Provider.Bind(val);       // 从文件绑定到对象
            // 如果文件不存在，且 Runtime.CreateConfigOnMissing = true
            if (!Provider.IsNew || Runtime.CreateConfigOnMissing)
            {
                val.Save();           // 创建文件，写入默认值
            }
            return _Current = val;
        }
    }
}

总结：文件不存在 → 自动创建 + 加载；文件存在 → 只读加载。Current 有缓存机制，同一个类型只 Load 一次。

两条轨道的交汇

维度	MSBuild	NewLife
触发时机	编译期（生成时）	运行时（程序启动后）
作用	把项目源文件复制到输出目录	从输出目录读取/写入配置文件
文件路径	bin\Debug\Config\Data.json	bin\Debug\Config\Data.json
读写关系	只读复制，不干预后续	只读或读写，不修改源文件

核心发现：两条轨道读写的是同一个物理文件。MSBuild 在编译期把项目里的 Config\Data.json 复制到输出目录，NewLife 在运行期从同一个路径读取和写入。它们之间没有"覆盖"关系，因为它们根本不在竞争同一个文件——它们操作的就是同一个文件。

什么时候会出现真正的冲突？

如果项目里同时存在两种配置源，冲突才会真正发生：

项目目录/
├── Data.json              // 项目根目录放了一份
├── Config\
│   └── Data.json          // Config 目录又放了一份
└── *.csproj
    <None Include="Data.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>

编译后：

bin\Debug\
├── Data.json              ← MSBuild 从根目录复制
└── Config\
    └── Data.json          ← NewLife 运行时创建（如果不存在就新建）

这就是问题所在：两个路径、两个文件、各自独立。NewLife 读写 Config\Data.json 不会碰根目录的 Data.json，MSBuild 复制根目录的 json 也不会影响 Config\ 目录。运行时修改的是 Config\Data.json，项目里的 Data.json 始终保持初始默认值。

解决方案

统一路径是唯一的正解：让项目源文件、MSBuild 输出路径、NewLife 读写路径三者指向同一个文件。

对于当前项目，项目里只有一份 Config\Data.json，三者已经天然对齐。如果未来需要扩展新的配置文件，统一遵循以下约定：

1. 所有配置文件放在项目 Config 子目录下
2. csproj 中按完整相对路径声明 CopyToOutputDirectory
3. ConfigAttribute 的 name 参数不使用 Config/ 前缀，让 NewLife 自动添加
4. 运行时修改的数据不写回项目目录，如需持久化应使用 AppData 等系统目录

总结

配置文件的"两个 json"问题，表面上是路径冲突，实质上是两套机制的时序差异：MSBuild 在编译期执行，NewLife 在运行期执行。两者路径一致时，文件只有一份，读写自然对齐；路径不一致时，才会出现两个独立文件。

理解这一点，就不需要担心"运行时被覆盖"——因为覆盖的从来不是 MSBuild，而是你自己。