ASP.NET MVC 5 でモデルベース コントローラー追加（スキャフォールディング）を実行すると「There was an error running the selected code generator」「Exception has been thrown…」で止まることがあります。原因の多くは Web.config の接続文字列の書き場所。最短で直す手順とチェックポイントを整理します。
起きている現象：MVC 5 の「モデルベース コントローラー追加」が失敗する
Visual Studio の ASP.NET MVC 5 プロジェクトで、右クリックから「追加」→「コントローラー」→「MVC 5 コントローラー (Entity Framework を使用し、ビューがある)」のような項目を選び、モデルと DbContext を指定して CRUD（作成・表示・編集・削除）を自動生成しようとしたときに、次のような抽象的なエラーだけが表示されて処理が止まるケースがあります。
- There was an error running the selected code generator:
- Exception has been thrown by the target of an invocation.
このメッセージは「コード生成処理の内部で例外が出た」ことしか分からず、Visual Studio の再インストールやプロジェクトの作り直しをしても改善しないことがよくあります。実際には、開発環境ではなくプロジェクト側の設定ミスが原因になっていることが多いです。
| タイミング | 症状 | よくある誤解 |
|---|---|---|
| コントローラー追加ウィザードの実行中 | CRUD のファイル生成が始まらない／途中で中断する | Visual Studio やテンプレートの不具合だと思いがち |
| モデル・DbContext を選択して OK を押した直後 | 上記 2 行のエラーだけ出て完了しない | NuGet の入れ直しや VS 再インストールで直ると思いがち |
結論：Web.config の接続文字列は <connectionStrings> 配下に置く
原因として一番多いのが、Web.config の接続文字列（connectionString）の配置場所が誤っているパターンです。スキャフォールディングは設計時（デザインタイム）にプロジェクトを読み込み、DbContext を生成して DB 接続の情報を参照します。その際に参照するのが、原則として Web.config の <connectionStrings> セクションです。
つまり、接続文字列を <appSettings> など別の場所に書いていたり、XML の構造が崩れていたりすると、スキャフォールディング側は接続文字列を取得できず、結果として「target of an invocation」のような分かりにくい例外になりやすい、ということです。
正しい修正例（Web.config）
<connectionStrings>
<add name="MovieDBContext"
connectionString="****"
providerName="System.Data.SqlClient" />
</connectionStrings>
ポイントは 2 つです。
- 必ず
<connectionStrings>の直下に<add>を置く nameは基本的に DbContext 名と一致させる（後述）
配置場所が間違っている例（よくある）
以下は「見た目はそれっぽい」のに、スキャフォールディングからは読めない／あるいは XML として正しく解析できない例です。
| 誤りのパターン | ありがちな書き方 | なぜ失敗するのか |
|---|---|---|
| appSettings に書いてしまう | <appSettings><add key="MovieDBContext" value="..." /></appSettings> | ConfigurationManager.ConnectionStrings で取得できない |
| system.web 配下に入れてしまう | <system.web>...<connectionStrings>...</connectionStrings></system.web> | <connectionStrings> は <configuration> 直下が前提 |
| Views/Web.config に追記してしまう | Razor 用の Web.config に接続文字列を追加 | スキャフォールディングが参照するのは通常ルートの Web.config |
| XML の閉じ忘れ・属性の引用符ミス | <add name="MovieDBContext" connectionString="..."> など | 設定読み込み自体が例外になり、原因が隠れて見える |
なぜ「Exception has been thrown by the target of an invocation.」になるのか
このエラー文言は、.NET の TargetInvocationException に対応していることが多く、実際の原因となる例外が “内側” に隠れている状態を指します。スキャフォールディングは内部でテンプレート（T4 など）や設計時サービスを呼び出し、リフレクションであなたのプロジェクトの DbContext を生成します。その途中で、次のような例外が起きると「呼び出し先で例外が投げられました」という形に丸められます。
- 設定ファイルが不正な XML で読み込めない
- 指定した name の接続文字列が見つからず、DbContext の生成時に例外
- providerName が不正で ADO.NET プロバイダーを解決できない
結果として、ダイアログ上は “何が悪いか” が見えにくく、手当たり次第の再インストールに走ってしまいがちです。まずは Web.config の接続文字列周りを疑うのが最短です。
最短で直す手順（実作業のチェックリスト）
「どこを直せばいいか分からない」ときは、次の順番で確認すると迷いません。特に 1〜3 がほぼ原因の中心です。
- ルートの Web.config を開き、
<configuration>直下に<connectionStrings>があるか確認する <connectionStrings>の中に<add name="..." />があり、name が DbContext 名と一致しているか確認する- XML の閉じタグ、引用符、エスケープ（
&など）が正しいか確認する - 保存してから、いったん ソリューションをビルド（エラーがない状態にする）
- 必要なら Visual Studio を再起動し、同じ手順でもう一度「コントローラー追加」を実行する
実務では、接続文字列の値そのものよりも、タグの配置とname の一致でハマることが圧倒的に多いです。
DbContext 名と connectionStrings の name を合わせる理由
Entity Framework（MVC 5 チュートリアルでよく使う EF6）では、DbContext を生成するときに「どの接続文字列を使うか」を次のいずれかで決めます。
- コンストラクターで
base("接続文字列名")を指定する - 指定がない場合、DbContext のクラス名（例：
MovieDBContext）を接続文字列名として探す
スキャフォールディングが「コンテキストを選ぶ → DB に接続してテーブル構造を見て → CRUD を生成する」流れになっている以上、DbContext が正しく接続先を特定できる状態であることが必須です。ここがズレていると、設計時に例外が出て生成できません。
典型的な DbContext の例
using System.Data.Entity;
public class MovieDBContext : DbContext
{
// 省略した場合、接続文字列名はクラス名（MovieDBContext）として探索されます
public DbSet Movies { get; set; }
}上の書き方なら、Web.config は次の対応になります。
| C# 側 | Web.config 側 | 一致している必要 |
|---|---|---|
class MovieDBContext | <add name="MovieDBContext" ... /> | ほぼ必須（省略時の既定探索名になる） |
接続文字列名を変えたい場合
「DbContext 名と DB 名は分けたい」「複数 DB を切り替えたい」などで name を変える場合は、C# 側で明示しておくと混乱が減ります。
public class MovieDBContext : DbContext
{
public MovieDBContext() : base("MovieDb")
{
}
}この場合は Web.config 側を name="MovieDb" に合わせます。スキャフォールディングで選んだ DbContext が、実際に参照する接続文字列名がどれかを意識しておくと、再発が減ります。
実用的な接続文字列の例（SQL Server / LocalDB）
チュートリアル通りに進めている場合、開発機の SQL Server Express LocalDB を使うことが多いです。以下は MVC 5 / EF6 でよく使う接続文字列の例です（環境に合わせて変更してください）。
<connectionStrings>
<add name="MovieDBContext"
connectionString="Data Source=(LocalDb)\MSSQLLocalDB;Initial Catalog=MovieDBContext;Integrated Security=True;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient" />
</connectionStrings>補足として、次の点を押さえるとトラブルが減ります。
- バックスラッシュは 1 つで OK（Web.config では
(LocalDb)\MSSQLLocalDBと書く。C# の文字列リテラルのように\\と二重にしない） MultipleActiveResultSets=Trueは EF 利用時に付けることが多い（必須ではないが無難）- SQL 認証を使う場合、ユーザー名・パスワードを含むため取り扱いに注意（後述）
スキャフォールディングが参照する Web.config はどれ？
MVC 5 プロジェクトには Web.config が複数存在することがあります。特に Views フォルダ配下の Web.config は Razor の表示設定などが中心で、アプリの接続文字列を置く場所としては不適切です。迷ったら、プロジェクト直下（ルート）の Web.config を編集してください。
| ファイル | 役割 | 接続文字列を書くべき？ |
|---|---|---|
| プロジェクト直下の Web.config | アプリ全体の設定（接続文字列、認証、compilation など） | はい |
| Views/Web.config | Razor ビューの設定（namespaces、pages など） | いいえ |
| Areas/*/Views/Web.config | Area 内のビュー設定 | いいえ |
XML ミスで生成が落ちるのに気づきにくい理由
Web.config は XML なので、わずかなミスでも読み込みが失敗します。ただし、スキャフォールディングの UI は「どの行が壊れているか」を親切に表示してくれないことがあります。特に次のミスは目視で見落としやすいので注意してください。
- 引用符の片側だけが全角になっている（コピー＆ペースト時に起きがち）
- アンパサンド（&） を含む値をそのまま書いている（XML では
&にする必要がある） - 閉じタグ
</connectionStrings>を書き忘れている <add ... />の/が抜けている
「なぜか急にスキャフォールディングが失敗し始めた」場合は、直前に Web.config を触っていないかを思い出すのが有効です。
それでも直らないときの追加切り分け
接続文字列の配置を直しても改善しない場合は、次の観点で原因を絞り込みます。ここから先は頻度は下がりますが、現場ではたまに遭遇します。
ビルドが通っているか（設計時はビルド成果物を使う）
スキャフォールディングはプロジェクトの型情報を参照するため、ビルドが壊れていると生成に失敗します。まずはソリューション全体をビルドし、エラーが 0 になってから再試行してください。
DbContext のコンストラクターで例外を投げていないか
DbContext のコンストラクターで独自処理（設定読み込み、ファイル I/O、外部サービス呼び出しなど）を入れていると、設計時に想定外の例外になりがちです。スキャフォールディングが通るまでは、DbContext の初期化はシンプルに保つのがおすすめです。
NuGet パッケージの整合性（EntityFramework と MVC）
古いプロジェクトを触っている場合、MVC / EF のバージョン差でテンプレートが想定する API が見つからず落ちることがあります。次のような状態を目安に確認します。
| 確認ポイント | 見る場所 | 目安 |
|---|---|---|
| EntityFramework が参照されているか | 参照 / packages.config | EF6 系が入っていればチュートリアルと整合しやすい |
| Microsoft.AspNet.Mvc などが揃っているか | 参照 / packages.config | MVC5 の主要パッケージが欠けていない |
| NuGet の復元ができているか | ソリューションのビルドログ | 参照エラー（黄色三角）がない |
ただし、今回の「ターゲットの呼び出し先で例外」の代表例はやはり Web.config なので、まずは connectionStrings の位置と XMLを最優先で確認してください。
再発防止：接続文字列を安全に管理するコツ（MVC 5 編）
チーム開発や本番運用を考えると、接続文字列を直書きした Web.config をそのまま Git に入れるのは避けたい場面があります。一方で、MVC 5（.NET Framework）のスキャフォールディングは Web.config の <connectionStrings> を見に行くため、“設計時に読める場所” と “安全な管理” を両立させる工夫が必要です。
- 開発用の接続文字列は Web.config に置き、資格情報を含めない（Windows 認証や LocalDB を使う）
- 本番用は Web.Release.config の変換で差し替える（Config Transform）
- どうしても秘密情報が必要なら、運用側で Web.config を差し替える手順を用意する
この運用にしておくと「スキャフォールディングが参照できない場所に移してしまって失敗する」事故を防げます。
まとめ
MVC 5 の「モデルベース コントローラー追加（スキャフォールディング）」が There was an error running the selected code generator や Exception has been thrown by the target of an invocation. で止まるとき、最初に疑うべきは Web.config の接続文字列です。
- 接続文字列は ルート Web.config の <connectionStrings> 配下に置く
nameは基本的に DbContext 名と一致させる- XML の閉じ忘れ・構文ミスでも同様の抽象的エラーになりやすい
- 修正後は保存して ビルド → 再実行の順で確認する
この 4 点を押さえるだけで、再インストールでは直らないタイプのスキャフォールディングエラーは高確率で解消できます。まずは Web.config を開き、<connectionStrings> の位置と中身を丁寧に見直してください。
コメント