Visual Studio 2022でApp_Code配下だけ参照DLLが見えない原因と解決策（usingが解決しない／1_App_Code問題）

Visual Studio 2022（.NET Framework 4.8）のASP.NETプロジェクトで、参照DLLが「プロジェクト直下の.csでは使えるのに、App_Code配下だけusingが解決しない」という現象に遭遇することがあります。さらにビルド時に存在しない「1_App_Code」を見に行くようなエラーが出ると、原因の特定が一気に難しくなります。ここでは症状の整理から、最短で直す手順、残したい場合のチェック項目、再発防止までを具体的にまとめます。

起きている症状を正しく把握する（まずは“切り分け”）

このトラブルは、エラー文面だけを見ると「参照設定が壊れた」「DLLが見つからない」といった一般的な話に見えます。しかしポイントは、同じプロジェクト内なのに“場所（フォルダー）によって参照解決の結果が変わる”ことです。

よくある見え方

• 参照DLLを追加した直後、プロジェクト直下の.csでは using Foo.Bar; が解決できる
• 同じ参照DLLを使うコードを、子フォルダー（例：App_Code）配下の.csに書くと using が赤線になり、型が見えない
• ビルド／リビルドのエラー一覧で、実在しないフォルダー名（例：1_App_Code）を参照しているような表示が出る
• 代表的なエラーは以下のようなものが混ざる

CS0246: 型または名前空間名 'Foo' が見つかりませんでした (using ディレクティブまたはアセンブリ参照が指定されていますか?)
CS0234: 名前空間 'Bar' に型または名前空間名 'Baz' が存在しません

同じ参照設定なのに解決結果が変わる場合、単純な「参照追加ミス」ではなく、そのフォルダー配下のコードが“別の仕組み”で扱われている可能性が高いです。ここで重要になるのが App_Code というフォルダー名です。

結論：App_Codeは“特別扱い”されるため、MVC構成ではトラブルの起点になりやすい

App_CodeはASP.NETの世界で「特別な意味を持つフォルダー名」として知られています。プロジェクト種別・構成によっては、App_Code配下のコードが通常のコンパイル単位とは別扱いになり、参照解決の挙動が変わる原因になります。

一方、質問の前提にあるようなASP.NET MVC（Webアプリケーション寄りの構成）では、そもそもApp_Codeを必須としないケースが多く、App_Codeが提供する「特別扱いの恩恵」を受ける必要が薄いことがほとんどです。結果として、App_Codeを使うことでメリットよりデメリットが勝ち、今回のような「フォルダーによって参照が見えたり見えなかったりする」不具合の温床になり得ます。

App_Codeが“特別扱い”される背景（なぜ挙動が変わるのか）

App_Codeが絡むと、環境によっては次のような構図になります。

観点	通常の.cs（一般フォルダー）	App_Code配下の.cs
コンパイルの扱い	プロジェクトのコンパイル対象としてビルドに含まれる	環境・種別によっては別のコンパイル単位／特別ルールで処理される
参照の解決元	csprojに定義された参照（HintPath/CopyLocalなど）を素直に使える	参照の見え方が異なり、結果としてusingが解決しないことがある
トラブルの典型	参照が壊れていなければ基本的に安定	DLL参照差、ビルド順序差、キャッシュ差が表面化しやすい

つまり、「App_Code配下だけ参照DLLが見えない」は、App_Codeが引き金となって“同じプロジェクト内なのに別の世界でコンパイルされているような状態”を作っている可能性が高い、ということです。

「1_App_Code」という謎フォルダーが出る理由（作る必要はない）

エラー一覧に 1_App_Code のようなフォルダー名が見えると「プロジェクト内のどこかに定義があるはず」と探してしまいがちですが、これは多くの場合、ビルドや動的コンパイルの過程で生成される一時的な中間ディレクトリ名として出てきます。

ポイントは次の通りです。

• 1_App_Code はあなたが作ったフォルダーではなく、内部処理上の“区分”として付く名前であることが多い
• そのため、プロジェクト上に存在しなくてもエラー一覧に出る（＝表示だけ追っても根本原因に届かない）
• 原因を正すべきは「1_App_Codeを作る」ことではなく、App_Codeが特別扱いされない構成に寄せるか、特別扱いされる前提に合わせて参照・配置を整えること

ここまでを踏まえると、最短での解決策はかなり明確になります。

最短で直す方法：App_Codeをやめて通常フォルダーへ移動（リネーム／撤去）

結局のところ、MVC系の構成でApp_Codeを使い続ける必然性は薄いことが多く、最短で安定させるなら「App_Codeを廃止」が強力です。やることはシンプルで、App_Code配下の.csを一般的なフォルダー（例：Controllers、Models、Services、Infrastructure、Commonなど）へ移すだけです。

移動先フォルダーの例

