久しぶりに開いた WinForms（.NET）プロジェクトで、Visual Studio のフォームデザイナーだけが突然開けなくなることがあります。エラー一覧に MSB4018「CreateAppHost」失敗や「user-mapped section open」が出る場合、デザイナー起動時のビルド処理が、生成される exe（apphost）を更新できずに止まっているのが典型です。この記事では原因の見立て方と、現場で効きやすい対処を「最短で直す順」に整理します。
症状の特徴（このパターンなら本記事の対象）
代表的には、デザイナーを開いた瞬間にビルドが走り、途中で落ちてデザイン画面が出ません。エラー一覧や出力に次のような文言が混ざります。
- MSB4018: The “CreateAppHost” task failed unexpectedly
- System.IO.IOException: The requested operation cannot be performed on a file with a user-mapped section open
- スタックトレースに Microsoft.DotNet.DesignTools / DesignTools 系が含まれる
| 見える現象 | 裏で起きがちなこと | 直し方の方向性 |
|---|---|---|
| フォームデザイナーだけ開けない | デザイナー用のビルド（設計時ビルド）が失敗 | ビルド成果物の掃除、SDK整合性、ロック解消 |
| MSB4018 / CreateAppHost が出る | apphost（生成 exe）を書き換えできない | ロック元プロセスを止める／apphost生成を回避 |
| user-mapped section open と出る | ファイルがメモリマップされ、Windowsが上書きを拒否 | 同期ドライブ回避、AV除外、bin/obj削除が効きやすい |
なぜ WinForms デザイナーで「CreateAppHost」が動くのか
WinForms デザイナーは見た目だけを描画しているように見えますが、実際には「設計時に必要な情報を得るため」にプロジェクトの参照解決や一部ビルドを行います。そこで MSBuild が走り、ターゲットフレームワークや出力物（obj/bin、時には apphost 生成）に手が入ります。
このタイミングで、生成される exe（apphost）が別プロセスに“掴まれた状態”だったり、ファイル操作しづらい場所（同期ドライブ／仮想ドライブ／ネットワーク）にあったりすると、CreateAppHost が更新に失敗し、結果としてデザイナーが開けません。
原因の本質：apphost（exe）が更新できない状況になっている
「user-mapped section open」は、対象ファイルがメモリマップされている（＝プロセスがセクションとして開いている）状態を示唆します。簡単に言うと、Windows が “安全のために上書き・削除を拒否する握られ方” をしている状態です。起こり方は1つではなく、よくある要因は次の通りです。
| よくある要因 | 具体例 | 見分けポイント |
|---|---|---|
| アプリやデバッグプロセスが残っている | 前回起動した exe が裏で生存、常駐ツールが読み込んだまま | タスクマネージャに exe がいる／再起動で直る |
| 同期ドライブ・仮想ドライブ上にプロジェクトがある | Google Drive / OneDrive / Dropbox 等の同期フォルダ | 場所を C:\dev へ移すと即改善しやすい |
| ウイルス対策・EDR が bin/obj をスキャンして掴む | リアルタイム保護が exe を検査中 | 特定端末だけ起きる／除外設定で改善 |
| .NET SDK / TFM の不一致 | net6.0-windows なのにSDK不足、global.jsonで固定 | ビルドも不安定／dotnet –list-sdks で判明 |
| bin/obj の不整合（古い成果物が悪さ） | 久々に開いた、VS更新後、参照が変わった | bin/obj削除で直ることが多い |
最短で直すための手順（上から順に実施）
ポイントは「ロックを外す」「成果物を作り直す」「SDKを揃える」「場所問題を解消する」です。迷ったら次の順で進めると復旧率が高いです。
プロジェクトを“普通のローカルディスク”へ移す（最優先で効きやすい）
プロジェクトが同期ドライブや仮想ドライブ上にある場合、apphost や中間生成物が独特の握られ方をし、CreateAppHost 失敗に繋がることがあります。まずはC:\dev や D:\src などのローカル固定ドライブに移動して試してください。
- 例：C:\dev\YourSolution にコピー（または移動）
- Git 管理なら、ローカルにクローンし直すのが最も安全
- 移動後に Visual Studio でソリューションを開き直す
場所問題は、後述の掃除やSDK確認よりも先に刺さることが多いです（特に「久々に開いた」「保存先が同期フォルダ」ケース）。
実行中プロセスを止めて“掴み”を外す
apphost（exe）が掴まれているなら、まず掴んでいるプロセスを止めるのが最短です。
- Visual Studio を閉じる（可能なら一度完全終了）
- タスクマネージャで、対象の exe（あなたのアプリ名）や dotnet / MSBuild 関連が残っていないか確認し終了
- 再度 Visual Studio を起動してデザイナーを開く
コマンドで一気に止めたい場合の例です（アプリ名は適宜変更）。
taskkill /im YourApp.exe /f
taskkill /im devenv.exe /f
taskkill /im msbuild.exe /f
taskkill /im dotnet.exe /fそれでも掴み元が分からない場合は、Windows の定番ツール（Process Explorer の検索機能など）で「どのプロセスが exe を開いているか」を特定して止める、という進め方が確実です。
bin / obj を削除して、設計時ビルドの土台を作り直す
古い成果物や中間ファイルの不整合でデザイナーが落ちるケースは多いです。まずは定番の掃除から入ります。
- Visual Studio で Clean → Rebuild
- それでもだめなら、ソリューション配下の bin / obj フォルダを手動削除
NuGet キャッシュも絡みそうなら、次も併用します。
dotnet nuget locals all --clear掃除後は、ソリューションを開き直してからデザイナーを試すと成功率が上がります（設計時ビルドが再構築されるため）。
.NET SDK / TargetFramework の整合性を取る（古いプロジェクトほど重要）
久々に開くプロジェクトで起きやすい落とし穴が、ターゲット（TFM）と端末の SDK 不一致です。まずは .csproj のターゲットを確認します。
- .csproj の <TargetFramework> を確認（例：net6.0-windows、net7.0-windows など）
- WinForms なら通常 <UseWindowsForms>true</UseWindowsForms> が入っているかも確認
次に、端末に入っている SDK を確認します。
dotnet --list-sdks対応は2択です。
- プロジェクト側の TFM を、インストール済み SDK に合わせて変更（急ぎの復旧向け）
- プロジェクトが想定する .NET SDK をインストール（長期的に安全）
さらに Visual Studio のインストーラーで「.NET デスクトップ開発」ワークロードが入っているかも確認しておくと、設計時ツール周りの不整合を避けられます。SDK やワークロードを変更した後は、Visual Studio を再起動してから試してください。
apphost 生成を無効化して CreateAppHost を迂回する（要件次第の回避策）
根本原因（ロックや場所問題）を解決できない事情がある場合、apphost 生成を避けて回避できることがあります。要件上問題がなければ、csproj に次のいずれかを追加して試します（環境により有効なプロパティ名が異なることがあります）。
<PropertyGroup>
<UseAppHost>false</UseAppHost>
</PropertyGroup>上で変化がない場合に、次も試行対象になります。
<PropertyGroup>
<EnableAppHost>false</EnableAppHost>
</PropertyGroup>apphost を無効化すると、実行形式や配布形態の前提が変わる場合があります。チーム開発や配布をしているプロジェクトでは、恒久対応にする前に影響範囲（起動方法、発行設定、CI）を確認してください。まずは「デザイナーを開くための一時回避」として使うのが安全です。
中間出力先をローカル固定にしてロックを避ける（場所問題の強化策）
プロジェクト全体を移せない事情（会社PCのポリシーなど）があるなら、せめて obj/bin だけでもローカルに逃がすと改善することがあります。中間出力先を明示して“掴まれにくい場所”へ誘導します。
<PropertyGroup>
<BaseIntermediateOutputPath>C:\_build\YourSolution\obj\</BaseIntermediateOutputPath>
<IntermediateOutputPath>C:\_build\YourSolution\obj\$(MSBuildProjectName)\</IntermediateOutputPath>
</PropertyGroup>この方法は「同期フォルダ上で作業せざるを得ない」「ネットワークドライブが絡む」ケースで効くことがあります。パスは環境に合わせて調整してください。
“現場で効きやすい”追加チェックリスト
上の手順で直らない場合に、ハマりどころを潰すチェックです。上から順に軽いものを並べています。
| チェック項目 | 確認方法 | 改善アクション |
|---|---|---|
| bin/obj の削除が本当にできているか | 削除時に「使用中」エラーが出ていないか | 掴み元プロセスを止める／PC再起動後に削除 |
| 同期ツールが稼働しているか | トレイ常駐、同期中アイコン | 一時停止、除外設定、ローカルへ移動 |
| ウイルス対策/EDR が強い端末か | 他端末では再現しないか | 開発フォルダを除外（bin/obj/Packages） |
| global.json で SDK が固定されていないか | ソリューション直下に global.json | SDK を入れる／固定バージョンを更新 |
| 権限・属性の問題 | フォルダが読み取り専用、アクセス制限 | 書き込み可能な場所へ移動／権限見直し |
| Visual Studio の不整合 | 更新直後からおかしい、拡張機能が怪しい | 修復（Repair）、拡張機能無効化で切り分け |
トラブルシュートの“おすすめ順”まとめ（迷った時用）
時間を溶かしやすいのが「掃除を繰り返す」だけのループです。次の順にやると、原因に近いところから効率よく当たれます。
- プロジェクトをローカルディスクへ移動（同期ドライブ/ネットワークを避ける）
- 実行中プロセスを止める（ロック解除）
- bin/obj を削除＋必要なら NuGet キャッシュクリア
- TargetFramework と SDK を揃える（dotnet –list-sdks / global.json を確認）
- apphost 無効化や中間出力先の変更で回避
再発防止のコツ（プロジェクト運用の小ワザ）
- 開発用の作業フォルダは最初からローカル固定にする（同期は別のバックアップ手段で担保）
- CI/CD やチーム開発があるなら、SDK を揃える仕組み（global.json やドキュメント）を用意する
- セキュリティソフトが強い環境では、bin/obj とパッケージ領域の除外を検討する（社内ルールの範囲で）
- 「デザイナーが開かない＝コードが壊れた」と決めつけず、まずロックと場所を疑う
よくある質問
ビルドは通るのに、デザイナーだけ落ちるのはなぜ？
通常ビルドとデザイナーの設計時ビルドでは、使うプロセスやタイミングが異なります。設計時は DesignTools 周りが絡み、出力物の更新がシビアに失敗することがあります。特に apphost が掴まれていると、ビルドが部分的に通って見えてもデザイナーだけ落ちることが起こり得ます。
bin/obj を消しても戻るのはなぜ？
根が「掴み」や「場所（同期/仮想/ネットワーク）」にあると、消して作り直す過程でまた同じ掴まれ方をして再発します。その場合は、移動（ローカル化）や除外設定など、掴まれにくい条件に変えるのが近道です。
apphost 無効化はやっていい？
一時回避としては有効なことがありますが、プロジェクト要件（配布・発行・起動方法）によっては影響が出ます。まずは「デザイナーを開くための切り分け」として適用し、原因がロック/場所/SDK だと特定できたら恒久対応は元に戻す、という使い方が安全です。
コメント