Windows .rc（リソーススクリプト）編集完全ガイド｜CEF shared.rcをVisual Studioで正しく開く方法

Windowsアプリのアイコンやバージョン情報は、.rc（Windows リソーススクリプト）に集約されます。ところが CEF の shared.rc を触ろうとすると、Visual Studio でプロパティ画面が空になったり、リソースビューで見える内容が想定と違うなど、編集の入口でつまずきがちです。この記事では、.rc の正体から、CEFプロジェクトで正しく開く手順、#include の扱い、BINARYリソースの編集導線までを、実務目線で整理します。

.rc（Windows リソーススクリプト）とは何か

.rc は Windows の「Resource Script（リソーススクリプト）」です。ダイアログ、メニュー、文字列テーブル、バージョン情報（VERSIONINFO）、アイコン、マニフェストなど、実行ファイル（.exe）やDLLに埋め込む「リソース」を定義するためのテキストファイルです。

ビルド時は概ね次の流れで扱われます。

.rc（テキスト）を リソースコンパイラ（rc.exe） が読み取る
.res（バイナリ）を生成する
リンク時に .res が .exe/.dll に取り込まれる

.rcで扱える代表的なリソース（何を編集するファイルなのかが一目で分かる表）

種類	.rc上の記述例（概念）	主な用途	Visual Studioでの編集
ICON / ICON GROUP	`IDI_APP_ICON ICON "app.ico"`	アプリのアイコン	GUIで差し替え可（ただし.ico自体は外部ファイル）
VERSIONINFO	`VS_VERSION_INFO VERSIONINFO ...`	ファイルの詳細（FileVersion / ProductName 等）	Version Information Editor（GUI）で編集しやすい
STRINGTABLE	`STRINGTABLE ...`	メッセージやUI文字列	GUIでもテキストでも可能（文字化け注意）
DIALOG	`IDD_ABOUT DIALOGEX ...`	ダイアログUI	Resource Editor（GUI）が便利
MENU	`IDR_MAINMENU MENU ...`	メニュー構成	GUIが便利
MANIFEST	`CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST ...`	UAC、DPI、互換性など	基本はテキスト編集（XML）
RCDATA / BINARY	`IDR_DATA RCDATA "data.bin"`	任意バイナリの埋め込み	「Open Binary Data」導線で中身確認/差し替え

.rc は「何の言語」？C/C++との違いと共通点

.rc は C/C++ そのものではありません。Windows Resource Script という専用の記述形式です。ただし、次の点で「Cっぽさ」が出ます。

プリプロセッサディレクティブが使える（#include / #define / #ifdef など）
リソースIDや定数を ヘッダファイル（resource.h 等）から取り込む運用が一般的

つまり、.rc は「UI部品やメタ情報を定義するスクリプト」であり、C/C++のソースと同じように #include を使って構成を分割したり、マクロで条件分岐したりできます。CEFの shared.rc がまさにこの形で、バージョン文字列や識別子をヘッダから取り込んでいるケースがあります。

編集は用途で使い分ける：おすすめIDE・エディタと選び方

.rc はテキストファイルなので、極論どのエディタでも編集できます。ただ、「GUIで触った方が速い場所」と「テキストで触った方が安全な場所」が混在します。編集目的別に、現実的な選択肢をまとめます。

目的別のおすすめ（迷ったらこの表どおりでOK）

やりたいこと	おすすめ	理由	注意点
`#include`・`#define`・パス修正など軽い修正	Visual Studio Code / Visual Studio / 任意テキストエディタ	差分が見やすく、手早い	文字コード（UTF-8/CP932）を揃える
VERSIONINFO（ファイルの詳細）を整えたい	Visual Studio の Resource Editor	項目ごとに入力でき、ミスが減る	数値の `FILEVERSION` と文字列の `"FileVersion"` を両方整合させる
ダイアログやメニューを作りたい	Visual Studio の Resource Editor	配置・整列が速い	自動整形で .rc の見た目が変わることがある
RCDATA/BINARY を埋め込みたい・中身を確認したい	Visual Studio（Open Binary Data）＋必要なら外部バイナリエディタ	追加と参照はVSが簡単	VS単体で「高度なバイナリ編集」までやるより、外部ツール併用が現実的
既存EXEのリソースを解析・差し替え（自社成果物の検証）	専用ツール（例：リソース閲覧/編集ツール）	ビルドなしで確認できる	配布物を後から書き換える運用は、再現性とセキュリティの観点で要注意

