.NET MAUI の Windows アプリを Visual Studio の「Publish → Create App Packages…」で MSIX（/MSIXUPLOAD）化していると、プロジェクトを別フォルダーへ移動したのに、なぜか古いパス配下へ出力され続けることがあります。この記事では、出力先の変更ポイントと、どこに設定が残るのかを実務目線で整理します。
症状：プロジェクトを移動したのに「AppPackages」だけ古い場所へ出る
典型的には次のような状況です。
- 以前：C:\Projects_2024 配下で開発していて、MSIX が AppPackages フォルダーに出力されていた
- 現在：プロジェクト一式を C:\Projects_2025 に移動した
- しかし、Visual Studio の [プロジェクト] → [発行] → [Create App Packages…] で作ると、出力先だけ C:\Projects_2024 のまま
この現象は「ビルド自体は新しい場所で動いているのに、MSIX 出力パスだけが古い設定で固定されている」ケースで起きやすいです。
最初に整理：あなたが変えたい“出力先”はどれ？
MSIX 関連は「出力先」という言葉が複数の場所を指しがちです。まずここを揃えると、迷いが減ります。
| 名称（よくある呼び方） | 実体 | どんなファイルが入る？ | どこで指定する？ |
|---|---|---|---|
| パッケージ出力先 / Output location / Output folder | MSIX（.msix / .msixbundle / .msixupload など）が生成されるフォルダー | MSIX 本体、依存関係、インストーラー用ファイル一式（構成による） | Create App Packages の「Select and Configure Packages」画面、または MSBuild プロパティ |
| AppPackages フォルダー（既定） | 既定の生成先（プロジェクト種別で場所が変わる） | 生成されたパッケージ一式 | 既定は自動。必要なら AppxPackageDir 等で上書き |
| Installer location（インストーラー配置先） | 自動更新を有効にしたときの“配布先” | ユーザーがアクセスする場所にコピーされる想定の一式 | ウィザードの「Configure update settings」 |
特に .NET MAUI の場合、完了画面に「Output location」と「Installer location」が並んで表示され、両者が別物だと分かります。
Create App Packages で出力先を変える方法（まずここが最短）
Visual Studio の Create App Packages ウィザードには、途中で Output location（出力場所） を指定できる画面が用意されています。ここが古いパス（C:\Projects_2024…）のままだと、プロジェクトを移動しても“出力だけ”が古い場所に固定されます。
手順（Visual Studio の UI で変更）
- 対象の .NET MAUI プロジェクトを右クリック
- [発行] → [Create App Packages…] を選択
- ウィザードを進めて、「Select and Configure Packages」（構成選択）画面まで進む
- Output location のテキストボックスで、古いパスを新しいパスへ変更
- 例：C:\Projects_2025\YourApp\AppPackages\
- 右端の「…」ボタンから参照して選ぶのが確実
- そのまま Create（作成）して完了
この画面は MSIX の自動更新を使う／使わないに関わらず、パッケージ生成の“出力場所”を指定するための入口として押さえておく価値があります。
出力先が指定できる画面が出ない場合の対処（.NET MAUI の発行フロー差異）
Visual Studio のバージョンやプロジェクト構成によっては、Create App Packages の流れが「MSIX Publish Profile」中心になり、途中で Output location を直接編集できないように見える場合があります。その場合でも、できることはあります。
パターンA：完了画面に Output location が出る（= 生成先はある）
.NET MAUI のドキュメント例では、完了ダイアログに Output location（生成先）と Installer location（コピー先）が表示されます。
- Output location：多くのケースで
bin\Release\...AppPackages\配下（構成や RID による） - Installer location：自動更新向けに、共有フォルダー/URL 等に“置きたい場所”を指定
もし「出力場所を変えたい」目的が “成果物を指定フォルダーへ集約したい” であれば、次のどちらかが現実的です。
- ウィザード完了時に Copy and Close を選び、Installer location を新しいフォルダーへ設定する（配布・提出用の置き場として使う）
- 後述する AppxPackageDir で “生成そのもの” の出力先を上書きする
パターンB：「bin\Release\…\AppPackages」に出るのが仕様に見える
.NET MAUI を CLI で publish した場合、生成された MSIX は既定で bin\Release\...AppPackages\<appname>\ にコピーされる、と明記されています。
つまり「既定の生成先」は存在し、そこから“どこへ置くか”は別レイヤーで調整する、という考え方になります。チーム運用ではこの方がトラブルが少ないことも多いです（後述）。
なぜ“移動しても古いパス”になるのか：絶対パスがどこかに残っている
プロジェクトフォルダーをエクスプローラーで移動しても、Visual Studio や MSBuild は過去に指定した絶対パスを自動で書き換えてくれません。特に MSIX は、出力先を明示的に指定できるため、どこかに C:\Projects_2024\... が残ると、そのまま使われ続けます。
このとき重要なのは、「Visual Studio が覚えている」というより、MSBuild のプロパティとして保存されている（またはユーザー設定として保存されている）点です。代表例が AppxPackageDir です。
設定はどこに保存される？実務で探すべきファイル一覧
結論としては、“このファイルに必ず入る”と決め打ちするより、古いパス文字列で検索して当てるのが最短です。とはいえ、当たりを付けやすい場所はあります。
| 保存先候補 | 典型パス | 残りやすい設定 | ポイント |
|---|---|---|---|
| MSIX の発行プロファイル | Properties\PublishProfiles\*.pubxml | PublishDir / RuntimeIdentifier / MSIX 関連のプロパティ | Visual Studio の発行 UI で作ると増えやすい |
| 発行プロファイルのユーザー設定 | Properties\PublishProfiles\*.pubxml.user | 証明書・パスワードなど“個人環境”寄りの値 | Git 管理しないのが一般的 |
| プロジェクトファイル本体 | *.csproj | AppxPackageDir など MSIX 出力に直結するプロパティ | 絶対パスを書いた場合、移動に弱い |
| ユーザー別プロジェクト設定 | *.csproj.user / *.wapproj.user | 開発者ごとの出力先・証明書など | 個人 PC の状態を持ち込みやすい |
| Visual Studio のキャッシュ | .vs フォルダー配下 | ウィザードや IDE の状態 | 原因切り分けで消すと直ることがある |
なお、MSIX パッケージの出力先は MSBuild の引数としてもよく使われ、AppxPackageDir が出力フォルダー指定の定番です（CI の例でも AppxPackageDir が使われます）。
最短で原因を特定する方法：旧パス文字列で全文検索する
「どのファイルに残っているか分からない」場合は、フォルダー丸ごと検索が一番確実です。以下はどれか一つでOKです。
エクスプローラーで検索（手軽）
- ソリューションのルートで Projects_2024 を検索
- ヒットしたファイルの中に、出力先や証明書パスが混じっていないか確認
コマンドで検索（速くて正確）
Windows 標準の findstr でも十分です。
cd C:\Projects_2025\YourSolution
findstr /s /i "Projects_2024" *.*PowerShell でやるならこちら。
Get-ChildItem -Recurse -File |
Select-String -Pattern "Projects_2024" -List「古いパスがどこに残っているか」が特定できたら、その行が本丸です（多くは AppxPackageDir、PublishDir、証明書ファイルパスなど）。
出力先を固定している“犯人”になりやすい：AppxPackageDir を見直す
MSIX の生成先を決めるプロパティとして、実務で最も遭遇するのが AppxPackageDir です。実際にプロジェクト設定の一部として <AppxPackageDir>...</AppxPackageDir> が置かれている例もあります。
AppxPackageDir が“絶対パス”だと移動で壊れる
例えば以下のように書いている（あるいはウィザードが書いた）場合、プロジェクトを移動しても出力先は変わりません。
<PropertyGroup>
<AppxPackageDir>C:\Projects_2024\MyApp\AppPackages\</AppxPackageDir>
</PropertyGroup>移動に強くするなら“相対パス”で指定する
次のように相対指定にすると、ルートを移動しても追従します。
<PropertyGroup>
<AppxPackageDir>AppPackages\</AppxPackageDir>
</PropertyGroup>さらに「Windows の Release のときだけ」など、範囲を絞っておくと安全です（MAUI はマルチターゲットなので、条件で分けると事故が減ります）。
<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows' and '$(Configuration)' == 'Release'">
<AppxPackageDir>AppPackages\</AppxPackageDir>
</PropertyGroup>この“相対パス化”は、今回のような「移動したのに古いフォルダーに出る」問題の再発防止として非常に効きます。
Visual Studio のウィザードで直せない／チームで揃えたい場合：コマンドラインで出力先を明示する
CI/CD やローカルのバッチ化を考えるなら、AppxPackageDir を引数で渡すのが一番分かりやすいです。Microsoft Learn の WinUI 3 向け CI 例でも AppxPackageDir と GenerateAppxPackageOnBuild が併記されています。
.NET MAUI の Windows パッケージは、CLI では次のように publish します（例）。
dotnet publish -f net8.0-windows10.0.19041.0 -c Release -p:RuntimeIdentifierOverride=win10-x64ここに出力先指定を足すイメージです（環境に合わせてパスは調整してください）。
dotnet publish -f net8.0-windows10.0.19041.0 -c Release `
-p:RuntimeIdentifierOverride=win10-x64 `
-p:AppxPackageDir="C:\Projects_2025\_Artifacts\AppPackages\"これで「成果物は必ずこのフォルダーへ」という形に揃えやすくなります。特に、提出用（Partner Center へアップロードするファイルを集める等）で便利です。
うまく切り替わらないときのチェックリスト
出力先変更が反映されない場合、以下を上から順に確認すると切り分けが早いです。
| チェック項目 | よくある原因 | 対処 |
|---|---|---|
| Output location と Installer location を混同していないか | 「コピー先」を変えただけで「生成先」が変わっていない | 完了画面で Output location を確認。必要なら AppxPackageDir を設定 |
| ソリューション内に Projects_2024 の文字列が残っていないか | pubxml / csproj / user ファイルに絶対パスが残存 | 全文検索して書き換える（またはプロファイル作り直し） |
| AppxPackageDir が絶対パスになっていないか | ウィザード設定の名残で固定 | 相対パス化、もしくは新パスへ更新 |
| .vs フォルダーや *.user のキャッシュが影響していないか | IDE 側の状態が古い | Visual Studio を閉じて .vs を退避/削除し、再オープンして再生成 |
| 出力先フォルダーの権限・存在 | ネットワーク共有、書き込み権限不足、パスが長すぎる等 | ローカルの短いパスで一度試し、問題が出力先依存か確認 |
再発防止の考え方：提出用フォルダーとビルド出力を分離する
個人的におすすめの運用は次の2段構えです。
- ビルド生成物（既定）：
bin\Release\...AppPackages\（仕組みに任せる） - 提出・共有用（チームで揃える）：
C:\Projects_2025\_Artifacts\のような別フォルダーへコピー（ウィザードの Installer location / Copy and Close、または CI で収集）
こうしておくと、開発者の PC でプロジェクトをどこに置いても「提出物はここ」だけを共通化しやすく、移動トラブルも減ります。
まとめ
- Create App Packages の途中にある Output location（出力場所） を新しいパスへ変更するのが最短ルート
- ウィザードで出力先が見えない/変えられない場合でも、AppxPackageDir の指定（プロジェクト/プロファイル/引数）で制御できる
- プロジェクト移動後も古いパスに出るときは、どこかに 絶対パスが残っているので、ソリューション全体を旧パスで検索して修正する
- 再発防止には、相対パスで AppPackages を指定するか、提出用フォルダーを別に設けて集約する運用が効果的
コメント