私は新しい Windows プログラマーであり、ユーザーが構成可能なアプリケーション設定をどこに保存すればよいかわかりません。ユーザーがアプリケーション設定を変更するためのユーザー フレンドリーな手段を提供する必要があることを理解しています。設定フォームなど。しかし、ユーザーがそのフォームの [適用] ボタンを押した後、値をどこに保存すればよいでしょうか?
設定を Windows レジストリに保存することと、ローカルの INI ファイルや構成ファイルなどに保存することの長所と短所は何ですか?
私は新しい Windows プログラマーであり、ユーザーが構成可能なアプリケーション設定をどこに保存すればよいかわかりません。ユーザーがアプリケーション設定を変更するためのユーザー フレンドリーな手段を提供する必要があることを理解しています。設定フォームなど。しかし、ユーザーがそのフォームの [適用] ボタンを押した後、値をどこに保存すればよいでしょうか?
設定を Windows レジストリに保存することと、ローカルの INI ファイルや構成ファイルなどに保存することの長所と短所は何ですか?
構成ファイルの利点:
レジストリの利点:
構成情報を保存する簡単な方法だけが必要な場合は、INI または XML を形式として使用する構成ファイルをお勧めします。レジストリの使用から抜け出したい特定の何かがある場合にのみ、レジストリを使用することをお勧めします。
Jeff Atwood は、Windows のレジストリと、代わりに .INI ファイルを使用する方がよい理由についての優れた記事を書いています。
アプリケーションごとの設定が、簡単に見たり、操作したり、バックアップしたりできる場所に保存されていれば、私の生活はかなり楽になるでしょう。たとえば... INIファイルで。
- レジストリは単一障害点です。そのため、これまでに見つけたすべてのレジストリ編集のヒントは、regedit を使用してコンピューターを壊す方法についての、大げさな絶叫免責事項から始まります。
- レジストリは不透明でバイナリです。私は山かっこ税が嫌いですが、少なくとも XML 構成ファイルはかなり人間が判読できるものであり、適切と思われる限り多くのコメントを許可します。
- レジストリはファイルシステムと同期している必要があります。アプリケーションを「アンインストール」せずに削除すると、古いレジストリが残ります。または、アプリのアンインストーラーの記述が不十分な場合。ファイルシステムはもはや記録のステートメントではありません.何らかの形でレジストリとの同期を保つ必要があります. これは DRY の原則に完全に違反しています。
- レジストリはモノリシックです。アプリケーションを自分のマシンの別のパスに移動したり、まったく別のマシンに移動したいとします。その特定のアプリケーションに関連する設定を、巨大なレジストリ tarball から抽出できたことを幸運に思います。特定のアプリケーションには通常、レジストリ全体に多数の設定が散らばっています。
レジストリよりも INI ファイルを使用する利点がもう 1 つありますが、これについては触れていません。ユーザーが何らかのボリューム/ファイル ベースの暗号化を使用している場合、INI ファイルを非常に簡単に暗号化できます。レジストリを使用すると、おそらくもっと問題になります。
アプリケーションと同じディレクトリにあるiniファイルを使用すると、アプリケーションと一緒にバックアップできます。したがって、OS を再ロードした後は、アプリケーション ディレクトリを復元するだけで、希望どおりの構成が得られます。
GetPrivateProfileStringのドキュメントによると、レジストリを使用して初期化情報を保存する必要があります。
ただし、そうは言っても、引き続き .ini ファイルを使用し、それらにアクセスするために標準プロファイル API ( GetPrivateProfileString
、WritePrivateProfileString
など) を使用する場合は、これらの API によって、「仮想 .ini ファイル」を自動的に提供する組み込みの方法が提供されます。レジストリ。ウィンウィン!
ここには、いくつかの長所と短所をカバーする同様の質問があります。
アプリケーションで絶対に必要な場合を除き、レジストリを使用しないことをお勧めします。私の理解では、Microsoft は設定ファイルの柔軟性のためにレジストリの使用を思いとどまらせようとしています。また、.ini ファイルの使用はお勧めしませんが、代わりに .Netの組み込み機能を使用してユーザー/アプリの設定を保存することをお勧めします。
私はダニエルに同意します。それが大規模なアプリケーションの場合は、レジストリで行うと思います。それが小さなアプリケーションで、構成フォームを作成せずにユーザーが構成できるようにしたい場合は、クイック INI ファイルを使用してください。
私は通常、次のように解析を行います (.ini ファイルの形式がオプション = 値、1 行に 1 つ、# で始まるコメントの場合):
static void Parse()
{
StreamReader tr = new StreamReader("config.ini");
string line;
Dictionary<string, string> config = new Dictionary<string, string>();
while ((line = tr.ReadLine()) != null)
{
// Allow for comments and empty lines.
if (line == "" || line.StartsWith("#"))
continue;
string[] kvPair = line.Split('=');
// Format must be option = value.
if (kvPair.Length != 2)
continue;
// If the option already exists, it's overwritten.
config[kvPair[0].Trim()] = kvPair[1].Trim();
}
}
編集:申し訳ありませんが、言語を指定したと思いました。上記の実装は C# です。
Danielが示したように、レジストリに構成データを保存すると、管理用テンプレートを使用するオプションが提供されます。つまり、管理用テンプレートを定義し、それをグループポリシーで使用して、ネットワーク全体でアプリケーションの構成を管理できます。アプリケーションの性質によっては、これは大きな恩恵になる可能性があります。
レジストリは、迅速なアクセスと簡単な更新のために最適化されており、拡張機能との関連付けなど、特定の Windows 固有の操作を実行する唯一の方法です。また、プログラムをアンインストールするために 1 つのディレクトリを削除するという議論は無視できます。Windows Vista では Program Files ディレクトリ内のファイルを変更できないため、とにかく構成を別のフォルダに移動する必要があります。
Windows プログラミングには一般的なガイドラインがあります。Microsoft が期待する方法で作業を行うことで、作業が大幅に楽になります。
とはいえ、INI ファイルの魅力は理解できますし、それを検討したことで誰かを責めるつもりはありません。
ini または config ファイルには 1 つの欠点があり、ユーザーがプログラムのインストール先を選択するオプションを持っている場合、それらの場所を特定できます。
レジストリを使用することの他の欠点は、32 ビットと 64 ビットのアプリケーションが混在する環境で作業している場合、レジストリにアクセスするためのシステム コールがランダムに(*)\Wow6432Node\
レジストリ パスに追加され、デバッグ中に気が狂ってしまうことです。 .
(*もちろんランダムではありませんが、非常に迷子になりやすいです)