Visual Studio 2022 で .resx を開くと、いつの間にか「新しいリソース管理（Resource Explorer）」になっていて、png のドラッグ＆ドロップが弾かれたり、Resources.Designer.cs が壊れてビルドできなくなったり…。以前の操作感に戻すための回避策と、安全に運用するポイントをまとめます。
Visual Studio 2022 の「新しいリソース管理（Resource Explorer）」で何が変わったのか
.NET の Windows アプリ（WinForms / WPF など）やクラスライブラリでは、文字列・画像・バイナリなどを .resx（XML 形式のリソースファイル）にまとめ、ビルド時にアセンブリへ埋め込んで利用することがよくあります。
これまでは Visual Studio の Managed Resources Editor（従来のリソースエディタ）で .resx を開き、表形式の画面に対して「行を追加」「ファイルをドラッグ＆ドロップ」といった直感的な操作でリソースを登録できました。
一方、Visual Studio 2022 の一部バージョンでは .resx を開く体験が変わり、Resource Explorer（新しいリソース管理 UI）として表示されるようになっています。狙いとしては検索や整理の強化が想像できますが、現状は「以前できていたことがやりにくい」「壊れる挙動がある」といった不満が目立ち、特に画像リソースを扱う現場で困りやすい状況です。
報告が多い不具合・使い勝手の悪化：まずは症状を整理
新しい Resource Explorer を使い始めてから、代表的に次のような困りごとが報告されています。
| 症状（何が起きるか） | 困るポイント | 現場での影響例 |
|---|---|---|
| .resx に png を追加しようとすると「icon か byte[] でないといけない」と言われる | 従来の「画像として登録」ができず、手戻りが増える | UI 用のボタン画像を追加できず、実装作業が止まる |
| ドラッグ＆ドロップで自動登録されなくなった | 「追加→種類選択→設定…」のように操作が増え、ミスも増える | 大量の画像を一括追加したい時に時間がかかる |
| UI／動作が分かりづらく、一覧が“ごちゃごちゃ”して見える | チーム内で操作の共通理解が作りにくい | レビューや引き継ぎで「どこを見ればいいか」が説明しづらい |
| 検索するとヒットした項目しか表示されず、全体の中での位置が分からない | 似たキー名の確認や、周辺の関連リソースを辿りにくい | 誤って別キーを編集し、リソースの整合性が崩れる |
| 行を選んで Ctrl+C → Ctrl+V したら、リソース行ではなく「リソースファイル自体」が複製された | 意図しないファイル増殖や、ビルド対象の混乱につながる | Properties に Resources.resx が複数でき、参照先が分からなくなる |
| 操作後に Resources.Designer.cs が削除された／関連が切れてコンパイルエラーになった | ビルド不能という致命的障害。原因特定にも時間がかかる | CI が落ちる、リリース前の修正が止まる |
| .md のような単純なファイル追加ができない、右クリックから「従来の Managed Resources Editor」を開くメニューが消えた | “逃げ道”が見当たらず、作業が詰まりやすい | 新 UI を強制され、旧来ワークフローが使えない |
特に重要なのは、最後の「Resources.Designer.cs が壊れる」系です。単に不便なだけでなく、プロジェクト全体がコンパイルできなくなるため、リソース編集は地味に見えても高リスク作業になり得ます。
そもそも Resources.Designer.cs は何をしているのか（壊れると何が起きる？）
Visual Studio のリソース機構は、.resx の内容をビルドに取り込みつつ、C# から扱いやすいように 強く型付けされたアクセサ（自動生成コード）を作ってくれます。その代表が Resources.Designer.cs です。
たとえば Properties.Resources.MyIcon のように書けるのは、Resources.Designer.cs が「MyIcon というプロパティを持つクラス」を生成しているからです。これが消えたり、.resx との関連が切れたりすると、次のような問題が起こります。
- コンパイルエラー：
Properties.Resourcesが見つからない、プロパティが存在しない、など - 実行時エラー／リソース取得失敗：リソースが埋め込まれていない、キー名が一致しない、など
- 修正が難しい：原因が「リソース編集のどの操作か」になりやすく、再現も取りづらい
ポイントは、Resources.Designer.cs は手で編集してはいけないファイルで、基本は 自動生成（Custom Tool）に任せるものだということです。つまり、壊れたときは「再生成できる状態を取り戻す」ことが最短になります。
現時点で一番実用的な対処：Managed Resources Editor（Legacy）に戻す
新しい Resource Explorer 側で「以前と同じ感覚」を完全に再現する設定が見つかっていない／提示されていないケースが多い一方で、従来の Managed Resources Editor（Legacy）を使えば従来通りに作業できる、というのが現場でのもっとも現実的なワークアラウンドです。
従来エディタで .resx を開く手順（Open With… で既定にする）
- ソリューション エクスプローラーで対象の .resx ファイルを右クリック
- Open With…（別のプログラムで開く…） を選択
- 一覧から Managed Resources Editor (Legacy) を選ぶ
- Set as Default（既定に設定） を押しておく（次回以降の二重クリックもレガシーで開く）
この状態で .resx を開き、従来通りに次の操作ができます。
- .resx の表画面へ png をドラッグ＆ドロップして画像リソースとして追加
- キー名を編集して整理（例：
Img_ButtonSaveのように規則化） - 行単位のコピー＆ペーストで複製（ファイル自体の複製になりにくい）
| やりたいこと | 推奨する操作 | コツ |
|---|---|---|
| png を素早く追加したい | Legacy で .resx を開き、D&D | 複数ファイルをまとめて D&D すると効率が良い |
| 同じ画像の別バージョンを登録したい | 行をコピーしてキー名だけ変更 | キー命名規則を決めておくと検索性が上がる |
| 誤操作が怖い | 編集前に Git でコミット（または作業ブランチ作成） | 差分で .resx と Designer の両方を確認する |
結論としては「新しい Resource Explorer を使わず、レガシーに戻す」のが、今日から取れる対策として最も費用対効果が高いです。
レガシーに戻せない／メニューが見当たらないときの代替ルート
環境や Visual Studio の更新状況によっては、右クリックメニューからレガシーが見当たらない、または項目名が分かりづらい場合があります。その場合でも、次の手順で「レガシーで開く」ルートに辿れることがあります。
- Open With… の一覧をスクロールして探す：名前に “Legacy” が付いていることが多い
- XML（Text）として開いて確認する：最終手段として .resx をテキストで編集し、あとで Custom Tool で再生成する
- プロジェクトの種類を確認する：SDK スタイル（.NET 6+）か .NET Framework かで生成周りが異なる場合がある
「どうしても表示されない」場合は、まずは Visual Studio を最新の更新にして改善していないか、または 別 PC では出るかを確認すると切り分けが早くなります。チーム開発なら「出る人／出ない人」がいるだけで運用が崩れやすいため、早めの共通化が重要です。
新しい Resource Explorer を使う必要がある場合の“壊さない”チェックリスト
事情があって新しい Resource Explorer を使わざるを得ない場合は、編集前後に必ず整合性チェックを入れて、被害を最小化する運用が現実的です。
編集前：最低限やっておきたいこと
- コミット or バックアップ：.resx と Resources.Designer.cs はセットで差分を見る
- 対象ファイルのプロパティ確認：Build Action が Embedded Resource になっているか
- 作業ブランチで試す：壊れたときに戻せる前提を作る
編集後：コンパイルまで含めて確認する
- Resources.Designer.cs が残っているか（勝手に削除されていないか）
- ビルドが通るか（ローカルで Rebuild まで実施）
- Resources 参照が生きているか（代表的なキーを 1 つ参照して動作確認）
| チェック項目 | 確認場所 | よくある落とし穴 |
|---|---|---|
| Resources.Designer.cs の生成設定（Custom Tool） | .resx を選択 → プロパティ | Custom Tool が空になり、再生成されなくなる |
| Build Action | .resx を選択 → プロパティ | None になっていて埋め込まれず、実行時に取得できない |
| リソースキーの命名 | .resx の一覧 | キー重複や、似たキーの上書きで想定外の画像が表示される |
| チーム内の Visual Studio バージョン差 | 開発端末ごとの状況 | 同じ .resx を編集しても UI・挙動が違い、差分が読みづらい |
Resources.Designer.cs が消えた／関連が切れてビルドできないときの復旧手順
「突然ビルドエラーになった」「Resources クラスが見つからない」といった場合は、焦って手編集するよりも、まずは自動生成を復旧させるのが近道です。代表的な復旧の流れをまとめます。
復旧の流れ（典型パターン）
- .resx を選択してプロパティを開く
- Custom Tool に
ResXFileCodeGenerator（またはPublicResXFileCodeGenerator）が入っているか確認する - 空なら正しい値を設定する（プロジェクトの既存 .resx と揃える）
- ソリューション エクスプローラーで .resx を右クリックし、Run Custom Tool（カスタムツールの実行） を行う
- Clean → Rebuild まで実行して、エラーが消えるか確認する
SDK スタイルのプロジェクトでは、Designer が obj 配下で生成されるケースもあります。その場合も基本の発想は同じで、生成設定が外れていないか、ビルドで生成が走っているかを確認します。
それでも直らないときの切り分け
- .resx の XML が壊れていないか：不完全なタグ、エンコーディング、特殊文字など
- リソース名（キー）に不正がないか：空白や記号などで生成に失敗する場合がある
- 同名の Resources クラスが別に存在しないか：名前衝突で参照が崩れる
- partial クラスや名前空間の変更履歴：Custom Tool Namespace のズレで参照先が変わる
png が「icon か byte[]」扱いになるのはなぜ？ Image と byte[] の違いを知っておく
.resx は画像を「Image（例：Bitmap）」として保存できる一方、環境やエディタ側の判断で「バイナリ（byte[]）」として扱うこともあります。新しい Resource Explorer では、この型推論や登録手順が変わっている可能性があり、結果として「png を入れたいだけなのに弾かれる」状況が起きやすくなります。
| 保存形式 | メリット | 注意点 | 向いている場面 |
|---|---|---|---|
| Image（Bitmap 等） | 取り出してすぐ UI に貼れる（WinForms など） | .NET 6+ のクロスプラットフォームでは System.Drawing の制約が話題になりやすい | Windows 専用 UI、既存の WinForms 資産 |
| byte[] | 中身は単なるバイト列。デコード方法を自由に選べる | 利用側で画像に変換するコードが必要 | ライブラリ化、将来の移植性を上げたい場合 |
| Icon | アイコン用途に最適化（.ico） | png をそのまま扱えない | フォームや実行ファイルのアイコン |
「png をリソースに入れる目的」が WinForms のボタン画像なのか、WPF の ImageSource なのか、あるいは単に埋め込みデータとして持ちたいのかで、ベストな形式は変わります。迷ったら、まずは従来通り Image で登録できる Legacy を使うのが安全です。
検索・複製・追加がやりづらいときの“逃げ道”ワークフロー
新しい Resource Explorer の挙動が不安定な間は、作業を止めないために「やり方を複数持つ」ことが有効です。
逃げ道1：Legacy を既定にして、普段はレガシーで作業する
最もおすすめです。チーム内でも「.resx は基本レガシーで開く」と決めておくと、操作説明が一気に楽になります。
逃げ道2：.resx を XML として編集し、Custom Tool で再生成する
大量のキー修正や、機械的な置換をしたい場合に有効です。ただし、画像やバイナリを含む .resx は XML が大きくなりがちで、手編集は事故の元です。必ずバックアップを取ってから実施してください。
逃げ道3：リソースの複製は「行複製が確実な画面」で行う
Ctrl+C / Ctrl+V の意味が UI によって変わると、誤ってファイル複製や上書きを招きます。複製が必要なときは、
- Legacy の表で行をコピーする
- または XML 上でキー名と値を複製する
のように、「何が複製されるか」が明確な方法を選ぶのが安全です。
チーム開発でトラブルを増やさないための運用ルール
.resx は便利な一方、差分が読みづらく、コンフリクトも起きやすいファイルです。新 UI の挙動が揺れている時期は、運用の工夫で事故率を下げられます。
| ルール | 狙い | 具体例 |
|---|---|---|
| キー命名規則を統一する | 検索性とレビュー効率を上げる | Str_ / Img_ / Bin_ など接頭辞を付ける |
| 画像は“まとめて追加→まとめて確認”する | 壊れたときの原因範囲を狭める | 10 枚追加したら一度ビルドして確認 |
| リソース編集はコミット単位を小さくする | ロールバックを簡単にする | UI 変更とリソース追加を同一コミットにしない |
| CI でリソース参照のコンパイルを必ず走らせる | 「ローカルだけ通る」を防ぐ | Pull Request 時に Rebuild を必須化 |
Microsoft へフィードバック（バグ報告・要望）を送るときのコツ
Resource Explorer の改善は、最終的には Visual Studio 側の修正が必要です。報告する際は「困っている」だけでなく、再現手順と影響範囲を具体化すると優先度が上がりやすくなります。
報告に入れておきたい情報
- Visual Studio 2022 のバージョン（例：17.xx）とエディション
- プロジェクト種別（.NET Framework / .NET 6+、WinForms / WPF、SDK スタイルかどうか）
- 対象の .resx の場所（Properties/Resources.resx か、フォームに紐づく .resx か）
- 「png を追加すると icon/byte[] と言われる」など、実際のメッセージと手順
- Resources.Designer.cs が消える／関連が切れる場合は、その直前に行った操作
- 可能なら最小構成の再現プロジェクト（新規作成→数ステップで再現）
送る場所の例
- Visual Studio の Help（ヘルプ）→ Send Feedback（フィードバックの送信）
- Developer Community（既存の類似報告がないか検索して、あれば投票・追加情報を投稿）
「同じ症状の報告が既にある」場合は、新規で乱立させるよりも、既存スレッドに再現条件や追加情報を積む方が修正につながりやすいことが多いです。
よくある質問（現場でハマりやすいポイント）
png を以前のようにドラッグ＆ドロップで入れたい
まずは Managed Resources Editor (Legacy) を既定に設定して、従来 UI で追加するのが最短です。新 UI 側での確実な回避策が確立していない間は、作業効率と安全性の両面でレガシーが優位です。
Resources.Designer.cs が消えました。手で作り直すべき？
手で作り直すのはおすすめしません。基本は .resx の Custom Tool 設定を正し、Run Custom Tool で再生成を狙います。うまくいかない場合は、壊れる直前のコミットへ戻して原因操作を切り分けるのが安全です。
検索すると一覧が消えて迷子になります
「全体の中での位置」を確認しながら作業したいなら、レガシーでの検索（または .resx を XML として開いて検索）が分かりやすいです。検索を多用するチームほど、UI の癖が作業効率に直結します。
画像を .resx に入れるのではなく、ファイルとして置くべき？
WPF では XAML の Resource（Build Action: Resource）として画像を管理する設計も一般的です。一方、WinForms や既存資産では .resx の画像リソースが前提になっていることも多いので、プロジェクトの歴史と利用箇所に合わせて選ぶのが現実的です。迷う場合は「文字列は .resx、画像はプロジェクト内 Resource」といった分離も検討できます。
まとめ：当面はレガシー回帰＋安全運用で“止まらない”開発に
Visual Studio 2022 の新しい Resource Explorer は、現状では png 追加のつまずきや、検索・複製の直感性不足、さらには Resources.Designer.cs 周りの致命的な不具合が疑われる報告もあり、安心して任せづらい面があります。
今すぐできる実務的な結論はシンプルです。
- .resx は Managed Resources Editor (Legacy) を既定にして使う
- リソース編集はコミットを小さくし、編集前後でビルドまで確認する
- 壊れたら Custom Tool 設定と再生成（Run Custom Tool）で復旧を狙う
- 再現条件を整理して Microsoft へフィードバックする
リソースはアプリの“見た目”を支える重要な資産です。編集体験が揺れている時期こそ、手順を固定し、壊れない運用を作っておくと、チーム全体の生産性が安定します。
コメント