Windows向けの.NET MAUIアプリを「EXE（アンパッケージ）」として配布するとき、発行前にReleaseでクリーン／ビルドすべきか迷いがちです。この記事では、dotnet publishの内部動作とDebugビルドとの関係、クリーンが効く場面、トラブルを減らす運用例を整理します。
結論：publish前の「Releaseでクリーン＆ビルド」は必須ではない
まず結論から言うと、事前にReleaseでクリーン／ビルドしておく必要はありません。通常はdotnet publishが発行の過程で必要なビルドを実行し、指定した構成（または既定の構成）で成果物を作ってくれます。
特に.NET 8以降（net8.0以上をターゲットにするプロジェクト）では、dotnet publishの既定構成がReleaseになっています。つまり、コマンドに-c Releaseを書かなかったとしても、net8.0以上をpublishしているならReleaseで発行されるのが基本です。
あなたのケース（net9.0-windows10.0.19041.0）は「net8.0以上」に該当するため、publishがReleaseで走る前提で考えてOKです。ですので、開発中にDebugビルドしていたとしても、そのままpublishして問題になりにくい、というのが基本方針になります。
| やりたいこと | 結論 | 理由（要点） |
|---|---|---|
| Debugで作業 → 最後にpublishして配布 | 問題なし | publishの過程でRelease側をビルド／発行するため |
| publish前に毎回「クリーン＆再ビルド」必須？ | 必須ではない | publish自体がビルドを含み、通常は差分ビルドで整合が取れる |
| たまに変な挙動が出るので保険をかけたい | クリーン推奨 | 古い生成物（obj/bin）やキャッシュ起因の事故を減らせる |
dotnet publishは何をしているのか（「ビルドしなくていい？」の正体）
「publish前にビルドが必要か？」が不安になる最大の理由は、publishが“コピー作業だけ”だと思ってしまうことです。実際にはpublishはビルドも含む一連の処理です。
一般的な流れは次の通りです。
| フェーズ | 内容 | よく使う制御 | 注意点 |
|---|---|---|---|
| Restore | NuGetパッケージ復元 | --no-restore | CIなどで復元タイミングを分けたい場合に有効 |
| Build | コンパイル／生成物作成 | --no-build | –no-buildを使うと“今あるビルド成果物”を前提にするので事故りやすい |
| Publish | 配布用フォルダーに必要物を集約 | -o / -p:PublishDir=など | 出力先の取り違え・古いフォルダー上書きに注意 |
つまり「事前にReleaseでビルドしておかないとpublishできない」というより、publishコマンドの中で必要なビルドをさせれば良いという整理が正確です。
Debugでビルドしてからpublishしても大丈夫？（混ざらない理由）
結論としては、Debugでビルドしていても、Release publishの邪魔になることは通常ありません。
理由はシンプルで、.NETのビルド成果物は基本的に構成（Debug/Release）ごとに出力先が分かれるためです。たとえば既定の出力構造なら、Debugはbin/Debug/...、Releaseはbin/Release/...に分かれます。publishも基本的にRelease側のフォルダーへ成果物が集約されます。
現場でよくある誤解：「Debugで一回ビルドしたから、publishがDebugのDLLを拾ってしまうのでは？」
→ 通常は拾いません。publishがRelease構成で走るなら、Releaseの生成物を基準にpublish出力が作られます。
ただし、次のような条件が重なると「混ざったように見える」ことがあります。
- publish出力フォルダーを固定（同じディレクトリに上書き）しており、古いファイルが残っている
- アイコン・画像などのリソース差し替え直後で、古い生成物が残っている
- Windows向けの設定（パッケージ種別やRIDなど）を切り替えた直後
この“混ざったように見える”問題は、実体としては「Debug/Releaseの混在」よりもpublish出力フォルダーの残骸やobj/binの古い生成物が原因で起きるケースが多いです。だからこそ、次の章の「クリーンが効くケース」を押さえておくと事故が減ります。
あなたのpublishコマンドを分解して理解する（何が変わると不安定になる？）
提示されているコマンドは、Windows向けMAUIをアンパッケージ（EXE配布）で出すための典型形に近いです。
dotnet publish -f net9.0-windows10.0.19041.0 -c Release \
-p:WindowsPackageType=None \
-p:WindowsAppSDKSelfContained=true \
/p:PackageCertificateThumbprint="c01ba45666762f3615cf6813aeb4dc4b1919541d" \
-p:RuntimeIdentifierOverride=win10-x64それぞれの意味をざっくり整理すると次の通りです。
| 指定 | 役割 | ここが変わると何が起きるか |
|---|---|---|
-f net9.0-windows10.0.19041.0 | Windows向けTFM（ターゲット）指定 | TFMを変えると依存関係・生成物が変わる。切り替え直後はクリーンが安全 |
-c Release | Release構成でpublish | .NET 8以降は省略可能（既定がRelease） |
-p:WindowsPackageType=None | アンパッケージ（MSIXではなくフォルダー配布） | MSIX前提の設定が残っているとエラーになることがある（後述） |
-p:WindowsAppSDKSelfContained=true | Windows App SDKの自己完結配布（依存を隣に展開） | WinAppSDK依存の出力が変わる。構成変更後はクリーン推奨 |
PackageCertificateThumbprint=... | 主にMSIX署名向けの証明書指定 | MSIXを作るなら重要。アンパッケージ配布だけなら基本は不要 |
-p:RuntimeIdentifierOverride=win10-x64 | Windows App SDKの既知問題回避のためのRID指定（MAUI文脈でよく登場） | RID周りは変更が入りやすい。環境でNETSDK1083が出たら見直し（後述） |
クリーン／再ビルドをしたほうがよい典型パターン
「必須ではない」とはいえ、クリーンが効く場面は確実にあります。特にMAUI（XAMLやリソース、プラットフォーム別生成物が絡む）では、稀に古い生成物が残って挙動がズレることがあります。
次のようなときは、publish前にクリーン（あるいはbin/obj削除）を挟むと安定しやすいです。
| 症状 | よくある原因 | おすすめ対処 |
|---|---|---|
| アイコン／スプラッシュ／画像が古いまま | obj側の生成物やリソースキャッシュが残る | dotnet clean → 再publish（ダメならbin/obj削除） |
| publish後のEXEが起動はするが挙動が古い | publish出力フォルダーに古いファイルが残っている | publish出力先を毎回空にする／別フォルダーへ出す |
| WindowsPackageTypeを切り替えたらエラー | MSIX向け設定とアンパッケージ設定の食い違い | プロパティ見直し＋クリーン（設定変更直後は特に） |
| アーキテクチャ変更（x86/x64）後に謎のエラー | RIDや参照が以前の構成を引きずる | クリーン＋RID再確認（win-x64等） |
| CIだけ失敗／ローカルだけ成功 | ワークスペースの汚れ、復元タイミングの違い | クリーンチェックアウト、restoreとpublishの分離 |
ポイントは、クリーンの目的が「Releaseにするため」ではなく、古い生成物を捨てて“今の設定とソースだけで作り直す”ためだということです。dotnet cleanはビルドで作られた出力（objとbin）を掃除するコマンドとして明確に定義されています。
Visual Studioの「クリーン」「リビルド」とCLIの対応関係
Visual Studioを使っている場合、「クリーン」「リビルド（再ビルド）」が混同されやすいので、CLIと対応付けて理解しておくと判断が楽になります。
| Visual Studioの操作 | 意味 | CLIで近いもの |
|---|---|---|
| ビルド（Build） | 前回から変更があるものを中心にコンパイル | dotnet build |
| クリーン（Clean） | 生成物（中間/出力）を削除 | dotnet clean |
| リビルド（Rebuild） | クリーンしてから全体をビルド | dotnet clean → dotnet build |
MicrosoftのVisual Studioドキュメントでも、Buildは変更があったものをビルドし、Rebuildはクリーンしてから全体をビルドする、と整理されています。
つまり「publish前にRebuildが必須か？」ではなく、“いまのpublishが古い生成物の影響を受けそうか？”で判断するのが現実的です。
おすすめ運用：シンプルに回す／安全寄りに回す
シンプル運用（まずはこれで十分）
「毎回コマンド1発で完結させたい」場合は、publishに任せてOKです。net8.0以上ならRelease既定なので、-c Releaseは省略可能です（付けたままでも問題ありません）。
dotnet publish -f net9.0-windows10.0.19041.0 \
-p:WindowsPackageType=None \
-p:WindowsAppSDKSelfContained=true \
-p:RuntimeIdentifierOverride=win10-x64アンパッケージ配布だけが目的なら、PackageCertificateThumbprintは基本的にMSIX署名向けの要素なので、まずは外してシンプルにするほうがトラブルを切り分けやすいです。
安全寄り運用（“キャッシュ起因”を避けたい）
「たまに変な生成物が出る」「アイコンやリソースが更新されないことがある」「配布前は確実に同じ状態で作りたい」なら、publish前にクリーンを挟むのが堅実です。
dotnet clean -c Release -f net9.0-windows10.0.19041.0
dotnet publish -c Release -f net9.0-windows10.0.19041.0 \
-p:WindowsPackageType=None \
-p:WindowsAppSDKSelfContained=true \
-p:RuntimeIdentifierOverride=win10-x64dotnet cleanは中間フォルダー（obj）と出力フォルダー（bin）を掃除します。これにより「古い生成物が残っているせいで起きる」タイプの問題を減らせます。
CI運用（再現性を重視する）
CIでは、ローカルのように「手元のbin/objがどれだけ汚れているか」が分からないので、基本方針としては次のどちらかに寄せると安定します。
- 毎回クリーンチェックアウト（ワークスペースを新品にする）
- 明示的にclean → publishにする
また、復元（restore）を明示し、publishでは--no-restoreを使うと、ネットワークの揺らぎや復元タイミングの差を抑えやすくなります。
dotnet restore
dotnet publish --no-restore -c Release -f net9.0-windows10.0.19041.0 \
-p:WindowsPackageType=None \
-p:WindowsAppSDKSelfContained=true \
-p:RuntimeIdentifierOverride=win10-x64アンパッケージ配布で見落としやすい「自己完結」の話
EXE配布（フォルダー配布）でよく混乱するのが、「自己完結（self-contained）」という言葉が2種類ある点です。
| 何の自己完結？ | 設定 | 意味 |
|---|---|---|
| Windows App SDKの自己完結 | WindowsAppSDKSelfContained=true | Windows App SDKの依存をexeの隣に展開して配布できる |
| .NETランタイムの自己完結 | --self-contained true（またはSelfContained=true） | .NETランタイムも同梱して「対象PCに.NETランタイムを入れなくても動く」 |
Windows App SDK側のドキュメントでも、WindowsAppSDKSelfContainedをtrueにしても、.NETアプリは別途「.NETとしての自己完結publish」も必要になり得る、と注記されています。
もし「配布先PCに.NETランタイムを入れたくない」なら、次のように両方を意識してコマンドを組むのが考え方としては安全です（プロジェクト条件によりサイズや互換性が変わるため、必ずテストしてください）。
dotnet publish -c Release -f net9.0-windows10.0.19041.0 \
-p:WindowsPackageType=None \
-p:WindowsAppSDKSelfContained=true \
--self-contained true \
-p:RuntimeIdentifierOverride=win10-x64よくある落とし穴：RID（win10-x64）と.NET 8以降の変更
質問の主題はクリーン／ビルドですが、Windows向けpublishの相談でセットになりやすいので、RIDについても最低限触れておきます。
.NET 8以降では、プロジェクトがnet8.0以上をターゲットにする場合、既定で使うRIDグラフが小さくなり、win10-x64のようなバージョン付きRIDが認識されないことがあります（NETSDK1083）。その場合はwin-x64のようなポータブルRIDを使うか、必要に応じてUseRidGraph=trueで旧挙動に戻す、というのが公式の推奨整理です。
一方、.NET MAUIのWindows発行手順では、Windows App SDKの既知問題回避としてRuntimeIdentifierOverrideを使う例が提示されています。環境やMAUI/WinAppSDKのバージョンによっては、このあたりの組み合わせが原因でpublishが不安定になることがあります。
もしあなたの環境で「win10-x64が認識されない」系のエラーに遭遇した場合は、次の順で切り分けると早いです。
- まずRIDを
win-x64へ寄せられないか検討（CLI引数やcsprojの設定を含めて） - それで別のWindows App SDK由来の不具合が出るなら、MAUIドキュメントの回避策（RuntimeIdentifierOverrideなど）に寄せる
- 最終手段として
UseRidGraph=trueで旧グラフに戻す（将来更新されない点には注意）
publish出力を配布前にチェックする（Debug混入を疑うより効果が高い）
「クリーンしたほうがいいか？」よりも、実務では配布前の確認のほうが効果が大きいです。特にEXE配布は“フォルダーごと配る”ことが多いので、チェックポイントを固定しておくと事故が減ります。
- 出力先がReleaseになっているか（
bin/Release/...配下、または指定したPublishDir） - publishフォルダーを一度空にしてから再実行しても同じ成果物になるか（残骸問題の排除）
- 別PC（クリーンな検証環境）で起動するか（依存不足の検出）
- 表示名・バージョン・アイコンなど“ユーザーが見る部分”が更新されているか
- 自己完結を狙う場合は、配布先PCに.NETランタイム未インストールでも動くか（SelfContained設定の妥当性）
よくある質問（クリーン問題に直結するもの）
「-c Release」を省略しても本当にRelease？
net8.0以上をターゲットにしていて、.NET 8 SDK以降でpublishしているなら、既定がReleaseです。省略してもReleaseでpublishされます。とはいえ、チーム運用やスクリプトの可読性の観点で、あえて明示しておくのは悪くありません。
publish前にDebugビルドしていたら、Release publishが古いままになる？
通常はなりません。publishがRelease構成で走れば、その構成として必要なビルドが行われます。もし「古いまま」に見えるなら、Debug/Releaseの問題というより、出力フォルダーの残骸やリソース生成物のキャッシュを疑い、クリーン（またはbin/obj削除）を試すのが近道です。
ソリューション（.sln）に対してdotnet publishしてもいい？
MAUIのドキュメントでは、ソリューション全体に対してpublishすると、ソリューション内の各プロジェクトを個別にpublishしようとして問題が出る可能性があるため、MAUIアプリのcsprojにスコープすることが推奨されています。
まとめ：迷ったら「publishに任せる」＋「困ったらclean」
- 事前のReleaseクリーン＆ビルドは必須ではない（publishがビルドを含む）
- Debugで作業していても、最後にRelease publishすれば通常問題ない
- ただし、リソース差し替えや設定変更直後など、古い生成物が疑わしいときはdotnet clean（またはbin/obj削除）が効く
- アンパッケージ配布では、WindowsAppSDKSelfContainedと.NET自己完結（SelfContained）は別物。配布要件に応じて意識する
コメント