VS2022でDesignerが開けない「System.Configuration.ApplicationScopedSettingAttribute が見つからない」原因と解決策（VS2019移行）

Visual Studio 2019（VS2019）で作成したプロジェクトを Visual Studio 2022（VS2022）で開いたとき、フォームや設定（Settings）の Designer を開く瞬間に「System.Configuration.ApplicationScopedSettingAttribute が見つからない」と表示されて編集できなくなることがあります。原因の考え方と、手順どおりに進めれば直しやすい切り分け方法をまとめます。

起きている現象（症状）

VS2019 では問題なく開けていたプロジェクトを VS2022 で開くと、フォームや設定ファイルなどの Designer（デザイナー）を表示するタイミングで、次のようなエラーが出て画面が開かなくなるケースがあります。

The type 'System.Configuration.ApplicationScopedSettingAttribute' could not be found.

このエラーは “アプリ本体の実行時” ではなく、主に “設計時（Designer）” の内部ビルドや型解決で失敗しているときに出やすいのが特徴です。つまり、「ビルドは通るのに Designer だけ壊れる」、あるいは「特定の Designer（Settings だけ、WinForms だけ）が壊れる」という形で現れがちです。

影響が出やすい箇所	よくある具体例	起きたときの困りごと
Settings（設定）Designer	Settings.settings / Settings.Designer.cs	接続文字列や設定値の編集・追加ができない
Windows Forms Designer	Form1.cs（デザイン）	フォーム画面が開かず、UI編集が止まる
一部のデザイナー関連生成物	Resources.resx、デザイナー生成コード	生成コードの更新ができず差分が崩れる

なぜ VS2022 で起きやすいのか（原因の本質）

結論から言うと、多くの場合は「ターゲットフレームワークや参照アセンブリ（ターゲットパック）、SDK/ランタイム、NuGet 参照のどこかが不足・不整合」です。

Designer は単にファイルを表示しているだけではありません。裏側で次のような処理を行います。

設計時ビルド（Design-time build）を実行し、生成コードや参照関係を解決する
プロパティグリッドやコンポーネント一覧を出すために、対象アセンブリの型情報をロードする
Settings の場合は Settings.Designer.cs に含まれる属性（Attribute）を解決して、強く型付けされた設定クラスを扱う

このとき、ターゲットの参照アセンブリが PC に入っていない、またはプロジェクトが System.Configuration 系を参照できていない、あるいはVS2022 が使う設計時コンポーネント（SDK/ランタイム）が欠けていると、Designer だけが先に失敗して「型が見つからない」という形で止まります。

特に ApplicationScopedSettingAttribute は Settings 周りの生成コードに頻出します。例えば、Settings.Designer.cs には次のような属性が自動生成されます。

[global::System.Configuration.ApplicationScopedSettingAttribute()]

[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]

[global::System.Configuration.DefaultSettingValueAttribute(“…”)] public string SomeSetting { get { return ((string)(this[“SomeSetting”])); } }

この属性が解決できない＝System.Configuration 周辺の型情報が設計時に参照できていない、というのが今回の問題の中心です。

最短で直すための全体像（先にゴールを共有）

対処は闇雲に試すより、上から順に “不足・不整合” を潰していくのが最短です。以下の表は、よくある原因と手当てを対応づけたものです。

原因カテゴリ	ありがちな状態	やること（要点）
ターゲットフレームワーク不整合	net48 のはずが別ターゲットになっている／マルチターゲットでDesignerが想定外を選ぶ	Target Framework を確認し、意図したターゲットに揃える
VSキャッシュ／生成物の破損	VS2022移行直後から Designer だけ不安定	bin/obj/.vs を削除→クリーン→リビルド
System.Configuration 参照不足	.NET（Core/5+）で System.Configuration 系が不足	NuGet「System.Configuration.ConfigurationManager」追加などで補う
SDK/ランタイム/ターゲットパック不足	.NET Framework の Developer Pack が入っていない／Desktop workload不足	Visual Studio Installer で不足コンポーネントを追加

手順：上から順に切り分ける（おすすめの進め方）

ターゲットフレームワークを確認・修正する

まず最初にやるべきことは、プロジェクトが何をターゲットにしているかを明確にすることです。VS2019 → VS2022 の移行時に、ターゲットが意図せず変わったり、環境側の参照が揃っていなかったりすると、Designer が型解決に失敗します。

ソリューションエクスプローラーでプロジェクトを右クリック → プロパティ
ターゲットフレームワーク（Target Framework）が期待どおりか確認

さらに確実にするなら、csproj を直接開いて確認します。見分けの目安は次のとおりです。

