MENU

Visual StudioのPublishでASPNETCOMPILER「パスが長すぎる」エラーを解決する方法（AspnetCompileMergeIntermediateOutputPath）

Visual Studio

ASP.NET Webサイトの発行（Publish）で ASPNETCOMPILER(0,0): Error ASPRUNTIME: The specified path, file name, or both are too long が出て止まる場合、原因の多くは「中間フォルダーのフルパスが長すぎる」ことです。本記事では、発行プロファイル側の設定で一時出力先を短いパスへ逃がし、確実に発行を通す方法と、再発防止の考え方をまとめます。

目次

発行時に出る「パスが長すぎる」エラーとは

Visual Studio の［発行］（Publish）や MSBuild で Web サイトを発行するとき、次のようなエラーで処理が停止することがあります。

ASPNETCOMPILER(0,0): Error ASPRUNTIME: The specified path, file name, or both are too long.
The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

ポイントは、エラーが「あなたが指定した発行先フォルダー」ではなく、aspnet_compiler が内部で作る一時フォルダー（中間生成物）に対して発生しやすいことです。発行先を短くしているつもりでも、ビルド・プリコンパイル・マージ工程で深い階層が作られ、結果として上限を超えます。

原因：Windows の古典的なパス長制限と、中間生成物の深い階層

多くの Windows 環境では、古くからの制限として次のような上限が意識されます（ツール側が古い API 前提だと影響が残ります）。

制限の種類目安よく引っ掛かる場面
フルパス長（ファイル含む）260 文字深い階層 + 長いファイル名（.aspx/.cshtml/.config など）
ディレクトリ名（パス）248 文字一時フォルダーに「プロジェクト名/構成/一意 ID…」が付く工程

Publish の内部では、ビルド後に aspnet_compiler によるプリコンパイルや、アセンブリのマージ（設定による）が走ります。このとき、プロジェクトの配置場所・発行プロファイル名・一時ディレクトリ名・生成されるサブフォルダー名が積み重なり、あなたが意図していない場所でパスが肥大化します。

特に次のような状況だと再現しやすくなります。

  • プロジェクトのルートが深い（例：C:\Users\ユーザー名\Documents\仕事\案件\…）
  • ソリューション名・プロジェクト名・フォルダー名が長い
  • フロントエンドの成果物（node_modules など）を誤って発行対象に含めている
  • 「発行時にプリコンパイル」を有効にしている（WebForms/ASPX が多い場合に多発）

最優先の解決策：AspnetCompileMergeIntermediateOutputPath を短いパスへ変更する

結論として一番効くのは、発行プロファイル（Publish 設定ファイル）側で、aspnet_compiler の中間出力先を短いパスへ逃がす方法です。これにより、コンパイル・マージ工程で作られる一時フォルダー階層が深くなりすぎるのを防げます。

手順の全体像

  1. 短いフォルダーを作成する（例：C:\shortPath\）
  2. 発行プロファイルの XML を開く（.pubxml / .publishproj など）
  3. AspnetCompileMergeIntermediateOutputPath を追加する
  4. 再度 Publish して、エラーが消えることを確認する

ステップ1：短いフォルダーを用意する

まずはローカルディスクの浅い場所にフォルダーを用意します。CI でも使う場合は、ビルドエージェントが書き込みできる場所にしてください。

  • 例：C:\shortPath\
  • 例：D:\tmp\aspnet\（別ドライブでも OK）

ステップ2：発行プロファイル（Publish 設定ファイル）を開く

Visual Studio の発行プロファイルは、プロジェクト配下に XML として保存されています。典型例は次の場所です。

種類よくある保存場所拡張子
発行プロファイルProperties\PublishProfiles\.pubxml
（環境によって）発行用 MSBuild プロジェクトソリューション/プロジェクト直下.publishproj など

発行画面からプロファイルを選び、設定ファイルをエディタで開く（または「フォルダーを開く」系の操作）と早いです。重要なのは、発行先の指定ではなく「発行プロファイル側」に追記する点です。

ステップ3：<PropertyGroup> に AspnetCompileMergeIntermediateOutputPath を追加する

次の例のように、発行プロファイル（.pubxml や .publishproj）の <PropertyGroup> 内へ追記します。パスはできるだけ短くし、必要なら末尾に \ を付けておくと意図が明確です。

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <!-- 省略：既存の発行設定 -->

    <!-- ★追加：aspnet_compiler の中間出力先を短いパスへ -->
    <AspnetCompileMergeIntermediateOutputPath>C:\shortPath\</AspnetCompileMergeIntermediateOutputPath>
  </PropertyGroup>
</Project>

ここで指定するのは「中間生成物（プリコンパイルやマージの作業場所）」です。最終的に IIS サーバーへ配置される場所（Web Deploy の接続先やリモート IIS のパス）とは別物なので、混同しないようにしてください。

ステップ4：Publish を実行して確認する

設定を保存したら、いつも通り発行します。成功したら、C:\shortPath\ 配下に一時的なフォルダーやファイルが作られます（発行が完了すれば残っていても問題ありませんが、不要なら削除して構いません）。

