WPF打包MSIX是否有等效于UWP的Package.Current.InstalledLocation的路径获取方法

原有路径逻辑失效的原因 #

• 你在ClickOnce部署场景下能用Directory.GetCurrentDirectory()定位到appsettings.json，本质是ClickOnce启动器会主动将当前进程的工作目录切换到应用安装文件夹。这个方法的取值逻辑是当前进程的工作目录，和应用自身的安装位置没有强绑定关系。
• 传统未打包应用如果被系统服务、系统快捷方式从其他目录拉起，很容易出现工作目录指向C:\WINDOWS\system32的问题。MSIX打包后的应用运行在独立的隔离上下文里，系统不会主动将工作目录切换到安装路径，自然会出现找不到文件、路径指向系统目录的报错。
• 你已经通过解包确认MSIX包内包含appsettings.json，说明打包配置本身没有问题，只是路径获取逻辑不匹配MSIX的运行规则。

等效的安装路径获取方法 #

WPF应用打包为MSIX后，完全可以使用和UWP通用的API获取安装位置，不存在平台限制：

• 不需要引入额外的第三方依赖，直接在项目中引用Windows.ApplicationModel命名空间，使用通用的Package类API即可。
• 调用Package.Current.InstalledLocation.Path就能拿到MSIX包在系统中的实际安装根路径，直接拼接上appsettings.json的相对路径，就能准确读取到包内的配置文件。

兼容双部署场景的实现写法 #

为了让同一套代码同时适配未打包/ClickOnce、MSIX打包两种部署方式，不需要做条件编译，直接通过运行时判断实现逻辑兼容，示例代码如下：

// 定位appsettings.json的完整路径
string configFullPath;
try
{
    // 检测当前是否运行在MSIX打包环境
    if (Package.Current != null)
    {
        // MSIX场景：从应用安装根目录取配置文件
        configFullPath = Path.Combine(Package.Current.InstalledLocation.Path, "appsettings.json");
    }
    else
    {
        // 未打包/ClickOnce场景：从应用程序基目录取配置文件
        configFullPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "appsettings.json");
    }
}
catch
{
    // 非打包环境下访问Package类会触发类型异常，直接回退到稳定的基目录路径
    configFullPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "appsettings.json");
}

实操注意事项 #

• 相比Directory.GetCurrentDirectory()，AppDomain.CurrentDomain.BaseDirectory的取值不受进程启动时的工作目录影响，不管是ClickOnce部署还是独立EXE运行，都能稳定拿到可执行文件所在的目录，更适合作为配置文件路径的兜底逻辑。
• 不要通过反射获取当前进程可执行文件路径的方式反推MSIX安装目录，MSIX的运行上下文带文件系统重定向规则，这种方式拿到的路径稳定性差，容易受虚拟化逻辑影响，直接使用系统提供的Package类API是最可靠的方案。
• 你之前配置的BuildAction=Content、Copy Always完全符合MSIX打包要求，不需要调整文件生成操作，只要路径拼接逻辑正确就能正常读取到appsettings.json。

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