csproj の記述	よくある意味	Designer エラーとの関係
`<TargetFrameworkVersion>v4.8</TargetFrameworkVersion>`	古い形式の .NET Framework プロジェクト	該当 .NET Framework の参照アセンブリ（Developer Pack/Targeting Pack）が不足すると壊れやすい
`<TargetFramework>net48</TargetFramework>`	SDKスタイルだが .NET Framework ターゲット	同様に Targeting Pack が必要。VSのワークロード不足でも詰まることがある
`<TargetFramework>net6.0-windows</TargetFramework>` 等	.NET（Core/5+）の Windows 向け	System.Configuration は既定で揃わないことがあり、NuGet 追加が必要になるケースがある
`<TargetFrameworks>...;...</TargetFrameworks>`	マルチターゲット	Designer が先頭ターゲットを使って失敗することがある（設計時のターゲットを見直す）

ここでのポイントは「プロジェクトが要求しているターゲット」と「開発PCに入っている参照一式」が一致していることです。VS2022 は入っているだけで全ターゲットの参照が揃うわけではないため、次のステップで不足を潰します。

ビルド成果物と VS キャッシュを消して作り直す

移行直後や、NuGet・参照の入れ替えをした直後に Designer が壊れた場合、古い生成物やキャッシュが原因になっていることがよくあります。特に Designer は “設計時専用のビルド結果” を持っているため、通常のビルドが通っても Designer だけが古い状態を掴んで失敗することがあります。

Visual Studio の [ビルド] → [ソリューションのクリーン]
ソリューション直下（各プロジェクト配下）の bin / obj を削除
可能ならソリューション直下の隠しフォルダー .vs も削除（VSのキャッシュ）
VS を再起動 → リビルド → Designer を再度開く

どれを消すべきか迷う場合は、次の表を目安にしてください。

削除対象	役割	消してよいか	効果が出やすい症状
bin	ビルド成果物（実行ファイルやDLL）	再生成されるので削除OK	古いDLLをDesignerが掴む、参照が更新されない
obj	中間生成物（生成コードや一時ファイル）	再生成されるので削除OK	Designerだけ型解決が古い、生成コードが壊れている
.vs	VSのキャッシュ（IntelliSense/Designer関連含む）	削除OK（再作成される）	移行後から急にDesignerが不安定、謎の設計時エラーが残る

この手順は地味ですが、「参照を直したのに直らない」状況の最後の一押しになることが多いです。

不足している System.Configuration 系の参照を追加する

エラーメッセージが示すとおり、設計時に System.Configuration.ApplicationScopedSettingAttribute が解決できていません。ここで重要なのは、プロジェクトの種類によって「足すべきもの」が変わる点です。

.NET（Core/5+：例 net6.0-windows / net8.0-windows など）の場合

.NET（Core/5+）では、.NET Framework 時代の System.Configuration 周りが既定で全て揃わないことがあります。そのため、Settings や Configuration を使うプロジェクトでは、NuGet パッケージで補うのが定番です。

NuGet で System.Configuration.ConfigurationManager を追加
追加後、パッケージの復元が成功しているか確認

csproj に入る形の例（PackageReference の場合）は次のようになります（バージョンはプロジェクトのターゲットや社内ルールに合わせて選んでください）。

<ItemGroup>
  <PackageReference Include="System.Configuration.ConfigurationManager" Version="（選択したバージョン）" />
</ItemGroup>

ここで詰まる場合は、Designer の問題というよりもNuGet 復元が失敗していることが多いです。VS の「出力」ウィンドウを NuGet に切り替え、復元エラー（ネットワーク、社内プロキシ、パッケージソース、認証）を先に潰してください。

.NET Framework の場合

.NET Framework プロジェクトでも、プロジェクト構成によっては System.Configuration 参照が外れている／壊れていることがあります（特にプロジェクトの移行・変換、参照の手整理をした後など）。

参照（References）を右クリック → 参照の追加
フレームワークの一覧から System.Configuration（関連する項目）を追加
再ビルドして Designer を開き直す

ただし、.NET Framework で本当に多いのは「参照の追加」よりも次の手順のターゲットパック不足です。参照を足しても直らない場合は、環境側の不足を疑ってください。

.NET / ターゲットパック（Developer Pack）/ VS ワークロードをインストールする

Designer は「実行できるか」よりも「設計時に参照できるか」を重視します。ここでの落とし穴は、ランタイムが入っていても参照アセンブリ（ターゲットパック）が無いと設計時に詰むことがある点です。

導入すべきものはターゲットで変わるため、次の表で整理すると迷いにくいです。