結論として、CEFの shared.rc を「壊さずに」触りたいなら、基本はVisual Studioのリソースエディタ（Resource View）が最も安全です。テキスト編集は“局所的な修正”に留めるとトラブルが減ります。

CEF の `shared.rc` を Visual Studio で正しく編集する手順

CEFのサンプル構成（cef-projectなど）では、shared.rc が存在していても、Visual Studioのプロジェクトに含まれていない状態だと、リソースビューが空に見えたり、想定したエディタが開かなかったりします。ポイントは「ソリューション生成」と「.rcをプロジェクトに含める」です。

前提：Visual Studio に C++ 関連コンポーネントが入っているか確認

リソースエディタは、Visual Studio に C++ 開発環境が揃っていないと期待どおりに動きません。次の状態だと「Resource View が出ない／空」「Open With に Resource Editor がない」などが起きやすいです。

Visual Studio のインストールで「デスクトップ開発（C++）」相当が入っていない
Windows SDK が不足していて rc.exe 周りが欠けている

まずは Visual Studio Installer で C++ 開発が有効になっているかを確認してください（ここが抜けていると、後述のチェックをしても改善しないことがあります）。

手順：CMakeで Visual Studio ソリューション（例：`cef.sln`）を生成する

質問文の流れに合わせると、開発者コマンドプロンプトでプロジェクトルートに移動し、cmake . で生成します。近年はビルドディレクトリを分ける形が定番なので、両方載せておきます。

ルート直下に生成する場合（シンプル）

cd path\to\cef-project
cmake .

ビルドディレクトリに生成する場合（おすすめ・クリーン運用向き）

cd path\to\cef-project
cmake -S . -B build
cmake --build build --config Debug

生成されたソリューション（例：cef.sln または build\cef.sln）を Visual Studio で開きます。

手順：`shared` プロジェクトに `shared.rc` と関連ファイルを含める

CEFの構成によっては、examples 配下に shared プロジェクトがあり、その中の Windows 用フォルダ（例：examples/shared/win）に shared.rc が置かれています。

ここが重要で、ファイルがディスクに存在するだけでは不十分です。Visual Studio のリソースビューは「プロジェクトに含まれるリソース」を基準に表示するため、次の操作を行います。

ソリューションエクスプローラーで shared プロジェクトを選択
プロジェクトを右クリック → 追加 → 既存の項目
examples/shared/win フォルダ内の shared.rc と、関連ヘッダ（例：resource.h、リソースID定義ヘッダ等）を追加

追加後、.rc ファイルの種類が正しく認識されていれば、ビルド時に「Resource Compile」相当として扱われます。

手順：Resource View（リソースビュー）から開く

Visual Studio のメニューから 表示 → その他のウィンドウ → リソースビュー（環境によって表記差あり）を開き、該当プロジェクト配下のリソースを展開します。shared.rc を開く導線は主に2つです。

Resource View から開く（GUI編集の前提が整いやすい）
ソリューションエクスプローラーで .rc を右クリック → プログラムから開く（Open With） → Resource Editor を選ぶ

「左は .rc のテキスト、右は VERSIONINFO の画面」になる理由

これは別物ではなく同じ .rc の一部をGUI表示しているだけです。典型例が VS_VERSION_INFO（VERSIONINFO）で、Visual Studio はこれを「Version Information Editor」として部品単位で見せます。編集内容は .rc の該当ブロックに反映され、最終的に rc.exe がそれをコンパイルします。

Visual Studio の「プロパティ画面が空」「リソースビューが想定と違う」ときの原因切り分け

CEFの shared.rc 編集で起きがちな症状を、再現性の高い順にチェックできるようにまとめます。どれも「いま何が足りていないか」が分かれば、解決は早いです。

症状	よくある原因	確認ポイント	対処
Resource View が空／何も表示されない	.rc がプロジェクトに含まれていない	ソリューションエクスプローラーに `shared.rc` が存在するか	「既存の項目」として追加し、プロジェクト配下に入れる
.rc を開いてもテキストエディタでしか開かれない	Resource Editor が入っていない／C++ワークロード不足	「Open With」に Resource Editor が出るか	Visual Studio Installer で C++ デスクトップ開発と Windows SDK を追加
プロパティウィンドウが空っぽに見える	ファイル種別が違う/選択対象が違う（フィルタやフォルダを見ている）	.rc ファイルそのものを選択しているか	Resource View から該当リソースを選んで編集する
VERSIONINFO の項目が一部しか見えない／期待した表示と違う	`#ifdef` や `#include` を含む構造で、GUIが解釈できる範囲が限定される	.rc先頭の `TEXTINCLUDE` や条件分岐の有無	必要ならテキストで確認し、GUIは編集に強い部分だけ使う
ビルドで rc.exe の include エラーが出る	Resource Compile のインクルードパスが不足	エラーログに出るヘッダがどこにあるか	プロジェクトの「リソース」設定で include 追加、CMakeならターゲットの include を見直す
編集はできるのに実行ファイルに反映されない	別の .rc がリンクされている／対象プロジェクトが違う	どのターゲット（exe）をビルドしているか	exeのターゲットに .rc が含まれているか確認

