使用MSIX部署时如何解决.NET可编辑配置文件的写入受限问题

优先推荐系统级专属配置目录方案，更适配Windows后台服务的运行场景，完全规避多账号权限链路的维护成本，符合Windows系统的应用配置管理规范。
不推荐将配置写入服务账号AppData的方案：Windows服务通常运行在LocalSystem或独立服务账号下，对应的AppData路径属于系统隐藏目录，普通管理员账号的GUI程序没有默认访问权限，打通权限的链路复杂度远高于直接使用系统级配置目录。

① MSIX允许写入的合法专属配置目录 #

推荐路径：C:\ProgramData\<你的服务唯一标识名>\Config

• MSIX沙箱的拦截规则仅针对安装包自身的只读安装目录（即C:\Program Files\WindowsApps\<包名>路径下的文件），不会对ProgramData这类系统标准目录做写入重定向
• 只要MSIX包申请了runFullTrust能力（传统桌面应用迁移时的默认必备能力），对该路径的读写操作和传统桌面应用行为完全一致，不会触发沙箱拦截
• 目录权限建议：创建时配置ACL为Administrators组拥有完全控制权限，Users组拥有只读权限，与ProgramData下其他系统应用的配置权限规则对齐

② .NET应用的配置路径重定向实现 #

无法仅靠AppDomain.CurrentDomain.SetData完成全量重定向，需要配合自定义逻辑改造：

• 方法局限性：AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", "新路径")仅能重定向.NET运行时加载的标准*.exe.config文件位置，无法影响自定义代码中硬编码的、通过AppContext.BaseDirectory拼接查找的其他编译生成*.exe.xml配置文件的路径
• 正确改造步骤：
  • 在应用启动流程最前端（Windows服务的OnStart方法、GUI程序的Main方法第一行），定义统一的配置根路径常量，启动时先检查该路径是否存在，不存在则自动创建并配置上述ACL权限
  • 对.NET标准配置文件，调用AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", Path.Combine(配置根路径, "你的服务exe名.config"))完成路径重定向
  • 对所有自定义加载的编译生成配置文件，将原有代码中拼接应用安装目录查找配置的逻辑，全部替换为拼接统一配置根路径
• 默认配置初始化逻辑：应用首次启动时，检查配置目录下的文件是否存在，若不存在则将MSIX包内打包的只读默认配置文件，从安装目录复制到自建的ProgramData配置目录下，完成首次初始化。

如果选择将配置写入服务账号AppData路径，会面临两个无法绕开的运维问题：

• 服务通常以LocalSystem身份运行，对应的AppData路径为C:\Windows\System32\config\systemprofile\AppData\Local，默认连管理员账号都没有访问权限，GUI辅助程序要修改配置，要么需要手动修改该路径的ACL给管理员开放写入权限，要么需要通过命名管道、服务控制接口等IPC通道通知服务自身修改配置，维护成本极高，完全不需要为服务账号开启桌面访问权限
• 配置与服务账号的profile绑定，更换机器、更换服务运行账号都会导致配置丢失，不符合系统级服务的配置管理预期。

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