目的	おすすめフォルダー名	入れるものの例
コントローラー関連	Controllers	Controllerクラス、Action共通処理
ドメイン／モデル	Models / Domain	Entity、ViewModel、DTO、検証ロジック
共通処理	Common / Shared	ユーティリティ、拡張メソッド、定数
インフラ層	Infrastructure	DBアクセス、外部APIクライアント、設定読み込み
サービス層	Services	業務ロジック、アプリケーションサービス

具体的な手順（失敗しにくい順序）

1. App_Codeを使わない通常フォルダーを作成する（例：Common）
2. App_Code配下の.csファイルを、新しいフォルダーへ移動する（エクスプローラーではなく、できればソリューションエクスプローラー上で移動）
3. 必要ならnamespaceを整理する（フォルダー移動でnamespaceが崩れている場合がある）
4. ソリューションのクリーン → リビルドを実行する
5. まだ挙動が残る場合は、bin/obj/.vsを削除してから再ビルドする（後述）

これだけで、App_Code由来の特別扱いが外れ、プロジェクト内のどこに置いても参照DLLが同じように見える状態へ戻せることが多いです。質問内容にもある通り、App_Codeを削除してControllersなどに移すことで解消した事例が実際にあります。

移動後にハマりやすいポイント

• 移動後にnamespaceが変わり、別ファイル側の using が必要になる（または不要になる）
• 拡張メソッドが見えない場合は、static クラスであること、参照先namespaceをusingしていることを再確認
• 部分クラス（partial）を使っている場合、分割ファイル同士のnamespaceが揃っているかを確認

App_Codeを廃止した時点で“フォルダー依存の参照差”という根本が消えるため、最終的に作業量が最小になりやすいのがこの方法です。

App_Codeを残したい場合に確認すべきこと（直す方向が“別”になる）

事情があってApp_Codeを残したい（既存資産が多い、運用上の制約がある）場合は、App_Codeが特別扱いされる前提に合わせて、参照の見え方を揃える必要があります。ここでは「何を見ればよいか」を現実的な順番で並べます。

チェックリスト（優先度順）

チェック項目	見方	問題だった場合の典型	対処例
プロジェクト種別が混在していないか	Webアプリケーション／Webサイトのどちらか、構成がブレていないか	一部が動的コンパイル扱いになり、参照解決が分断	Webアプリケーションに統一、またはApp_Codeを撤去
参照DLLが出力先にコピーされているか	参照のプロパティでCopy Local（ローカルコピー）相当の設定	プロジェクト内では見えても、別コンパイル単位からは見えない	DLLをbinへ配置されるようにする／参照設定を見直す
App_Code配下ファイルのビルドアクション	ファイルのプロパティで「ビルドアクション」	CompileではなくContent/None扱いで解析が不安定	必要に応じてCompileへ
参照追加方法が一貫しているか	NuGet参照、ローカル参照、GAC参照が混在していないか	HintPathや条件付き参照で、環境によって差が出る	参照元を統一（可能ならNuGet）
web.config側に参照が必要な構成になっていないか	動的コンパイルが絡む場合、web.configのassemblies指定	App_Codeだけ参照が不足して解決しない	構成に応じてassembliesを追加（ただし根本的には撤去推奨）

ここで強調したいのは、App_Codeを残す場合は「参照DLLを追加すれば全部の.csで見えるはず」という前提が崩れやすい点です。運用を安定させたいなら、やはりApp_Codeを“普通のフォルダー名”に寄せるほうが事故率は下がります。

csproj破損・手編集の影響を疑うべきサインと確認方法

質問内容にある通り、参照の表示が不自然だったり、急に挙動が崩れたタイミングが「csprojを手編集した」「設定をいじった」直後だったりする場合、.csprojの記述不整合を疑う価値があります。参照が壊れると、フォルダー配置の違いが“きっかけ”となって症状が表面化することがあります。

csprojでまず確認したいポイント

• TargetFrameworkVersion が意図通りか（例：v4.8）
• 参照DLLが <Reference> として正しく入っているか、HintPath が正しい場所を指しているか
• 条件付き（Condition） で Debug/Release どちらかだけ参照されていないか
• App_Code配下の.csが <Compile Include> から外れていないか（または意図せず別Item扱いになっていないか）

参照が怪しいときに出やすい“匂い”

• 参照マネージャーの表示が普段と違う（互換性表示が極端、説明が出ない等）
• 一部の構成だけ参照できない（DebugはOKだがReleaseはNG等）
• 他の開発者環境では再現しない／CIでは失敗する

Visual Studio上で確認するなら、プロジェクトを右クリックして「プロジェクト ファイルの編集（.csproj）」を開き、参照ブロックを目視します。例えばローカルDLL参照であれば、概ね次のような形になっていることが多いです。

<ItemGroup>
  <Reference Include="SomeLibrary">
    <HintPath>..\packages\SomeLibrary\lib\net48\SomeLibrary.dll</HintPath>
    <Private>True</Private>
  </Reference>
</ItemGroup>

もしここが崩れている、HintPathが存在しない場所を向いている、Conditionで外れている、といった不整合があれば、App_Codeに限らず参照解決が不安定になります。心当たりのある変更があるなら、まずは変更を戻して再ビルドするのが最短です。