特に最初の「.rc がプロジェクトに含まれていない」は、CEF系でよくある落とし穴です。ディスク上に見えていても、Visual Studio が「リソースとして扱う対象」になっていないと、Resource View の表示がズレます。

`#include` 行はどうやって作られる？「生成」と「追記」の現実

#include "windows.h" や #include "include/cef_version.h" のような行は、次のどれかで増えます。

最初のテンプレート（Visual Studioのプロジェクト作成時に雛形として入る）
人が手で追記（CEFが必要とするバージョン情報やマクロ参照など）
Visual Studio の操作で間接的に追記される（リソース追加でID定義が増え、結果として include が必要になる）

重要なのは、リソースエディタが常に #include 行を自動生成するわけではない点です。特に CEF の shared.rc のように、外部ヘッダからバージョン文字列や定数を取り込む設計は、基本的にリポジトリ側の意図として書かれています。

Visual Studioが自動的に触りやすい場所／触りにくい場所

Visual Studioは、次のような“管理領域”を持つことがあります（ファイル先頭の TEXTINCLUDE など）。ここはIDEが状態管理に使うことがあり、無理に整形し直すと差分が大きくなりがちです。

APSTUDIO_READONLY_SYMBOLS などのブロック
TEXTINCLUDE のセクション（IDEが参照するための情報）

実務でおすすめなのは、手で触る部分を別ファイルに逃がす運用です。例えば shared.rc の末尾で #include "shared_custom.rc2" のように分けておくと、IDEの自動整形と手動編集が衝突しにくく、更新時のマージも楽になります。

VERSIONINFOを編集する際に押さえるべき「整合性」

VERSIONINFOは、数値版と文字列版の両方が存在し、食い違いが起きやすいポイントです。GUIで編集できる分、ミスは減りますが、次の観点は意識すると安定します。

数値版：FILEVERSION / PRODUCTVERSION（例：1,2,3,4）
文字列版：VALUE "FileVersion", "1.2.3.4" など
表示に出るのは主に文字列版だが、インストーラや更新判定で数値版を見るケースもある

CEFのサンプルに手を入れる場合、上流の意図（CEFバージョン表記など）を壊さないように、どの項目をアプリ固有情報として変えるかを決めておくと安全です（例：FileDescriptionやProductNameは自社アプリ名、CEF由来の項目は維持、など）。

バイナリリソース（BINARY / RCDATA）編集で「Binary Editorが見当たらない」問題の解き方

Visual Studioで「Binary Editor」という独立したメニューやツールを探し続けると迷子になりやすいです。BINARY系は、概ね次の導線で扱います。

「追加」と「編集」は別の作業（ここを混同しない）

やること	Visual Studio上の導線	結果として起きること
バイナリをリソースとして追加したい	Resource View → 右クリック → リソースの追加（Add Resource）	.rc に `IDR_XXX RCDATA "path"` などの記述が増える
既存バイナリリソースの中身を開いて確認/差し替えしたい	Resource View で対象を右クリック → Open Binary Data（バイナリデータを開く）	埋め込まれているデータを表示・扱う画面が開く

つまり、探すべきは「Binary Editor」という名前の機能ではなく、Open Binary Data（バイナリデータを開く）です。これが見つからない場合、そもそもリソースエディタ機能が不足している（C++関連コンポーネント不足）可能性もあります。

BINARY と RCDATA の違い（現場では RCDATA が一般的）

.rc では任意バイナリを埋め込めますが、運用としては RCDATA を使うことが多いです。BINARY はカスタムタイプとして扱われることもあり、プロジェクトによっては表示が分かりにくい場合があります。

RCDATA：任意データを載せる用途として一般的で、コード側でも扱い例が多い
BINARY：カスタム型として扱われることがあり、IDEでの見え方が揺れることがある

