Windows WPF Kiosk Application – Platform and Local Storage Clarification

Hello @lakshmi ,

Thanks for laying out the questions so clearly. I've gone through the current Microsoft documentation and I've put together my answers below.

1 & 2. Using WPF as a kiosk, and Assigned Access / editions

I can confirm that a WPF app is a classic (Win32) desktop app, and you can run it as a kiosk. The catch is that the method depends on the Windows version:

• On Windows 11 (21H2 and later), I can point you to the single-app kiosk route: you configure it through Assigned Access using a KioskModeApp profile with the v4:ClassicAppPath attribute.
• On Windows 10, I found that the single-app KioskModeApp profile only accepts a UWP app (AppUserModelId), and ClassicAppPath isn't part of the Windows 10 schema. So for WPF on Windows 10, the documented paths are either the restricted (multi-app) experience (which allows desktop apps via DesktopAppPath and auto-launch via rs5:AutoLaunch, available since version 1809) or Shell Launcher.

On editions, here's what the docs state: Assigned Access is supported on Pro, Enterprise, Education, and IoT Enterprise, while Shell Launcher requires Enterprise, Education, or IoT Enterprise (Pro isn't listed). You'll also need UAC enabled and console sign-in, and you can apply the configuration through Intune/MDM, a provisioning package, PowerShell, or the Settings app.

Since you're targeting both Windows 10 and 11, I'd suggest you consider a single consistent method that works across both, such as Shell Launcher or the multi-app experience, because the single-app ClassicAppPath route only covers Windows 11.

References:

• Configuration file
• XSD
• Shell Launcher

3. Storing configuration, and keeping it through updates

For a .NET/WPF app, I'd store the configuration using Environment.GetFolderPath, either CommonApplicationData (C:\ProgramData\..., shared across the device) or LocalApplicationData (per-user). Since your settings are device-specific, I think ProgramData is a reasonable fit, because it's machine-scoped and sits outside the install folder, though I'd treat that as a suggestion rather than a hard rule.

On persistence, I can confirm these locations survive both application restarts and system reboots. For updates, it comes down to how you package the app:

• If you deploy it unpackaged (MSI or file-copy), your config under ProgramData/AppData lives outside the payload, so updates won't touch it. I'd just avoid writing anything into Program Files.
• If you use MSIX, the docs state that writes are kept during an upgrade and are only removed on a full uninstall, and the install directory itself is read-only. If you need the config to persist even more broadly, you can look at Flexible Virtualization (Windows 11), which lets you declare specific AppData folders as unvirtualized.

To make sure device-specific config isn't overwritten on update, one approach I'd suggest is keeping it separate from the app payload and having the app create or migrate the file only when it's missing.

References:

• Environment.SpecialFolder
• Packaged desktop apps
• Flexible virtualization

If you can let me know the exact editions and versions you plan to deploy, along with your preferred management method, I'd be happy to put together a specific configuration example for you. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.