既存の .NET Framework 4.8 製 WinForms アプリを MSIX/APPX でパッケージし、Microsoft Store から配布しようとすると、必ずぶつかるのが「ファイルアクセスはどこまで許されるのか」「AppData に書いたファイルがどこに行ったのか」という問題です。本記事では、Store 審査の考え方と MSIX のファイル仮想化（リダイレクト）の仕組みを整理しつつ、実際にどのパスを使って保存すべきか、.NET Framework 4.8 WinForms 向けの具体的な実装までまとめます。
.NET Framework 4.8 WinForms と MSIX／APPX の基本整理
まず前提として、.NET Framework 4.8 の WinForms アプリを MSIX/APPX でパッケージしたものは、いわゆる「パッケージ化されたデスクトップアプリ（packaged desktop app / full-trust app）」として動作します。これは UWP のようなサンドボックスではなく、従来の Win32 アプリに近い権限で動作しつつ、一部のフォルダやレジストリだけ OS によって仮想化されるモデルです。
UWP アプリとの一番大きな違い
- UWP アプリ … 厳格なアプリコンテナー内で動作し、
PicturesやDocumentsなどのフォルダにアクセスするには、明示的な Capability やピッカー API が必須。 - MSIX 化された WinForms … 実行時は通常のデスクトップアプリとしてユーザー権限で動作し、
%USERPROFILE%配下などには基本的に従来どおりアクセス可能。ただしAppDataやレジストリは「パッケージ専用の場所」に書き込みが仮想化されます。
つまり「MSIX でパッケージした瞬間に UWP と同じ制約になる」というイメージは誤りで、「フル トラストのまま、AppData などの一部だけが OS によって安全な場所へ追い出される」という理解が近いです。
インストール先と書き込み可否
- インストール先は
C:\Program Files\WindowsApps\<パッケージ名>配下で、ここは読み取り専用です。コードやリソースをここに配置することはできますが、実行時に書き込むことはできません。 - ユーザーデータやログは、
%LocalAppData%\Packages\<パッケージ名>\配下のパッケージ専用領域に保存されます。 AppData直下への書き込みは OS によってこのパッケージ領域にリダイレクトされます（詳細は後述）。
「どこにでも書ける」＝即アウトではない
Microsoft Q&A での公式回答でも、MSIX 化された WinForms アプリは多くのフル トラスト挙動を保持しており、それだけを理由に Store 審査で即却下されるわけではない、というスタンスが示されています。重要なのは「システムディレクトリを勝手に書き換えない」「ユーザーデータを適切な場所に置く」といったポリシー順守です。
Microsoft Store 審査から見たファイルアクセスの考え方
Store 審査で特に見られやすいポイントを、WinForms + MSIX 観点で整理すると次のようになります。
| 観点 | NG になりやすい例 | 安全な設計例 |
|---|---|---|
| インストール先への書き込み | C:\Program Files\WindowsApps 配下にログや設定ファイルを書こうとする | ApplicationData.Current.LocalFolder など、ユーザーデータ領域に保存 |
| システム領域の変更 | C:\Windows や HKLM に設定を書き込む | ユーザープロファイル配下や HKCU に限定し、レジストリ仮想化に任せる |
| ユーザーファイルへのアクセス | ユーザーの許可なくドキュメントやピクチャをスキャン | 必要なときだけファイル／フォルダピッカーを使い、ユーザー操作をトリガーにアクセス |
| パスの扱い | ハードコードされた絶対パス（例：C:\Users\Admin\...） | Environment.GetFolderPath や WinRT API から取得したパスを使用 |
ポイントは、「フルアクセスできるからといって何をしてもよいわけではない」という感覚を持つことです。MSIX による仮想化と Store ポリシーの両方を意識し、ユーザーデータはパッケージ専用領域、共有したいデータはピッカー経由という大枠を守るとトラブルが少なくなります。
AppData\Roaming に書いたファイルが見えない理由
質問の本題である「C:\Users\Admin\AppData\Roaming\Company\Product に書いたはずなのにファイルが見えない」という現象は、MSIX による AppData の仮想化（リダイレクト） が原因です。
AppData の仮想化の仕組み（ざっくり）
- Windows 10 バージョン 1903 以降では、パッケージ化されたデスクトップアプリが
AppData\LocalやAppData\Roamingなどに新しいファイル／フォルダを書き込むと、実際にはアプリ専用のプライベート領域に保存されます。 - OS は実行時にそのプライベート領域と本来の AppData をマージして見せるため、アプリから見ると従来どおり
AppData\Roaming\Company\Productに見えますが、エクスプローラーで Roaming を直接開いても見つかりません。 - MSIX の場合、このプライベート領域は
%LocalAppData%\Packages\<パッケージ名>以下に作られるのが標準です。
Microsoft Q&A の回答では、WinForms アプリが AppData\Roaming に書いたデータは、実際にはおおむね次の場所に保存されると説明されています。
C:\Users\<UserName>\AppData\Local\Packages\<YourAppPackageId>\LocalCache\...
実際には、この LocalCache 配下にさらに Local や Roaming などいくつかのサブフォルダがぶら下がっており、その中に書き込み内容がマッピングされます。構造は OS バージョンやツールによって多少異なりますが、「Packages フォルダの LocalCache に吸い込まれる」という理解で十分です。
従来パスと MSIX 実体の対応イメージ
| 従来の WinForms から見えるパス | MSIX パッケージでの実体（概念図） | 補足 |
|---|---|---|
C:\Users\<User>\AppData\Roaming\Company\Product | %LocalAppData%\Packages\<PFN>\LocalCache\Roaming\Company\Product\ | Roaming に書いたつもりでも Packages 配下の LocalCache にリダイレクト |
C:\Users\<User>\AppData\Local\Temp | %LocalAppData%\Packages\<PFN>\LocalCache\Local\Temp\ | 一時ファイルもパッケージ専用の Temp に配置されることが多い |
C:\Program Files\MyApp\config.json | %LocalAppData%\Packages\<PFN>\LocalCache\Local\Microsoft\WritablePackageRoot\config.json | インストールフォルダ直下への書き込みは別の影（WritablePackageRoot）にリダイレクトされるケースもあるが、そもそもここに書き込む設計は避けるべき。 |
このように、AppData やインストールフォルダへの書き込みは OS によって自動的に Packages 配下へ転送されるため、「Roaming を確認してもファイルが見えない」という状態が発生します。開発者は仮想化先の正確なパスを追いかけるのではなく、API から得られる保存先を使うのが基本です。
WinForms から MSIX の保存場所を正しく取得する方法
MSIX 配布を前提とした .NET Framework 4.8 WinForms アプリでは、保存先をハードコードせず、Windows Runtime の ApplicationData API や Environment.GetFolderPath から取得するように書き換えておくと安全です。
Windows.Storage.ApplicationData を使う
WinForms からでも、Windows 10 SDK の参照を追加すれば Windows.Storage.ApplicationData を呼び出せます。Stack Overflow でも、MSIX 実行時の「実際の非仮想化パス」を取る方法として紹介されています。
// 1. プロジェクトに「Windows」(Windows.winmd) への参照を追加しておく
// 2. using を追加
using Windows.Storage;
string GetLocalDataRoot()
{
// MSIX（UWP コンテナー）内で動いている場合は、
// ApplicationData.Current.LocalFolder がパッケージ専用領域を指す
return ApplicationData.Current.LocalFolder.Path;
}
string GetRoamingDataRoot()
{
return ApplicationData.Current.RoamingFolder.Path;
}
string GetTempDataRoot()
{
return ApplicationData.Current.TemporaryFolder.Path;
}
上記のパスは、MSIX 実行時には %LocalAppData%\Packages\<PFN>\LocalState あるいは LocalCache 配下の実体にマッピングされます。一方、従来の MSI インストールなど「非 MSIX 実行時」には通常の AppData フォルダを指すため、同じコードでどちらにも対応できます。
MSIX かどうかで保存先を切り替える例
「MSIX 版と従来版を同じソースでビルドしている」「既存のデータ移行をしたい」といった場合は、DesktopBridge.Helpers などを使って「MSIX 上で動いているかどうか」を判定し、保存先を切り替えるのが現実的です。
using System;
using System.IO;
using DesktopBridge;
using Windows.Storage;
public static class AppPaths
{
private static readonly Helpers _helpers = new Helpers();
public static string GetAppDataFolder()
{
string root;
if (_helpers.IsRunningAsUwp())
{
// MSIX / Store 実行時: パッケージ専用の LocalFolder を使う
root = ApplicationData.Current.LocalFolder.Path;
}
else
{
// 従来の Win32 実行時: 通常の LocalApplicationData
root = Environment.GetFolderPath(
Environment.SpecialFolder.LocalApplicationData);
}
// 会社名・製品名でサブフォルダを切る
return Path.Combine(root, "Company", "Product");
}
}
既存コードで Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) を直接使っている箇所は、上記のようなラッパーを経由するように差し替えておくと、MSIX 化しても保存場所の実体差異を意識せずに済みます。
PFN（Package Family Name）から実体のフォルダを確認する
デバッグ時に「実際にどこに保存されているのか」を確認したい場合は、パッケージ ID（PFN: Package Family Name）を調べてから、エクスプローラーで該当フォルダを開くのが手早いです。
PowerShell で PFN を取得
# アプリ名の一部で検索して PFN を取得
(Get-AppxPackage -Name "*YourAppName*").PackageFamilyName
得られた PFN を使って、次のようなフォルダを開きます。
C:\Users\<UserName>\AppData\Local\Packages\<PFN>\LocalCache\
ここに Roaming・Local 等がぶら下がっていれば、MSIX 仮想化された AppData の中身が確認できるはずです。なお、本番コードで PFN をハードコードするのは避け、あくまでも「調査・デバッグ用途」として使うのがよいでしょう。
Store 審査で嫌われるファイルアクセスとその代替パターン
実際に Store 申請する際にトラブルになりがちなパターンと、その置き換え先をもう少し具体的に整理しておきます。
| NG パターン | 問題点 | 推奨パターン |
|---|---|---|
| インストールフォルダに設定ファイル・ログを書き込む | パッケージは読み取り専用であり、OS が WritablePackageRoot にリダイレクトするケースもあるが、アップデートやアンインストール時の挙動が読みづらい。 | ApplicationData.Current.LocalFolder または LocalCache を利用し、「アプリデータは常に AppData 側」に寄せる。 |
C:\Windows や C:\ProgramData に直接書き込む | Store ポリシー上リスクが高く、企業環境ではグループポリシー等でブロックされることも多い。 | ユーザープロファイル配下に限定し、必要なら管理者向けの別ツール（MSI 等）に分離する。 |
| 起動直後にユーザーの全ドキュメントをスキャン | プライバシー上の懸念があり、審査で指摘される可能性が高い。 | ユーザー操作（「フォルダを開く」ボタンなど）をトリガーに、ファイル／フォルダピッカー経由でアクセスする。 |
C:\Users\Admin\... のような固定パス | 他ユーザー環境やローカライズされた OS で動作しない。MSIX 仮想化との相性も悪い。 | Environment.GetFolderPath や ApplicationData を通して取得したパスを使う。 |
「MSIX だから Store に載せられる」ではなく、「Store に載せても問題ない動作か」をあらためて見直し、NG パターンを潰しておくのが安全です。
ユーザーデータのライフサイクル：アップデート & アンインストール時
MSIX で重要なのが、ユーザーデータの ライフサイクル です。パッケージのバージョンアップやアンインストール時に、どのデータが残り、どのデータが消えるかを理解しておく必要があります。
- AppData の仮想化領域（
%LocalAppData%\Packages\<PFN>\...）にあるデータは、通常アップデートでは保持され、アプリがアンインストールされたときにまとめて削除されます。 - 一方、
unvirtualizedResourcesなどの制限付き Capability を使って AppData 仮想化を無効化した場合、AppData の実体に書き込まれるため、アンインストール後も残ります。ゲームのセーブデータなど、あえて残したい場合にのみ使うべき機能です。 - FSLogix 等のプロファイル仮想化製品を併用している場合、
%LocalAppData%\Packages配下の扱いが独自に制御されるケースもあるため、企業環境向けに配布する場合はインフラ担当者と事前に確認しておくと安全です。
最終的なユーザー体験としては、次のような設計を意識するとよいでしょう。
- アプリの設定・キャッシュ・履歴などは、基本的に
LocalFolder/LocalCacheに保存し、アンインストール時に消えてもよい前提で設計する。 - 長期的に保持したいデータ（プロジェクトファイルやエクスポート結果など）は、
Documents等のユーザーフォルダに保存し、ユーザー自身がバックアップできる形にする。 - 必要であれば「設定のエクスポート／インポート」機能を用意し、アンインストール前にユーザーが設定を退避できるようにする。
既存 WinForms アプリを MSIX 対応させるためのチェックリスト
ここまでの内容を踏まえ、既存の .NET Framework 4.8 WinForms アプリを MSIX 化する際の実務的なチェックリストをまとめておきます。
1. パス取得ロジックの棚卸し
- ソリューション全体を検索し、
"C:\"や"AppData"のようなハードコードされたパスを洗い出す。 Environment.GetFolderPathを使っていない箇所、ユーザー名を直接埋め込んでいる箇所を中心に修正する。- 保存先は、できるだけラッパーメソッド（前述の
AppPaths.GetAppDataFolder()など）を経由するよう統一する。
2. 書き込み先フォルダの分類
- 設定・キャッシュ系 …
ApplicationData.Current.LocalFolderまたはLocalCache。 - ローミングさせたい少量の設定 …
ApplicationData.Current.RoamingFolder（MS アカウントでのサインインを前提に利用）。 - ユーザーが直接触るファイル …
KnownFolders.DocumentsLibrary等（WinRT API またはファイルピッカー経由）を使用。
3. データ移行ロジックの実装
- MSIX 化した初回起動時に、「従来版が使っていた
AppData\Roaming\Company\Product」などのディレクトリが存在するかをチェック。 - 存在する場合は、新しいパッケージ専用フォルダ（
ApplicationData.Current.LocalFolder等）にデータをコピーし、移行完了後に旧フォルダをクリーンアップする。 - 移行処理は一度きり実行されるよう、バージョン番号やフラグファイルで制御しておく。
4. ログ出力とトラブルシューティング
- ログファイルもユーザーデータと同様にパッケージ専用フォルダへ出力し、ユーザーが希望すれば「ログファイルをエクスポート」できる機能を用意する。
- 開発・サポート用に、「現在のデータフォルダをエクスプローラーで開く」メニューを用意しておくと、MSIX 環境でもパスが迷子になりにくい。
おまけ：高度なシナリオ（AppData 仮想化の制御）
ほとんどの WinForms アプリでは既定の AppData 仮想化で十分ですが、どうしても他プロセスから同じ AppData のファイルを見せたい場合など、より細かな制御が必要になることもあります。
- MSIX の
unvirtualizedResources制限付き Capability とFileSystemWriteVirtualizationの設定を使うと、特定フォルダに対して AppData 仮想化を無効化できます。 - ただし、この機能は「仮想化そのものをオフにする」ため、アンインストール時にクリーンに消えない・他プロセスから丸見えになるなど、MSIX のメリットを一部手放すことになります。
ゲームのセーブデータのように「アプリ削除後も残したい」「他プロセスと共有したい」といった明確な要件がない限りは、既定の仮想化に任せておくのが無難です。
まとめ：.NET Framework 4.8 WinForms を安全に Store 配布するために
最後に、本記事のポイントをもう一度整理します。
- .NET Framework 4.8 の WinForms アプリを MSIX 化すると、実行モデルはフル トラストのままながら、
AppDataやレジストリはパッケージ専用領域に仮想化されます。 AppData\RoamingやAppData\Localに書いたつもりのファイルは、実際には%LocalAppData%\Packages\<PFN>\LocalCache\...などに保存されます。- 保存先をハードコードするのではなく、
Windows.Storage.ApplicationData.Current.LocalFolder/RoamingFolder/TemporaryFolderなどの API から取得し、MSIX でも従来版でも同じコードで動くようにしておくと安全です。 - Store 審査を意識するなら、インストールフォルダやシステム領域への書き込みを避け、ユーザーデータはパッケージ専用領域か、ユーザーが明示的に選んだフォルダに限定するのが基本方針です。
- ユーザーデータのライフサイクル（アップデートで保持されるのか、アンインストールで消えるのか）を設計し、必要に応じてエクスポート機能や移行処理を実装しておくと、トラブル時にもユーザー体験を損ねません。
これらを押さえておけば、「AppData に書いたはずなのに見えない」「Store 審査でファイルアクセスが原因でリジェクトされた」といった典型的なハマりどころをかなり回避できます。既存の WinForms 資産をそのまま MSIX 化するのではなく、ファイルアクセスと保存場所をこの機会に見直しておくことが、Microsoft Store で長く運用できるアプリへの近道です。
コメント