あなたのプロジェクト	開発PC側で不足しやすいもの	入れ方の例	不足すると出やすい症状
.NET Framework 4.x	.NET Framework Developer Pack / Targeting Pack	Visual Studio Installer → 個別のコンポーネントで該当バージョンのターゲットパックを追加	Designer だけ「型が見つからない」「参照アセンブリが無い」系で停止
.NET（Core/5+）Windows（WinForms/WPF）	.NET SDK / Windows Desktop 関連ワークロード	Visual Studio Installer → ワークロード「.NET デスクトップ開発」等を追加	フォームDesignerが開かない、設計時ビルドが失敗
混在（マルチターゲット、古い設定資産あり）	複数のSDK/ターゲットパックの組み合わせ不足	プロジェクトが要求するターゲットを洗い出して必要分を入れる	特定のマシンだけ再現、特定のDesignerだけ壊れる

.NET（Core/5+）の場合、SDK/ランタイムの状況はターミナルで確認できます。

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

「環境に最新の .NET SDK/ランタイムを追加したら解消した」というケースもあります。これは、VS の設計時処理が利用するコンポーネントが揃い、設計時ビルドが通るようになった可能性が高いです。特に複数ターゲットを扱う開発PCでは、“必要なものが一式揃っている状態”に整えることが重要です。

Settings の生成コードを再生成する（Settings.settings が絡む場合）

エラーが Settings Designer を開くときに必ず出るなら、Settings の生成コード（Settings.Designer.cs）が壊れている、または Custom Tool（生成器）が正常に走っていない可能性もあります。参照やSDKを整えた後でも直らない場合に試す価値があります。

Settings.settings を選択し、プロパティ（F4）で Custom Tool が空になっていないか確認
右クリックで カスタムツールの実行（Run Custom Tool）を実行し、生成をやり直す
生成された Settings.Designer.cs で該当属性の行が異常になっていないか確認

注意点として、生成コードを手編集しているプロジェクトは、再生成で差分が出ることがあります。必要ならファイルをバックアップしてから実施してください。

「ビルドは通るのに Designer だけ落ちる」時の見方

Designer は設計時ビルドを裏で走らせるため、通常のビルドと “使う条件” がズレることがあります。ここを押さえておくと、原因特定が一気に楽になります。

状況	考えやすい原因	優先して見る場所
通常ビルドは成功、Designerだけエラー	設計時ビルド用の参照/キャッシュ不整合	bin/obj/.vs削除、ターゲットパック不足、NuGet復元状況
特定PCだけ再現	そのPCの VS コンポーネントやSDKが不足	Visual Studio Installer の個別コンポーネント、dotnet一覧
Settings Designer だけ落ちる	System.Configuration 系の参照不足、生成コード不整合	System.Configuration.ConfigurationManager 追加、Settings再生成
WinForms Designer だけ落ちる	Windows Desktop workload不足、設計時ロード失敗	VSワークロード、対象コントロール/依存DLL、出力ログ

また、VS の「出力」ウィンドウは強い味方です。Designer を開いた直後に、次をチェックしてください。

出力 → 表示を「ビルド」「NuGet」「デザイナー関連」に切り替え、最初に出ているエラー行を追う
“見つからない” と言われている型が、どのアセンブリにある想定なのかを推測する（System.Configuration 系かどうか）
NuGet 復元が裏で失敗していないか（パッケージソースエラーが出ていないか）

よくある落とし穴（ハマりどころを先回り）

ターゲットの「実行環境」はあるのに「参照アセンブリ」が無い

特に .NET Framework では、Windows に入っているランタイムだけで安心しがちですが、Designer が必要とするのは “開発用の参照アセンブリ一式” です。Developer Pack / Targeting Pack の不足は、まさに今回のような “型が見つからない” に直結します。

マルチターゲットで Designer が想定外のターゲットを選んでいる

例えば net8.0-windows;net48 のように複数ターゲットを持つ場合、Designer の都合で先頭ターゲット寄りに処理が進んで失敗することがあります。Designer を使いたい資産（WinForms/Settings）がどのターゲット前提かを整理し、必要ならターゲット順を見直す、または設計時用の条件を調整するのが有効です。

packages.config 管理の古いプロジェクトで復元が不完全

VS2019 時代のプロジェクトで、NuGet の管理方式が古い（packages.config）場合、VS2022 側の復元や参照解決が噛み合わず、Designer で先に崩れることがあります。復元が怪しい場合は、いったん packages フォルダ周りを含めて整理し、復元を成功させてから Designer を再確認してください。

それでも直らないときの最終手段（確度が高い順）