CEFのように複数プロジェクトで共有する場合、IDEの表示・保守性を考えると、チーム内で「RCDATAに寄せる」「ID命名規則を統一する」などのルールを決めると運用が安定します。

文字化けとビルド事故を避ける：.rc の文字コードとコードページ

.rc編集で地味に効いてくるのが文字コード（コードページ）問題です。リソースコンパイラはソースの文字コードに敏感で、外部エディタで保存形式が変わると、次のようなトラブルが起きます。

日本語の STRINGTABLE が「?」になる／化ける
コンパイル時に想定外の文字として扱われ、エラーになる
Visual Studioで開くと表示は正しいのに、CIや別環境で崩れる

安全策：チームで「保存形式」を固定し、必要ならコードページ指定を使う

実務で取りやすい安全策は次のとおりです。

チームで .rc の保存形式を決め、統一する（例：CP932で統一、またはUTF-8で統一）
UTF-8運用に寄せるなら、必要に応じて #pragma code_page(65001) を検討する
外部エディタを使う場合は、保存時に勝手に文字コード変換しない設定にする

特に CEF のように複数人・複数環境（ローカル/CI）でビルドするプロジェクトでは、「たまたま自分のPCだけ通る」状態が一番危険です。文字列テーブルを触る場合は、差分レビュー時に“文字化けがないか”も確認対象に入れると事故が減ります。

「生成するツールはある？」に対する現実的な答え

.rc を完全自動で生成する“万能ツール”というより、現場では次のどれかが主流です。

Visual Studio のプロジェクト作成時に雛形が生成され、それを育てていく
既存の .rc をベースに必要なリソースを追加していく
ビルドシステム側（CMake等）で一部だけテンプレート生成する（バージョン文字列や製品名など）

CEFの shared.rc に関しては、すでに“プロジェクトに必要な形”ができているケースが多く、むしろ大事なのは正しく開けるように整えることです。生成よりも、

プロジェクトに含める（Resource Viewに出す）
必要なincludeパスが通っているか確認する
変更が上流更新で消えないように管理する

この3点に集中した方が、結果的に早く安定します。

CEFプロジェクトでの変更が「消える／ずれる」を防ぐ運用のコツ

CEFやChromium系は更新頻度が高く、上流からの取り込みでローカル変更が衝突しやすいです。shared.rc をいじるときは、次のような“変更の置き場”を意識すると、後々のメンテが楽になります。

アイコン差し替えで品質が落ちるのを防ぐ

アイコンは差し替え自体は簡単ですが、.ico の中に複数サイズが入っていないと、Windowsが拡大縮小してぼやけます。最低限、次のサイズを含めると見た目が安定します。

16×16 / 32×32 / 48×48（従来の表示で必須）
256×256（高DPIや一部UIで効く）

最後に：変更が反映されたかを確かめるチェック手順

.rc は「編集できた」だけでは終わりません。実行ファイルに反映されているかを短時間で確認する手順を用意しておくと、切り戻しや不具合調査が一気に楽になります。

Explorerで確認（最短）

生成された .exe を右クリック → プロパティ
「詳細」タブで ProductName / FileVersion / FileDescription などを見る
アイコンはエクスプローラーやタスクバー表示で確認する

PowerShellで確認（自動化・CIで便利）

(Get-Item ".\YourApp.exe").VersionInfo | Format-List *

ここで意図した値になっていなければ、次を疑うのが近道です。

編集した .rc がその exe のターゲットに本当に含まれているか
別プロジェクト（別ターゲット）を見ていないか
Release/Debug など構成違いで出力先が別になっていないか

まとめ：CEF の `shared.rc` 編集で迷わないための要点

.rc は Windows の Resource Script。rc.exe で .res にコンパイルされ、exe/dll に埋め込まれる
軽い修正はテキストでOK。VERSIONINFOやダイアログは Visual Studio の Resource Editor が強い
CEFでリソースビューが空なら、まず .rc がプロジェクトに含まれているか（既存の項目として追加）を確認する
#include 行は“自動生成が前提”ではない。必要に応じて手で追記し、保守しやすい分割（rc2など）を検討する
BINARY編集は「Binary Editorを探す」より、Open Binary Data が導線になる
文字コードは統一が正義。String Table を触るなら特に注意する

この記事を書いた人

佐藤健司

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

Windows .rc（リソーススクリプト）編集完全ガイド｜CEF shared.rcをVisual Studioで正しく開く方法

