いつ、なぜ、Windowsレジストリにデータを保存する必要がありますか？

開発者として、レジストリに構成/オプションを保存するツールは私の人生の悩みの種です。これらのオプションの変更を簡単に追跡することはできず、マシンからマシンに簡単に移植することもできません。そのため、.INIファイルの古き良き時代を本当に切望しています...

独自のアプリケーションを作成する場合、昔ながらの構成ファイルではなくレジストリに置くことを選択する必要があります。

• もともと（WIN3）構成は、windowsディレクトリのWIN.INIファイルに保存されていました。
• 問題：WIN.INIが大きくなりすぎました。
• 解決策（Win31）：プログラムと同じディレクトリにある個別のINIファイル。
• 問題：そのプログラムはネットワーク上にインストールされ、多くの人々によって共有される可能性があります。
• 解決策（Win311）：ユーザーのウィンドウディレクトリにある個別のINIファイル。
• 問題：多くの人がWindowsフォルダを共有している可能性があり、いずれにしてもそれは読み取り専用でなければなりません。
• 解決策（Win95）：ユーザーごとに個別のセクションを持つレジストリ。
• 問題：レジストリが大きくなりすぎました。
• ソリューション（WinXP）：個々のデータの大きなブロックをユーザー自身のアプリケーションデータフォルダーに移動しました。
• 問題：大量のデータには適していますが、少量の場合はかなり複雑です。
• ソリューション（.NET）：アプリケーションと同じフォルダー内の.config（Xml）ファイルに格納された、読み取り専用の少量の固定データ。APIで読み取る。（読み取り/書き込みまたはユーザー固有のデータはレジストリに残ります）

ユーザーの視点とプログラマの視点の両方からこれに来ると、ファイルの関連付けやマシン固有の設定のようなものでない限り、レジストリに何かを入れることは本当に良い言い訳にはならないでしょう。

私は、プログラムはインストールされた場所から実行可能である必要があり、インストールはマシン内で、または別のマシンにさえ完全に移動可能であり、その実行に影響を及ぼさないべきであると言う学派から来ました。

構成可能なオプション、または必要なDLLなどが共有されていない場合は、インストールディレクトリのサブディレクトリに配置して、インストール全体を簡単に移動できるようにする必要があります。

私はプログラムのような小さなユーティリティをたくさん使用しているので、USBスティックにインストールして別のマシンに接続して実行するだけでは、私には適していません。

マイクロソフトのポリシー：

• Windows 95以前は、アプリケーションデータにiniファイルを使用していました。
• Windows 95-XP時代には、レジストリを使用していました。
• Windows Vistaからは、XMLベースですが、iniファイルを使用しています。

レジストリはマシンに依存しています。速度が遅くなり、必要なものを見つけることはほとんど不可能なので、私はそれを好きになりませんでした。だからこそ、シンプルなiniファイルやその他の設定ファイルが好きです。それらがどこにあるか（アプリケーションフォルダーまたはユーザーフォルダー）を知っているので、簡単に移植でき、人間が読めるようになります。

いつ -レガシー統合が原因で、または顧客のシステム管理者が「そうなるはず」と言ったり、XMLの使用をより困難にする古い言語で開発していることが原因である。

理由 -主に、レジストリは、アプリケーションの隣にある設定ファイルをコピーするほど移植性がないためです（ほとんど同じ名前で呼ばれます）。

.Net2 +を使用している場合は、App.ConfigファイルとUser.Configファイルがあり、DLLをレジストリに登録する必要がないため、このファイルに近づかないでください。

設定ファイルには独自の問題がありますが（下記を参照）、これらをコーディングして、アーキテクチャを変更できます。

• 問題：アプリケーションには構成可能な設定が必要でした。
• 解決策：Windowsフォルダーのファイル（WIN.INI）に設定を保存します-セクション見出しを使用してデータをグループ化します（Win3.0）。
• 問題：WIN.INIファイルが大きくなりすぎた（そして乱雑になった）。
• 解決策：設定をアプリケーションと同じフォルダー（Win3.1）のINIファイルに保存します。
• 問題：ユーザー固有の設定が必要です。
• 解決策：ユーザー設定を、ユーザーのウィンドウディレクトリ（Win3.11）のユーザー固有のINIファイルまたはアプリケーションINIファイルのユーザー固有のセクションに保存します。
• 問題：セキュリティ-一部のアプリケーション設定は読み取り専用にする必要があります。
• 解決策：セキュリティを備えたレジストリ、ユーザー固有のセクション、およびマシン全体のセクション（Win95）。
• 問題：レジストリが大きくなりすぎました。
• 解決策：ユーザー固有のレジストリがユーザー自身の「アプリケーションデータ」フォルダのuser.datに移動し、ログイン時にのみロードされました（WinNT）。
• 問題：大規模な企業環境では、複数のマシンにログオンし、それぞれ1つずつセットアップする必要があります。
• 解決策：ローカル（ローカル設定）とローミング（アプリケーションデータ）プロファイル（WinXP）を区別します。
• 問題：他の.Netのようにアプリケーションをxcopyでデプロイまたは移動できません。
• 解決策：アプリケーションと同じフォルダにあるAPP.CONFIG XMLファイル-、読みやすく、操作しやすく、移動しやすく、変更された場合に追跡できます（.Net1）。
• 問題：ユーザー固有のデータを同様の方法（つまり、xcopy展開）で保存する必要があります。
• 解決策：ユーザーのローカルまたはローミングフォルダー内のUSER.CONFIG XMLファイルで、厳密に型指定された（.Net2）。
• 問題：CONFIGファイルでは大文字と小文字が区別され（人間には直感的ではありません）、非常に具体的な開閉「タグ」が必要です。実行時に接続文字列を設定できません。セットアッププロジェクトは（レジストリと同じように）設定を書き込めず、簡単に判別できません。 user.configファイルとユーザー設定は、新しいリビジョンがインストールされるたびにブローされます。
• 解決策：ITEMメンバーを使用して実行時に接続文字列を設定し、Installerクラスにコードを記述してインストール中にApp.Configを変更し、ユーザー設定が見つからない場合はアプリケーション設定をデフォルトとして使用します。