もしまだ失敗する場合は、「短いパスへ逃がす」以外の要因（発行対象に深いフォルダーが混ざっている等）が残っている可能性があります。後述のチェックリストを確認してください。

なぜ中間出力先の変更で直るのか（仕組みをイメージする）

Publish の処理は、ざっくり言うと次のような工程の組み合わせです（プロジェクト種類や設定により前後します）。

工程主な役割パスが長くなりやすい理由
ビルドコードのコンパイル生成物が bin や一時フォルダーに集約される
プリコンパイル（aspnet_compiler）ASPX/ASCX などを事前コンパイルページ階層を反映したサブフォルダーが作られやすい
マージ（設定時）アセンブリ結合中間生成物 + 追加の作業ディレクトリが増える
最終出力（発行先へコピー/転送）IIS / フォルダー / FTP などへ配置発行先パス自体が長いと、ここでも問題化する

このうち、エラーの主戦場は「プリコンパイル〜マージ」で、しかも出力先が OS の一時領域やプロジェクト配下の深い場所になりがちです。そこで AspnetCompileMergeIntermediateOutputPath で中間出力のルートを短くすると、深い階層が発生しても「スタート地点」が短い分だけ上限に収まりやすくなります。

再発防止として有効なこと（“短いパス”以外の根本対策）

中間出力先を短くするのは即効性が高い一方、プロジェクト側の構造が原因で再発するケースもあります。チーム開発や CI/CD まで含めて安定させるなら、次の観点も合わせて整備すると効果的です。

プロジェクトの配置場所を浅くする

最も手軽で効果が高いのが、プロジェクトのルートを浅い場所に移すことです。

  • 推奨例：C:\src\MySolution\
  • 避けたい例：C:\Users\ユーザー名\Documents\Company\Project\Customer\2026\…

フォルダー名・ファイル名を短くする（特に深い階層）

“長い名前”は単体では問題にならなくても、階層が深いほど合計が膨らみます。例えば、次のような見直しが効きます。

見直し対象ありがちな例短縮の例
フォルダー名ControllersForAdministrationAndReportingAdmin / Rpt
画像/CSS/JS の出力先wwwroot\assets\images\icons\…wwwroot\a\i\…（運用と相談）
自動生成物ビルド成果物をリポジトリに含める生成物は発行時に作る、Git では除外する

発行対象に「深いフォルダー」を混ぜない

Web サイトの発行対象に、次のような“巨大で深いフォルダー”が入っていると、プリコンパイル以前にコピー工程で詰まることがあります。

  • node_modules（フロントエンド依存関係）
  • packages（古い NuGet 管理）
  • .git や .vs
  • バックアップ用のフォルダー（backup_202601 など）

「発行に必要なものだけを出す」ように、発行プロファイルやプロジェクトの除外設定を見直すと、速度面でもメリットがあります。

OS 側の “長いパス” 設定は効く？（期待値を正しく持つ）

Windows 10/11 や Windows Server の一部環境では、長いパスを許可する設定（グループポリシー/レジストリ）があります。ただし、ツール側が長いパスを扱える実装になっていない場合、設定しても効果が出ないことがあります。

そのため、Publish で確実に直したい場合は、まず本記事の AspnetCompileMergeIntermediateOutputPath で中間出力を短くする対策を優先し、OS 側の設定は「環境全体として長いパスを扱いたい事情があるとき」に検討するのが現実的です。

「C:\shortPath\ には出るけど IIS に反映されない」問題の整理

コメントなどでよくある混乱が、「中間出力を短いパスにしたら、そこへ出力されるだけで IIS に発行されない」というものです。これは仕様として自然で、次のように役割が違います。

設定/要素役割代表例間違えやすいポイント
AspnetCompileMergeIntermediateOutputPathプリコンパイル/マージの作業場所（中間生成物）C:\shortPath\ここは最終発行先ではない
発行方法どこへどうやって配置するかWeb Deploy / FTP / IIS / File SystemFile System だとサーバーへ自動転送されない
発行先 URL/パス最終成果物の配置先IIS のサイト名、Web Deploy の接続先、出力フォルダー中間出力と同じにすると混乱しやすい

もし「IIS サーバーへ直接反映したい」のに反映されない場合、疑うべきポイントは次の 2 つが定石です。

  • 発行方法が File System（フォルダー出力）になっていないか：この場合、ローカル（または共有）フォルダーへ出すだけで終わります。IIS へ反映したいなら Web Deploy などへ切り替えが必要です。
  • 発行先を決める別設定が意図せず変わっていないか：中間出力先の変更と、発行先（サーバー接続情報やパス）は別項目です。設定ファイルを編集する際に、既存の発行先設定を上書きしていないか確認します。

トラブルシューティング：まだ失敗するときのチェックリスト

設定を入れてもまだ失敗する場合は、次の順で潰していくと原因が切り分けやすくなります。

チェック項目確認方法対処の方向性
中間出力先が本当に反映されているか発行ログで aspnet_compiler のパスを確認プロファイルの編集先を間違えていないか、複数プロファイルを使っていないか確認
中間出力先が書き込み可能かフォルダー権限、ウイルス対策ソフトの隔離別ドライブ/別パスへ変更、権限付与
発行対象に深いフォルダーが混ざっていないか発行対象ファイル一覧/プロジェクトの除外設定node_modules 等を除外、成果物だけをコピーする
プロジェクト自体の場所が深すぎないかソリューションのフルパスを数えるC:\src\ 直下へ移動、短い名前へ変更
発行先パスが長すぎないかFile System 出力先や共有パスの長さ発行先も浅い場所へ変更（中間出力とは別に調整）

原因調査：どのファイル/フォルダーが「長さの犯人」かを特定する

根本原因の把握や再発防止のために、「実際にどれくらいの長さのパスが存在するのか」を把握しておくと、チーム全体の運用が楽になります。特に Web サイトは静的ファイルや自動生成物が増えやすいため、定期的な棚卸しが有効です。

発行ログで aspnet_compiler の実行内容を確認する

まずは Publish のログ（出力ウィンドウ）で、aspnet_compiler がどのディレクトリを入力/出力として使っているかを確認します。中間出力先が意図通り短いパスに変わっていれば、少なくとも「中間フォルダーが深すぎる」問題は改善している可能性が高いです。

  • プロファイルを複数持っている場合、編集したプロファイルで発行しているかも要確認です。
  • CI の場合は、ビルドログに aspnet_compiler の引数が出るようログレベルを上げると切り分けが進みます。

PowerShell で “最長パス TOP” を一覧化する

ローカルのプロジェクト配下で、パスが長い順に上位を確認する例です。除外したいディレクトリ（node_modules など）がある場合は、フィルターを追加してください。

# プロジェクト直下で実行（例）
# cd C:\src\MySolution\MyWebSite

Get-ChildItem -Recurse -Force -File |
  Select-Object FullName, @{Name="Length"; Expression={$_.FullName.Length}} |
  Sort-Object Length -Descending |
  Select-Object -First 30

この一覧の中に「発行に不要なもの」が混ざっている場合は、発行対象の除外やディレクトリ整理の優先度が高いサインです。逆に、必要なファイルでパスが長い場合は、配置場所を浅くする/ディレクトリ名を短縮するといった設計寄りの対策が効きます。

コマンドライン（MSBuild）で指定したい場合

Visual Studio の UI 編集が難しい環境（CI など）では、ビルド/発行コマンドのプロパティとして渡す方法もあります。発行プロファイルを使う場合は、次のように指定します（例）。

msbuild MyWebSite.publishproj /t:Publish /p:PublishProfile=MyProfile /p:AspnetCompileMergeIntermediateOutputPath=C:\shortPath\

パスにスペースが含まれる場合は、引用符で囲んでください。

msbuild MyWebSite.publishproj /t:Publish /p:PublishProfile=MyProfile /p:AspnetCompileMergeIntermediateOutputPath="C:\short path\"

プロファイルに埋め込む方法と比べて、環境ごとにパスを変えたいときに便利です（エージェントの作業ディレクトリ構成に合わせやすい）。

よくある質問

中間出力先はネットワーク共有（\\server\share\）でもいい？

技術的には可能な場合もありますが、ネットワーク経由だと権限・パス解決・速度・一時的な切断の影響を受けやすく、発行の安定性が落ちます。まずはローカルディスクの短いパスを推奨します。

C:\shortPath\ は毎回空にした方がいい？

必須ではありません。発行のたびに新しいサブフォルダーが作られることが多く、古いものが残っていても通常は問題になりません。ただしディスク容量が気になる場合は、定期的に削除して運用しても構いません。

そもそも “プリコンパイル” をやめれば直る？

設定次第では回避できることもありますが、プリコンパイルを外すと発行後の初回アクセス時にコンパイルが走ったり、動作検証の前提が変わったりします。まずは中間出力先の短縮で安定させ、要件に応じてプリコンパイルの有無を検討するのが安全です。

Windows 側で長いパスを有効にしているのに直らないのはなぜ？

OS の設定が有効でも、aspnet_compiler や関連タスクが古い API 前提で動いている場合、内部で上限に引っ掛かることがあります。ツールの実装依存が残るため、まずは「短いパスに逃がす」アプローチのほうが再現性が高いです。

まとめ

  • Publish 時の ASPNETCOMPILER「パスが長すぎる」エラーは、発行先ではなく中間生成物のパス肥大化で起きることが多い
  • 発行プロファイルに AspnetCompileMergeIntermediateOutputPath を追加し、中間出力先を短いパスへ変更するのが最優先の対策
  • 再発防止として、プロジェクトのルートを浅くする・名前を短くする・発行対象を絞るなども合わせて行う
  • 「IIS に反映されない」ときは、中間出力と最終発行先（Web Deploy/FTP/File System 等）の設定を切り分けて確認する
Visual Studio
Visual Studio ASP.NET Publish ASPNETCOMPILER パス長制限

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次