.rc（Windows リソーススクリプト）とは何か

.rcで扱える代表的なリソース（何を編集するファイルなのかが一目で分かる表）

.rc は「何の言語」？C/C++との違いと共通点

編集は用途で使い分ける：おすすめIDE・エディタと選び方

目的別のおすすめ（迷ったらこの表どおりでOK）

CEF の `shared.rc` を Visual Studio で正しく編集する手順

前提：Visual Studio に C++ 関連コンポーネントが入っているか確認

手順：CMakeで Visual Studio ソリューション（例：`cef.sln`）を生成する

手順：`shared` プロジェクトに `shared.rc` と関連ファイルを含める

手順：Resource View（リソースビュー）から開く

「左は .rc のテキスト、右は VERSIONINFO の画面」になる理由

Visual Studio の「プロパティ画面が空」「リソースビューが想定と違う」ときの原因切り分け

`#include` 行はどうやって作られる？「生成」と「追記」の現実

Visual Studioが自動的に触りやすい場所／触りにくい場所

VERSIONINFOを編集する際に押さえるべき「整合性」

バイナリリソース（BINARY / RCDATA）編集で「Binary Editorが見当たらない」問題の解き方

「追加」と「編集」は別の作業（ここを混同しない）

BINARY と RCDATA の違い（現場では RCDATA が一般的）

文字化けとビルド事故を避ける：.rc の文字コードとコードページ

安全策：チームで「保存形式」を固定し、必要ならコードページ指定を使う

「生成するツールはある？」に対する現実的な答え

CEFプロジェクトでの変更が「消える／ずれる」を防ぐ運用のコツ

おすすめの考え方

アイコン差し替えで品質が落ちるのを防ぐ

最後に：変更が反映されたかを確かめるチェック手順

Explorerで確認（最短）

PowerShellで確認（自動化・CIで便利）

まとめ：CEF の `shared.rc` 編集で迷わないための要点

この記事を書いた人

コメント

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

Windows .rc（リソーススクリプト）編集完全ガイド｜CEF shared.rcをVisual Studioで正しく開く方法

.rc（Windows リソース スクリプト）とは何か

.rcで扱える代表的なリソース（何を編集するファイルなのかが一目で分かる表）

.rc は「何の言語」？C/C++との違いと共通点

編集は用途で使い分ける：おすすめIDE・エディタと選び方

目的別のおすすめ（迷ったらこの表どおりでOK）

CEF の shared.rc を Visual Studio で正しく編集する手順

前提：Visual Studio に C++ 関連コンポーネントが入っているか確認

手順：CMakeで Visual Studio ソリューション（例：cef.sln）を生成する

手順：shared プロジェクトに shared.rc と関連ファイルを含める

手順：Resource View（リソースビュー）から開く

「左は .rc のテキスト、右は VERSIONINFO の画面」になる理由

Visual Studio の「プロパティ画面が空」「リソースビューが想定と違う」ときの原因切り分け

#include 行はどうやって作られる？「生成」と「追記」の現実

Visual Studioが自動的に触りやすい場所／触りにくい場所

VERSIONINFOを編集する際に押さえるべき「整合性」

バイナリリソース（BINARY / RCDATA）編集で「Binary Editorが見当たらない」問題の解き方

「追加」と「編集」は別の作業（ここを混同しない）

BINARY と RCDATA の違い（現場では RCDATA が一般的）

文字化けとビルド事故を避ける：.rc の文字コードとコードページ

安全策：チームで「保存形式」を固定し、必要ならコードページ指定を使う

「生成するツールはある？」に対する現実的な答え

CEFプロジェクトでの変更が「消える／ずれる」を防ぐ運用のコツ

おすすめの考え方

アイコン差し替えで品質が落ちるのを防ぐ

最後に：変更が反映されたかを確かめるチェック手順

Explorerで確認（最短）

PowerShellで確認（自動化・CIで便利）

まとめ：CEF の shared.rc 編集で迷わないための要点

この記事を書いた人

関連記事

コメント

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

.rc（Windows リソーススクリプト）とは何か

CEF の `shared.rc` を Visual Studio で正しく編集する手順

手順：CMakeで Visual Studio ソリューション（例：`cef.sln`）を生成する

手順：`shared` プロジェクトに `shared.rc` と関連ファイルを含める

`#include` 行はどうやって作られる？「生成」と「追記」の現実

まとめ：CEF の `shared.rc` 編集で迷わないための要点

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