キャッシュ／一時ファイルで症状が長引くケース：クリーンだけで直らないときの掃除

App_Code問題に限らず、Visual Studioはソリューション情報やIntelliSense、ビルド中間生成物を複数箇所に持ちます。参照解決が“直ったはずなのに赤線が消えない”“エラー一覧だけ残る”といった場合は、キャッシュ起因で症状が長引いている可能性があります。

安全に試せる掃除手順

1. Visual Studioを終了する
2. ソリューション配下の bin と obj を削除する
3. ソリューション配下の .vs フォルダーを削除する（隠しフォルダーの場合あり）
4. Visual Studioを起動してリビルドする

さらに「1_App_Code」のような一時ディレクトリに由来する痕跡が疑わしい場合、ASP.NETの一時コンパイル出力が溜まっていることがあります。運用ルールや権限の範囲で、必要に応じて一時ファイルをクリアすることで改善するケースもあります（ただし、根本はApp_Codeの特別扱いを避けることです）。

原因別・対処の早見表（迷ったらここから）

症状	可能性が高い原因	最短の対処	補足
App_Code配下だけusingが解決しない	App_Codeの特別扱いで参照解決が分断	App_Codeを廃止して通常フォルダーへ移動	MVCではこの解決が最も安定
エラー一覧に1_App_Codeが出る	一時コンパイル過程の表示／キャッシュ痕	App_Code撤去＋bin/obj/.vs削除	フォルダーを作る方向は逆効果になりやすい
参照の表示が不自然、突然壊れた	csproj手編集や条件付き参照の不整合	csprojの変更を戻す／参照定義を整える	Debug/Release差やCI差が出る場合は特に疑う
移動しても赤線が消えない	IntelliSenseキャッシュ／中間生成物が残留	bin/obj/.vs削除→リビルド	クリーンだけでは残ることがある

再発防止：MVC（.NET Framework 4.8）でのフォルダー設計と参照管理のコツ

今回のようなトラブルは、参照DLLそのものよりも「プロジェクトの構造」と「特殊フォルダー名」が原因で起きることが少なくありません。再発防止としては、次の考え方が効きます。

フォルダー命名は“特別扱いされる名前”を避ける

• App_Code を避け、目的が伝わる名前（Common/Services/Infrastructureなど）にする
• フレームワークが予約している可能性のある名前（App_Dataなど）も、用途が違うなら安易に使わない

参照は“どこから見ても同じ”状態に寄せる

• 参照DLLは可能ならNuGetなどで管理し、環境差を減らす
• ローカルDLL参照の場合は、HintPathやCopy設定が意図通りかを定期的に確認する
• Debug/Releaseや開発PC/CIで差が出ないよう、条件付き参照をむやみに増やさない

csprojを手編集するなら“ルール化”する

• 手編集した場合は必ず差分を確認し、レビューを通す
• 参照やCompileのItemGroupを整理し、重複や条件分岐の乱立を避ける
• プロジェクト構成変更の直後は、bin/obj/.vs削除を含むクリーンなビルドで確認する

「App_Codeに入れると便利だった時代」があったのは事実ですが、MVC構成や現代的なプロジェクト運用では、特殊フォルダーに寄せない設計のほうがトラブルシューティングも運用もシンプルになります。

よくある質問

App_Codeを使ってはいけないのですか？

禁止というより、MVC構成では“使う必然性が薄く、ハマりどころが増える”というのが実務的な答えです。WebFormsや特定の運用要件でApp_Codeを活かす構成が存在する一方、MVCで共通クラスやサービスを置く用途なら、通常フォルダーで十分です。

「1_App_Code」フォルダーを作れば直りますか？

多くの場合、直りません。これは内部処理で生成される一時的な区分名として表示されている可能性が高く、プロジェクトに同名フォルダーを作るとむしろ状況が複雑化しやすいです。対処は「App_Codeを廃止する」「参照解決を揃える」「キャッシュを掃除する」が基本線です。

App_Codeを廃止したのに、まだusingが解決しません

この場合は、App_Code固有の問題が解消したあとに、参照設定やキャッシュ問題が残っている可能性があります。次を順に試すと収束しやすいです。

• bin/obj/.vs削除 → 再ビルド
• 参照DLLのプロパティ（コピー設定・HintPath）再確認
• csprojの参照定義が壊れていないか確認

プロジェクトを大きく触れないで対処したい場合の妥協案は？

どうしても移動が難しい場合は、App_Code配下を残しつつ、参照DLLがApp_Code側からも見えるように「出力先へのコピー」「構成の統一」「参照追加方法の一本化」を徹底する必要があります。ただ、長期的にはApp_Code撤去のほうが総コストは下がりやすいです。

App_Code配下だけ参照DLLが見えない現象は、単発の設定ミスではなく、App_Codeの特別扱いとプロジェクト構成の相性が原因で起きることが多いです。迷ったら、まずはApp_Codeを通常フォルダーへ置き換える——これが一番早く、再発もしにくい解決策です。