いくつかのウィンドウの位置と最近使用したアイテムのリストをWindowsレジストリに保存すると、世界は終わりますか？これまでのところ、問題はありません。

HKEY-CURRENT-USERは、些細なユーザーデータを少量で保存するのに最適な場所です。それが目的です。他人が乱用したからといって、意図した目的に使用しないのはばかげているようです。

ユーザーのローミングプロファイルで利用できるようにしたい設定は、ユーザーのApplication Dataフォルダーを手動で探す手間を省きたい場合を除いて、おそらくレジストリに登録する必要があります。:-)

レジストリの読み取りと書き込みはスレッドセーフですが、ファイルはそうではありません。したがって、プログラムがシングルスレッドかどうかによって異なります。

あなたが新しいアプリを開発している、あなたは移植性を気にした場合、あなたはすべきNEVERウィンドウ内のデータを格納していない他のOSは、（Windowsの場合）、レジストリがありませんので、レジストリ（当たり前注意を-これは明白かもしれないが、しばしば見落とされます）。

Winプラットフォーム用にのみ開発している場合は、できるだけ避けてください。構成ファイル（暗号化されている可能性がある）は、より優れたソリューションです。レジストリにデータを保存しても利益はありません（たとえば、.NETを使用している場合は、分離ストレージがはるかに優れたソリューションです）。

少し話題から外れていますが、移植性について懸念している人がいるので、今まで使った中で最も良い方法はQtのQSettingsクラスです。設定の保存を抽象化します（Windowsのレジストリ、Mac OSのXML設定ファイル、UnixのIniファイル）。クラスのクライアントとして、私はレジストリやその他について疑問に思って頭を悩ませる必要はありません。それはJust Works（tm）です。

http://doc.trolltech.com/4.4/qsettings.html#details

通常、設定をレジストリに入れない場合は、主に現在のWindows設定の取得、ファイルの関連付けの変更などに使用し
ます。ソフトウェアが既にインストールされているかどうかを検出する必要がある場合は、レジストリに最小限のエントリを作成できます。 、それはあなたがどんな設定でも見つけることができる場所です。または、アプリケーションデータで特定の名前のフォルダを検索します。

Document and Settingsフォルダーを見ると、Unixドット表記を使用してフォルダーを設定しているソフトウェアがたくさんあります。 .jindent .jogl_ext（など）

アプリケーションデータでは、エディタ名またはソフトウェア名を含むさまざまなフォルダ。少なくともポータブルアプリケーションの中で、現在の傾向のように見えます...
WinMergeは少し異なるアプローチを使用し、データをレジストリに保存しますが、構成ダイアログでオプションのインポートとエクスポートを提供します。

個人的には、レジストリを使用して、（アン）インストールスクリプトで使用するインストールパスを格納しました。これが唯一の可能なオプションかどうかはわかりませんが、賢明な解決策のように見えました。もちろん、これはWindowsでのみ使用されているアプリ用です。

.NETでは、本当に必要はありません。

これを行うためにプロジェクトプロパティを使用する方法を示す2つの例を次に示します。

これらの例では、Windowsユーザープロジェクトのプロパティでこれを行っていますが、アプリケーションでも同じことができます/できます。

詳細はこちら：

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

（ディスカッションの後半ですが）短い回答：グループポリシー。

顧客のIT部門が、リンク速度、カスタムエラーメッセージ、または接続するデータベースサーバーなど、書き込み中またはバンドルしているWindowsまたはコンポーネントに関連する設定を適用したい場合でも、これは通常、グループポリシーを介して行われ、レジストリに保存された設定として最終的に現れます。このようなポリシーは、Windowsの起動時またはユーザーのログイン時から適用されます。

コンポーネントの設定をレジストリの場所にマップできるカスタムADMXテンプレートを作成するツールがあり、管理者に適用する必要のあるポリシーを適用するための共通のインターフェイスを提供し、この方法で適用する意味のある設定のみを表示します。

私は、Windowsレジストリは良い考えだと思いますが、アプリケーション開発者からの多大な虐待と、Microsoftが推奨/義務付けていない標準ポリシーのため、管理できない獣になりました。あなたが言及した理由で私はそれを使うのが嫌いですが、それを使うことが理にかなっているいくつかの場合があります：

• アプリケーションがアンインストールされた後、アプリケーションの痕跡を残す（たとえば、アプリケーションが再度インストールされる場合に備えて、ユーザーの設定を覚えておく）
• 異なるアプリケーション間で構成設定を共有する-コンポーネント