新規プロジェクトを同じターゲットで作成し、問題のプロジェクトと csproj を見比べる（差分が原因のヒントになる）
フォームや設定ファイルを最小構成で取り出して再現確認する（特定ファイルだけ壊れているか切り分け）
VS2022 を最新の更新状態にしてから再確認（Designer 周りの修正が入ることがある）
拡張機能が影響していそうなら、拡張機能を一時的に無効化して確認
社内標準の開発環境があるなら、別PC（またはクリーン環境）で同じソリューションを開いて差分を洗い出す

ここまでやっても再現し続ける場合は、エラーが出る瞬間の「出力」ログ（最初のエラー行）を手がかりに、欠けている参照やパッケージに当たりをつけるのが最短ルートです。メッセージが ApplicationScopedSettingAttribute を名指ししている以上、まずは System.Configuration 系の不足・不整合を疑うのが合理的です。

再発防止（チームで VS2019/VS2022 が混在するなら特に重要）

今回のような Designer エラーは、個人PCの環境差で再発しやすいトラブルです。チーム開発では次の対策が効きます。

対策	狙い	具体例
前提環境を明文化	「誰かだけ起きる」を減らす	README に必要な VS ワークロード、.NET SDK、.NET Framework Developer Pack を記載
SDKバージョンを揃える	設計時ビルド差を減らす	必要なら global.json で .NET SDK を固定（.NETプロジェクトの場合）
Settings/生成コードは手編集しない運用	生成の再現性を上げる	Settings.Designer.cs の手編集を禁止し、差分が出たら原因を潰す

まとめ

VS2019 のプロジェクトを VS2022 で開いたときに Designer で「System.Configuration.ApplicationScopedSettingAttribute が見つからない」エラーが出る場合、ほとんどはターゲットの参照一式（ターゲットパック/SDK/ランタイム）や System.Configuration 系の参照が不足・不整合になっていることが原因です。

まずはターゲットフレームワークを確認し、bin/obj/.vs の削除→再ビルドでキャッシュをリセット。そのうえで、.NET（Core/5+）なら System.Configuration.ConfigurationManager の追加、.NET Framework ならDeveloper Pack/Targeting Pack の導入を疑い、環境とプロジェクトの参照を揃えるのが最短の解決策になります。

この記事を書いた人

佐藤健司

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

VS2022でDesignerが開けない「System.Configuration.ApplicationScopedSettingAttribute が見つからない」原因と解決策（VS2019移行）

起きている現象（症状）

なぜ VS2022 で起きやすいのか（原因の本質）

最短で直すための全体像（先にゴールを共有）

手順：上から順に切り分ける（おすすめの進め方）

ターゲットフレームワークを確認・修正する

ビルド成果物と VS キャッシュを消して作り直す

不足している System.Configuration 系の参照を追加する

.NET（Core/5+：例 net6.0-windows / net8.0-windows など）の場合

.NET Framework の場合

.NET / ターゲットパック（Developer Pack）/ VS ワークロードをインストールする

Settings の生成コードを再生成する（Settings.settings が絡む場合）

「ビルドは通るのに Designer だけ落ちる」時の見方

よくある落とし穴（ハマりどころを先回り）

ターゲットの「実行環境」はあるのに「参照アセンブリ」が無い

マルチターゲットで Designer が想定外のターゲットを選んでいる

packages.config 管理の古いプロジェクトで復元が不完全

それでも直らないときの最終手段（確度が高い順）

再発防止（チームで VS2019/VS2022 が混在するなら特に重要）

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

VS2022でDesignerが開けない「System.Configuration.ApplicationScopedSettingAttribute が見つからない」原因と解決策（VS2019移行）

起きている現象（症状）

なぜ VS2022 で起きやすいのか（原因の本質）

最短で直すための全体像（先にゴールを共有）

手順：上から順に切り分ける（おすすめの進め方）

ターゲットフレームワークを確認・修正する

ビルド成果物と VS キャッシュを消して作り直す

不足している System.Configuration 系の参照を追加する

.NET（Core/5+：例 net6.0-windows / net8.0-windows など）の場合

.NET Framework の場合

.NET / ターゲットパック（Developer Pack）/ VS ワークロードをインストールする

Settings の生成コードを再生成する（Settings.settings が絡む場合）

「ビルドは通るのに Designer だけ落ちる」時の見方

よくある落とし穴（ハマりどころを先回り）

ターゲットの「実行環境」はあるのに「参照アセンブリ」が無い

マルチターゲットで Designer が想定外のターゲットを選んでいる

packages.config 管理の古いプロジェクトで復元が不完全

それでも直らないときの最終手段（確度が高い順）

再発防止（チームで VS2019/VS2022 が混在するなら特に重要）

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル