いつ-なぜ-Windowsレジストリにデータを保存する必要がありますか？
開発者として、レジストリに構成/オプションを保存するツールは私の悩みの種です。これらのオプションの変更を簡単に追跡できず、マシンからマシンに簡単に移植できないため、.INIファイルの古き良き時代に本当に憧れます...
独自のアプリケーションを作成する場合、旧式の構成ファイルではなく、レジストリに置くことを選択する必要があるのはなぜですか？
- 元々（WIN3）構成は、windowsディレクトリのWIN.INIファイルに保存されていました。
- 問題：WIN.INIが大きくなりすぎました。
- 解決策（Win31）：個別のINIプログラムと同じディレクトリにあるファイル。
- 問題：そのプログラムはネットワークにインストールされ、多くの人々によって共有される可能性があります。
- 解決策（Win311）：ユーザーのWindowディレクトリにある個々のINIファイル。
- 問題：多くの人がWindowsフォルダーを共有する可能性があり、とにかく読み取り専用にする必要があります。
- 解決策（Win95）：ユーザーごとに個別のセクションがあるレジストリ。
- 問題：レジストリが大きくなりすぎた。
- 解決策（WinXP）：個々のデータの大きなブロックがユーザー自身のアプリケーションデータフォルダーに移動されました。
- 問題：大量のデータには適していますが、少量のデータにはかなり複雑です。
- 解決策（.NET）：アプリケーションと同じフォルダー内の.config（Xml）ファイルに格納された、読み取り専用のAPIを使用した、少量の固定読み取り専用データ。 （読み取り/書き込みまたはユーザー固有のデータはレジストリに残ります）
ユーザーの観点とプログラマーの観点の両方からこれを考えると、ファイルの関連付けやマシン固有の設定のようなものでない限り、レジストリに何かを入れるのは本当に言い訳にはならないと言わざるを得ません。
私は、プログラムはインストールされた場所から実行可能でなければならず、インストールはマシン内で、または別のマシンまで完全に移動可能であり、その実行に影響しないようにすべきだと言う学派から来ました。
構成可能なオプション、または必要なdllなどが共有されていない場合は、インストールディレクトリのサブディレクトリに配置して、インストール全体を簡単に移動できるようにする必要があります。
私はプログラムのような小さなユーティリティをたくさん使用しているので、それをUSBスティックにインストールして別のマシンに接続して実行するだけでは、私には向かないでしょう。
マイクロソフトのポリシー：
- Windows 95以前は、アプリケーションデータにiniファイルを使用していました。
- Windows 95-XP時代では、レジストリを使用しました。
- Windows Vistaでは、iniファイルを使用していますが、現在はxmlベースです。
レジストリはマシンに依存しています。遅くなり、必要なものを見つけることはほとんど不可能なので、私はそれが好きではありませんでした。だから、単純なiniや他の設定ファイルが好きです。どこにあるか（アプリケーションフォルダーまたはユーザーフォルダー）を知っているので、簡単に移植でき、人間が読むことができます。
When-レガシー統合のために、または顧客のシステム管理者が「そうなる」と言っているため、またはXMLの使用をより困難にする古い言語で開発しているために、強制されます。
理由-主にレジストリは、アプリケーションの隣にある設定ファイルをコピーするほど移植性が高くない（ほぼ同じと呼ばれる）ため。
.Net2 +を使用している場合、App.ConfigファイルとUser.Configファイルがあり、レジストリにDLLを登録する必要がないので、そこから離れてください。
構成ファイルには独自の問題があります（以下を参照）が、これらをコーディングしてアーキテクチャを変更できます。
- 問題：アプリケーションには構成可能な設定が必要でした。
- 解決策：Windowsフォルダー内のファイル（WIN.INI）に設定を保存します-セクション見出しを使用してデータをグループ化します（Win3.0）。
- 問題：WIN.INIファイルが大きくなりすぎた（そして乱雑になった）。
- 解決策：設定をINIファイルにアプリケーション（Win3.1）と同じフォルダーに保存します。
- 問題：ユーザー固有の設定が必要です。
- 解決策：ユーザー固有のINIユーザーのウィンドウディレクトリ（Win3.11）のファイルまたはアプリケーションのユーザー固有のセクションINIファイル。
- 問題：セキュリティ-一部のアプリケーション設定は読み取り専用にする必要があります。
- 解決策：セキュリティ、ユーザー固有およびマシン全体のセクション（Win95）を備えたレジストリ。
- 問題：レジストリが大きくなりすぎた。
- 解決策：ユーザー固有のレジストリは、ユーザー自身の「アプリケーションデータ」フォルダーのuser.datに移動し、ログイン時にのみロードされます（WinNT）。
- 問題：大規模な企業環境では、複数のマシンにログオンし、それぞれを設定する必要があります。
- 解決策：ローカル（ローカル設定）プロファイルとローミング（アプリケーションデータ）プロファイル（WinXP）を区別します。
- 問題：.Netの残りのようなアプリケーションをxcopyでデプロイまたは移動できません。
- 解決策：アプリケーションと同じフォルダーにあるAPP.CONFIG XMLファイル-、読みやすく、操作しやすく、移動しやすく、変更された場合に追跡できます（.Net1）。
- 問題：ユーザー固有のデータを同様の方法（つまり、xcopyデプロイ）で保存する必要があります。
- 解決策：ユーザーのローカルフォルダーまたはローミングフォルダーにあるUSER.CONFIG XMLファイルと厳密に型指定された（.Net2）。
- 問題：CONFIGファイルは大文字と小文字を区別し（人間には直観的ではありません）、非常に特定の開閉タグを必要とします。実行時に接続文字列を設定できません。 user.configファイルとユーザー設定は、新しいリビジョンがインストールされるたびに吹き飛ばされます。
- 解決策：ITEMメンバーを使用して実行時に接続文字列を設定し、インストーラークラスでコードを記述してインストール中にApp.Configを変更し、ユーザー設定が見つからない場合はアプリケーション設定をデフォルトとして使用します。
いくつかのウィンドウ位置と最近使用したアイテムのリストをWindowsレジストリに保存すると、世界は終わりますか？これまでのところ私にとっては大丈夫です。
HKEY-CURRENT-USERは、些細なユーザーデータを少量保存するのに最適な場所です。それが目的です。他の人が悪用したからといって、意図した目的に使用しないのはばかげているようです。
レジストリの読み取りと書き込みはスレッドセーフですが、ファイルはそうではありません。したがって、プログラムがシングルスレッドかどうかによって異なります。
ユーザーの移動プロファイルで使用可能にしたい設定は、実際にユーザーのアプリケーションデータフォルダーを手作業で探したい場合を除き、おそらくレジストリに登録する必要があります。 :-)
少し話題から外れていますが、移植性を心配している人がいるので、これまで使用した中で最も良いアプローチはQtのQSettingsクラスです。設定（Windowsのレジストリ、Mac OSのXML設定ファイル、UnixのIniファイル）のストレージを抽象化します。クラスのクライアントとして、私は、レジストリまたは他の何かについて疑問に思う脳サイクルを費やす必要はありません。それはJust Works（tm）です。
新しいアプリを開発していて、移植性に関心がある場合は、他のOSには（windows）レジストリがないため、[〜＃〜] never [〜＃〜] Windowsレジストリにデータを保存する必要があります（ダウ注意-これは明白かもしれませんが、しばしば見落とされます）。
Winプラットフォーム用にのみ開発している場合は、できるだけ避けてください。構成ファイル（暗号化されている場合もあります）は、より優れたソリューションです。レジストリにデータを保存してもメリットはありません（たとえば、.NETを使用している場合は、隔離されたストレージがはるかに優れたソリューションです）。
（議論に遅れるが）短い答え：グループポリシー。
顧客のIT部門が、リンク速度、カスタムエラーメッセージ、または接続するデータベースサーバーなど、Windowsまたは書き込みまたはバンドルしているコンポーネントに関連する設定を適用したい場合、これは通常、グループポリシーを介して行われます。グループポリシーは、レジストリに保存された設定として最終的に表示されます。このようなポリシーは、Windowsの起動時またはユーザーのログイン時から施行されます。
コンポーネントの設定をレジストリの場所にマップできるカスタムADMXテンプレートを作成するツールがあり、管理者にポリシーを適用するための共通のインターフェースを提供し、この方法を適用するのに意味のある設定のみを表示します。
通常、レジストリに設定を入れない場合、主に現在のWindows設定の取得、ファイルの関連付けの変更などに使用します。
これで、ソフトウェアが既にインストールされているかどうかを検出する必要がある場合、レジストリに最小限のエントリを作成できます。これは、任意の構成で見つけることができる場所です。または、アプリケーションデータで指定された名前のフォルダーを検索します。
Document and Settingsフォルダーを見ると、フォルダーを設定するためにUnixドット表記を使用している多くのソフトウェアが表示されます。 .jindent .jogl_ext（など）
アプリケーションデータでは、エディター名またはソフトウェア名を持つさまざまなフォルダー。少なくともポータブルアプリケーションの中で、現在の傾向であるように見えます...
WinMergeはわずかに異なるアプローチを使用して、データをレジストリに保存しますが、構成ダイアログでオプションのインポートとエクスポートを提供します。
.NETでは、実際に必要はありません。
これを行うためにプロジェクトプロパティを使用する方法を示す2つの例を次に示します。
これらの例は、Windowsユーザープロジェクトプロパティによってこれを行いますが、アプリケーションでも同じことができます。
詳細はこちら：
個人的には、レジストリを使用して、（アン）インストールスクリプトで使用するインストールパスを保存しました。これが唯一の選択肢かどうかはわかりませんが、賢明な解決策のように思えました。これは、もちろんWindowsでのみ使用されていたアプリ用です。