開発者として、構成/オプションをレジストリに保存するツールは私の人生の悩みの種です。これらのオプションへの変更を簡単に追跡できず、マシンからマシンへの移植も容易ではありません。これらすべてが、.INI ファイルの古き良き時代を本当に切望しています...
独自のアプリケーションを作成する場合、旧式の構成ファイルではなく、レジストリに何を入れることを選択する必要がありますか? また、その理由は何ですか?
18272 次
14 に答える
78
- もともと (WIN3) 構成は、windows ディレクトリの WIN.INI ファイルに格納されていました。
- 問題: WIN.INI が大きくなりすぎました。
- 解決策 (Win31): プログラムと同じディレクトリにある個々の INI ファイル。
- 問題: そのプログラムがネットワーク上にインストールされ、多くの人々によって共有されている可能性があります。
- 解決策 (Win311): ユーザーの Window ディレクトリにある個々の INI ファイル。
- 問題: 多くの人が Windows フォルダーを共有している可能性がありますが、とにかく読み取り専用にする必要があります。
- 解決策 (Win95): ユーザーごとに個別のセクションを持つレジストリ。
- 問題: レジストリが大きくなりすぎました。
- 解決策 (WinXP): 個々のデータの大きなブロックがユーザー独自の Application Data フォルダに移動されました。
- 問題: 大量のデータには適していますが、少量のデータにはかなり複雑です。
- 解決策 (.NET): アプリケーションと同じフォルダー内の .config (Xml) ファイルに保存された少量の固定された読み取り専用データと、それを読み取るための API 。(読み取り/書き込みまたはユーザー固有のデータはレジストリに残ります)
于 2008-11-06T12:33:30.013 に答える
17
ユーザーの観点とプログラマーの観点の両方からこれを考えると、ファイルの関連付けやマシン固有の設定のようなものでない限り、レジストリに何かを入れる良い言い訳は本当にないと言わざるを得ません。
私は、プログラムはインストールされている場所ならどこからでも実行可能であり、インストールはマシン内、または別のマシンに完全に移動可能であり、実行に影響を与えないようにする必要があるという考え方から来ています。
構成可能なオプション、または必要なdllなどが共有されていない場合は、インストールディレクトリのサブディレクトリに配置して、インストール全体を簡単に移動できるようにする必要があります。
私はプログラムのような小さなユーティリティをたくさん使っているので、USBスティックにインストールして別のマシンに接続して実行することができない場合は、私には向いていません。
于 2008-11-06T12:17:39.453 に答える
14
いつ-レガシー統合のため、または顧客のシステム管理者が「そうなるはずだ」と言ったため、またはXMLの使用をより困難にする古い言語で開発しているために強制されます。
理由-主に、レジストリは、アプリケーションの隣にある構成ファイルをコピーするほど移植性がないためです（ほとんど同じように呼び出されます）。
.Net2 +を使用している場合は、App.ConfigファイルとUser.Configファイルがあり、レジストリにDLLを登録する必要がないため、DLLに近づかないでください。
構成ファイルには独自の問題がありますが（以下を参照）、これらはコード化でき、アーキテクチャを変更できます。
- 問題：アプリケーションには構成可能な設定が必要でした。
- 解決策：設定をWindowsフォルダー内のファイル（WIN.INI）に保存します-セクション見出しを使用してデータをグループ化します（Win3.0）。
- 問題：WIN.INIファイルが大きくなりすぎた（そして乱雑になった）。
- 解決策：アプリケーション（Win3.1）と同じフォルダーにあるINIファイルに設定を保存します。
- 問題：ユーザー固有の設定が必要です。
- 解決策：ユーザー設定をユーザーのウィンドウディレクトリ（Win3.11）のユーザー固有のINIファイル、またはアプリケーションINIファイルのユーザー固有のセクションに保存します。
- 問題：セキュリティ-一部のアプリケーション設定は読み取り専用である必要があります。
- 解決策：セキュリティを備えたレジストリと、ユーザー固有およびマシン全体のセクション（Win95）。
- 問題：レジストリが大きくなりすぎました。
- 解決策：ユーザー固有のレジストリは、ユーザー自身の「アプリケーションデータ」フォルダのuser.datに移動され、ログイン時にのみロードされます（WinNT）。
- 問題：大規模な企業環境では、複数のマシンにログオンし、それぞれをセットアップする必要があります。
- 解決策：ローカル（ローカル設定）プロファイルとローミング（アプリケーションデータ）プロファイル（WinXP）を区別します。
- 問題：.Netの他の部分のようにアプリケーションをxcopyでデプロイまたは移動することはできません。
- 解決策：アプリケーションと同じフォルダーにあるAPP.CONFIG XMLファイル-、読みやすく、操作しやすく、移動しやすく、変更された場合に追跡できます（.Net1）。
- 問題：同様の（つまり、xcopyデプロイ）方法でユーザー固有のデータを保存する必要があります。
- 解決策：ユーザーのローカルフォルダーまたはローミングフォルダーにあり、強く入力された（.Net2）USER.CONFIGXMLファイル。
- 問題：CONFIGファイルでは大文字と小文字が区別され（人間には直感的ではありません）、非常に具体的な開閉「タグ」が必要です。実行時に接続文字列を設定できません。セットアッププロジェクトは設定を書き込めません（レジストリと同じくらい簡単です）。簡単に判別できません。 user.configファイルとユーザー設定は、新しいリビジョンがインストールされるたびに吹き飛ばされます。
- 解決策：ITEMメンバーを使用して実行時に接続文字列を設定し、Installerクラスにコードを記述してインストール中にApp.Configを変更し、ユーザー設定が見つからない場合はアプリケーション設定をデフォルトとして使用します。
于 2008-11-26T04:48:00.673 に答える
13
Microsoftのポリシー：
- Windows 95以前は、アプリケーションデータにiniファイルを使用していました。
- Windows 95-XPの時代には、レジストリを使用していました。
- Windows Vistaからは、iniファイルを使用しますが、現在はxmlベースです。
レジストリはマシンに依存します。遅くなり、必要なものを見つけるのがほとんど不可能なので、私はそれが好きではありませんでした。そのため、単純なiniファイルやその他の設定ファイルが好きです。それらがどこにあるか（アプリケーションフォルダーまたはユーザーフォルダー）がわかっているので、持ち運びが簡単で、人間が読める形式になっています。
于 2008-11-06T12:10:48.983 に答える
9
いくつかのウィンドウ位置と最近使用したアイテムのリストをWindowsレジストリに保存すると、世界は終わりますか？これまでのところ、問題なく動作しています。
HKEY-CURRENT-USERは、些細なユーザーデータを少量保存するのに最適な場所です。それが目的です。他の人がそれを悪用したという理由だけで、その意図された目的のために使用しないのはばかげているようです。
于 2008-11-06T13:28:20.277 に答える
6
レジストリの読み取りと書き込みはスレッドセーフですが、ファイルはそうではありません。したがって、プログラムがシングルスレッドかどうかによって異なります。
于 2008-11-06T12:48:22.760 に答える
4
ユーザーの移動プロファイルで使用できるようにする設定は、実際にユーザーの Application Data フォルダーを手動で探す努力を実際に行いたくない場合を除いて、おそらくレジストリに入れる必要があります。:-)
于 2008-11-06T12:04:43.723 に答える
3
新しいアプリを開発していて、移植性を気にする場合は、他のOSに（Windows）レジストリがないため、Windowsレジストリにデータを保存しないでください（注意-これは明らかかもしれませんが、見落とされがちです）。
Winプラットフォーム用にのみ開発している場合は、できるだけ避けてください。構成ファイル（おそらく暗号化されている）は、はるかに優れたソリューションです。レジストリにデータを保存してもメリットはありません（たとえば、.NETを使用している場合は、分離ストレージの方がはるかに優れたソリューションです）。
于 2008-11-06T12:16:37.677 に答える
2
少し本題から外れますが、移植性について懸念している人を見かけるので、私がこれまでに使用した最良のアプローチは Qt の QSettings クラスです。設定の保存を抽象化します (Windows ではレジストリ、Mac OS では XML 設定ファイル、Unix では Ini ファイル)。クラスのクライアントとして、レジストリやその他のことについて頭を悩ませる必要はありません。Just Works (tm) です。
于 2008-11-06T12:48:43.027 に答える
0
.NETでは、実際には必要はありません。
これを行うためにプロジェクトプロパティを使用する方法を示す2つの例を次に示します。
これらの例は、Windowsユーザープロジェクトのプロパティによってこれを行いますが、アプリケーションでも同じことができます。
詳細はこちら：
于 2008-12-29T20:00:21.937 に答える
0
通常、レジストリに設定を入れない場合は、主に現在のWindows設定の取得、ファイルの関連付けの変更などに使用し
ます。ソフトウェアが既にインストールされているかどうかを検出する必要がある場合は、レジストリに最小限のエントリを作成できます。 、それはあなたがどんな設定でも見つけることができる場所です。または、アプリケーションデータで指定された名前のフォルダを検索します。
Document and Settingsフォルダーを見ると、フォルダーの設定にUnixドット表記を使用しているソフトウェアがたくさんあります。.p4qt.sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext（など）
アプリケーションデータでは、エディタ名またはソフトウェア名が付いたさまざまなフォルダ。少なくともポータブルアプリケーションの間では、現在の傾向のように見えます...
WinMergeはわずかに異なるアプローチを使用し、データをレジストリに保存しますが、構成ダイアログでオプションのインポートとエクスポートを提供します。
于 2008-11-06T12:12:04.690 に答える
0
個人的には、レジストリを使用して、（アン）インストールスクリプトで使用するインストールパスを保存しました。これが唯一の可能な選択肢であるかどうかはわかりませんが、賢明な解決策のように思えました。もちろん、これはWindowsでのみ使用されていたアプリ用でした。
于 2008-11-06T13:51:32.977 に答える
0
Windows レジストリは良いアイデアだったと思いますが、アプリケーション開発者による悪用と、Microsoft によって推奨/義務付けられていない標準ポリシーが手に負えない獣に成長したためです。あなたが言及した理由で私はそれを使うのが嫌いですが、それを使うのが理にかなっている場合があります:
- アプリケーションがアンインストールされた後にアプリケーションの痕跡を残す (例: アプリケーションが再度インストールされた場合に備えてユーザーの設定を記憶する)
- 異なるアプリケーション間で構成設定を共有する - コンポーネント
于 2008-11-06T12:55:10.157 に答える