SQL Serverで列を追加したのでEF(Database First)のEDMXを作り直したら、ControllersでUsers1やTblillerが「型または名前空間が見つからない」…そんなときは、EDMXそのものよりも“生成されたC#クラス”が出ていない/名前が変わった可能性が高いです。本記事では最短で切り分ける手順と、Visual Studio 2022のT4不具合への対処をまとめます。
症状：EDMXは作れたのに、Users1 / Tbliller / tblilceler が消える
Entity Framework（EF）のDatabase Firstでよくあるのが、次のような状況です。
- SQL Server 側に string（nvarchar など）の列を追加した
- 既存の
.edmxを削除して、DBから「ADO.NET Entity Data Model」を再生成（再追加）した - ところが、コントローラーで使っていた
Users1/Tbliller/tblilcelerが 「型または名前空間が見つからない」 になる - 「モデルは追加されているはずなのに、DbContextがテーブルを見ていない」ように見える
このエラーは“DB接続の問題”というより、生成されたC#コード（エンティティ/DbContext）がプロジェクトに存在しない・参照できないことが原因で起きます。逆に言うと、問題の本丸はEDMXよりもコード生成です。
まず理解：Database First は「EDMX + コード生成」で動いている
Database First（EDMX）では、Visual Studioが以下を組み合わせてモデルを成立させます。
| 構成要素 | 役割 | トラブルが起きた時の見え方 |
|---|---|---|
Model.edmx | DBスキーマの設計図（概念モデル/ストレージモデル/マッピング） | EDMXは存在するのに型が無い、という状態になり得る |
*.tt（T4テンプレート） | エンティティクラスやDbContextを生成するテンプレート | T4が失敗すると Users1.cs などが生成されず “型が無い” になる |
生成された .cs ファイル | コンパイル対象になる実体（public partial class Users1 など） | これが無い/名前が変わる/別namespaceになるとビルドが落ちる |
つまり、EDMXを再追加したときに「T4が走っていない」または「T4がエラーで止まっている」と、モデルは見えてもクラスは出てきません。結果として、コントローラー側からは Users1 が“存在しない型”になります。
最短の切り分け：最初に見るべき3点
遠回りせずに原因を潰すなら、次の順番が最速です。特に1番目が重要です。
| 優先 | 確認ポイント | 見る場所 | NGだった場合の方向性 |
|---|---|---|---|
| 最優先 | エンティティクラスが実ファイルとして生成されているか | ソリューション エクスプローラー（Users1.cs / Tbliller.cs / tblilceler.cs など） | T4/EFツールが失敗、または生成設定が無効。まず生成を復旧させる |
| 次 | namespace / コンテキスト名が変わっていないか | 生成されたクラスの先頭 namespace xxx、コントローラーの using | コード側を追従（using/型名/コンテキスト名の修正） |
| 次 | EDMX生成ウィザードで該当テーブルを選んだか | 「モデルの更新/作成」時のテーブル選択 | テーブルを選び直して再生成。DbSetも出るか確認 |
この3点だけで、原因の大半はAかBかに分類できます。
原因A：プロジェクト側の参照・生成物不足（よくある）
エンティティの .cs が生成されていない
「EDMXはあるのに型が無い」パターンの王道です。典型例として、ソリューション内に次がありません。
Users1.cs/Tbliller.cs/tblilceler.csなど、エンティティに対応するクラスxxxxEntities.cs（DbContext）や、DbSet<Users1>を含むコンテキスト
Database Firstの生成方式はプロジェクト設定により大きく2つに分かれます。
| 生成方式 | 見えるファイル | 特徴 | トラブル時の対処 |
|---|---|---|---|
| T4（推奨されがち） | Model.tt / Model.Context.tt と、それにより生成される Model.cs など | テンプレートで出力を制御できるが、VS更新の影響を受けることがある | .tt を「カスタムツール実行」、T4エラー確認 |
| EDMX内生成（Designer.cs） | Model.Designer.cs（EDMX配下にぶら下がる） | テンプレートの影響は少ないが、カスタマイズしづらい | EDMXのプロパティ（カスタムツール/生成戦略）確認 |
今回のように「Visual Studio 2022のT4不具合」が絡むケースは、ほとんどがT4方式で生成されるはずの.csが出ていない状況です。
T4の基本チェック：.tt を手動で生成してみる
次の手順で、生成が正常に動くか確認できます。
- ソリューション エクスプローラーで
Model.tt（またはModel.Context.tt）を探す - 右クリック → 「カスタム ツールの実行」（Run Custom Tool）
- 出力された
.csが更新されるか、エラー一覧にT4関連エラーが出ないかを見る
ここでエラーが出る場合は、以降の「原因B（VSのT4不具合）」側の対処が必要です。逆に、手動生成で Users1 などが出るなら、プロジェクトの参照やnamespaceの問題である可能性が高くなります。
namespace / using が変わっている
EDMXを削除→再追加すると、以下が自動で変わることがあります。
- モデルの既定の名前空間（例：
MyProject.Models→MyProject.Data） - DbContext名（例：
ISKOMENUEntities→ISKOMENUEntities1のように末尾が変わる） - エンティティ名（複数形/単数形、先頭大文字化など）
特にDbContext名が変わると、コントローラー側に次のようなエラーが連鎖します。
using (var db = new ISKOMENUEntities())
{
// db.Users1 ... が見つからない
}生成されたコンテキスト名が ISKOMENUEntities1 になっているなら、型名を合わせるか、EDMX側の設定（コンテナ名/コード生成設定）を揃える必要があります。
また、namespaceがズレている場合は、単純に using の追加/修正で直ることもあります。
using YourProject.Models; // 以前のnamespace
using YourProject.Data; // 新しく生成されたnamespace（例）EDMX作成時にテーブルを外している
再生成時のウィザードで、対象テーブル（例：Users1 / Tbliller / tblilceler）のチェックを外すと、そもそもクラスが生成されません。
再生成した直後に DbContextに DbSet<Tbliller> が存在するか を見ると判定が早いです。
public partial class ISKOMENUEntities : DbContext
{
public virtual DbSet<Tbliller> Tbliller { get; set; } // これが無いなら未選択の可能性
}原因B：Visual Studio 2022のEF（T4）生成不具合でクラス生成が失敗する
「以前は同じ手順で更新できたのに、今回はできない」というケースで濃厚なのがこれです。Visual Studioの更新により、EFのコード生成（T4）が内部的に失敗し、結果としてエンティティ/コンテキストの .cs が生成されず、コンパイル時に「型または名前空間が見つからない」が出ます。
見分け方はシンプルで、次のどれかが当てはまれば可能性が高いです。
.ttを「カスタムツール実行」すると、エラー一覧にT4関連のエラーが出る- EDMXを再生成したのに
Model.Context.cs/Model.csの更新日時が変わらない - 生成物がゼロになり、コントローラーの型参照エラーが一気に出る
対処1：EF.Utility.CS.ttinclude / EF6.Utility.CS.ttinclude の修正でT4生成を通す
スレッドでよく挙がる回避策が、Visual Studio配下のEFテンプレート（ttinclude）を修正して、T4が落ちないようにする方法です。
対象になりやすいファイル名は次の2つです。
EF.Utility.CS.ttincludeEF6.Utility.CS.ttinclude
内容としては、テンプレート内でリフレクションを使って GenerationEnvironment を取得する処理があり、そこで BindingFlags.NonPublic が指定されている箇所を BindingFlags.Public 側に寄せる（または Public で取得できるようにする）ことで生成が通る、というパターンです。
例（概念的なイメージ）:
// NGになりやすい（NonPublicを参照）
BindingFlags.NonPublic
// 回避として変更が提案されがち（Publicを参照）
BindingFlags.Public注意: この方法は「VSのインストール配下ファイルを直接編集」になるため、更新で元に戻ることがあります。また、組織のルールによっては編集が許可されない場合もあります。可能なら、修正前にファイルをバックアップし、変更点をメモしておくのが安全です。
対処2：Visual Studio を更新/ロールバックして挙動が安定する版に揃える
テンプレート編集が難しい場合は、Visual Studioのバージョンを変えるのが手堅いです。報告例としては「特定の更新で発生し、特定の版に戻すと直る」ケースがあり、Visual Studio Installer のロールバック機能を使って環境を揃える、というアプローチになります。
- 更新で入った不具合の可能性がある → 直近の更新を戻す（ロールバック）
- 逆に古い環境で起きている → 最新の修正版へアップデートする
チーム開発の場合は「誰かのPCだけで発生」しがちなので、VSのバージョン差を疑うと切り分けが早いです。
対処3：生成エラーを“見える化”して、原因をログで潰す
「何となく生成されない」状態を抜けるには、T4生成エラーを確実に拾うのが有効です。
- エラー一覧で
.ttやTextTemplatingFileGeneratorが絡むメッセージを探す .ttを開いて、上部にある<#@ include file="..." #>の参照先が見つかっているか確認する- セキュリティソフトや権限で、VSが生成物を書き込めていない可能性も疑う（管理者権限での起動など）
実務で効く：作り直し後の復旧手順（チェックリスト形式）
“直すためにやること”を順番に並べると、次の流れが安定します。
| 手順 | やること | 狙い | うまくいったサイン |
|---|---|---|---|
| 1 | EDMX再生成直後に、エンティティの .cs が存在するか確認 | “型が無い”の本質を即判定 | Users1.cs 等がプロジェクトに出る |
| 2 | .tt を右クリック → 「カスタム ツールの実行」 | T4が落ちていないか確認 | 生成物の更新日時が変わる |
| 3 | エラー一覧でT4/テンプレートのエラーを確認 | Visual Studio側の不具合を特定 | .tt関連エラーが消える |
| 4 | namespace / DbContext名を確認し、コントローラーのusing/型名を合わせる | 生成物はあるのに参照できない状態を解消 | 型参照エラーが減る/消える |
| 5 | 必要なテーブルがウィザードで選択されているか確認 | DbSetが出ない原因を排除 | DbContextに対象のDbSetが出る |
| 6 | Clean / Rebuild、必要なら bin / obj を削除して再ビルド | 古い生成物・キャッシュを一掃 | ビルドが通る |
ポイントは、ビルドエラー（Users1が無い）を見てnamespaceをいじる前に、まず“クラスが生成されているか”を見切ることです。生成されていないのにusingを直しても、根本は直りません。
現場で起きがちな落とし穴
「EDMXを削除→再追加」で、手作業で増やした拡張が消える
Database Firstでは、エンティティにロジックを足す場合、生成ファイルを直接編集せずpartial classを別ファイルで作るのが定石です。
もし生成ファイルを直接編集していた場合、EDMXを作り直すと変更が消えます。ビルドは通っても挙動が変わるので、再生成前にGitなどで差分を取っておくのが安全です。
エンティティ名の自動変換で “似た名前” が増える
例として、テーブル名が Users1 のとき、再生成で Users や Users11 のような紛らわしい名前に変わることがあります。これはウィザード側の命名規則（複数形、衝突回避）で起きやすいです。
「同名の型が複数ある」「想定の型名が見つからない」場合は、生成されたクラス名そのものをプロジェクト内検索で確認し、コントローラー側を合わせるか、EDMX側の設定を調整します。
“テーブルはあるのにDbSetが無い”は、選択漏れ以外にも起きる
テーブル選択を間違えていないのにDbSetが出ない場合は、次も確認してください。
- テーブルに主キーが無い（EFがエンティティとして扱えず除外されることがある）
- ビュー/ストアドで、ウィザード上は見えているが生成が制限されている
- スキーマ権限の問題で、接続ユーザーから列情報を読めていない
よくある質問
コントローラーに出るのは “Users1 だけ” です。他はOK。なぜ？
同名衝突や命名規則の影響で、生成後のクラス名が変わっている可能性があります。プロジェクト全体検索で class Users1 を探し、存在しない場合は Users や Users11 など別名になっていないか確認してください。
「型または名前空間が見つからない」が大量に出て、何から手を付けていいか分かりません
この状態は、ほぼ確実に生成物の欠落です。まずは .tt があるか、.tt を手動で生成できるかを確認し、生成が通らないなら Visual Studio/T4 側の対処（テンプレート修正・更新/ロールバック）に進むのが最短です。
EDMXを削除せず「モデルをデータベースから更新」ではダメですか？
基本的にはその方が安全です。削除→再追加は、名前空間やコンテキスト名が変わったり、設定が初期化されたり、カスタム設定が消えたりします。更新がうまくいかない事情がある場合でも、まず更新を試し、ダメならバックアップを取ってから作り直す流れが事故を減らします。
長期的にはどうするのが良い？
EF6のDatabase First（EDMX）は、Visual Studioの更新の影響を受けやすい側面があります。長期運用では、以下のどちらかを検討すると安定します。
- EF6継続なら、チームでVisual Studio/EFツールのバージョンを固定し、更新ルールを決める
- 将来的に可能なら、EF Coreへの移行と Scaffold（リバースエンジニアリング）でコード生成を管理する
まとめ：最初に見るべきは「クラスが生成されているか」
EDMXを作り直した直後に「Users1 / Tbliller / tblilceler が見つからない」と出たら、原因は大きく2つです。
- 原因A： 生成されたエンティティ/DbContextが無い、namespaceや型名が変わった、テーブル選択漏れ
- 原因B： Visual Studio 2022のT4生成が不具合で失敗し、そもそもクラスが生成されない
特に、モデルを削除→再追加したときにエラーが急増する場合は、T4が走っていない/失敗している可能性が高いです。まずは生成物の有無を確認し、必要ならテンプレート修正やVisual Studioのバージョン調整で、コード生成を復旧させてください。
コメント