レジストリとCustomFileへの保存
プログラムの設定を保存するときに通常のMy.Settings...メソッドを使用してきましたが、プログラムの設定をレジストリに保存してそれらの設定をロードしたい場合は、カスタムの書き込まれたファイルに設定を保存し、ファイルからそれらの設定をロードします。
あなたはどちらを好みますか、そしてその理由は？
良い出発点はJeff Atwoodの記事です： Windowsレジストリは良いアイデアでしたか？
レジストリを使用しないことには多くの理由があります。その中で：
- レジストリは単一障害点です。そのため、レジストリを編集する際のヒントはすべて、regeditを使用してコンピュータを破壊する方法について、大きな悲鳴を上げる免責事項から始まります。
- レジストリは不透明でバイナリです。私が山かっこの税を嫌うのと同じくらい、少なくともXML構成ファイルは合理的に人間が読める形式であり、適切な数のコメントを許可します。
- レジストリはファイルシステムと同期している必要があります。 「アンインストール」せずにアプリケーションを削除すると、古いレジストリの残骸が残ります。または、アプリのアンインストーラーが不十分な場合。ファイルシステムはもはや記録の声明ではありません-なんとかしてレジストリと同期を保つ必要があります。これは、DRY原則の完全な違反です。
- レジストリはモノリシックです。アプリケーションをマシン上の別のパスに、またはまったく別のマシンに移動したいとします。巨大なレジストリtarballからその特定のアプリケーションに関連する設定を抽出してがんばってください。特定のアプリケーションには、通常、レジストリ全体に多数の設定が散在しています。
レジストリを必要とする可能性のある唯一のアプリケーションは次のとおりです。
- COMアプリケーション。中央リポジトリがないと、クラスID（
CLSID）を取得するのがはるかに難しくなります。 - ネットワーク全体で構成を管理する必要がある大規模なアプリケーション（レジストリにデータを保存すると、Admin Templatesをグループポリシー）。
私は、WindowsレジストリをWindows自体に任せるのが最善であることをお勧めします。
- 通常のユーザーはその一部にアクセスできません。
- その一部は、特定のタイプのアプリケーション（64ビットバージョンのWindowsで実行されている32ビットプロセス）にはアクセスできません。
- これは完全に独自のストレージメカニズムであり、アップグレードやセキュリティパッチによって警告なしに変更される可能性があります。
- レジストリの一部をバックアップまたは復元するのは簡単ではありません。それは本当に全部か無かです。
- その中に保持されている値は移植可能ではありません。それらは1つの特定のマシンに固定されています。
ユーザーのローミングプロファイルディレクトリに保持されている単純なテキストファイルとは対照的です。
ユーザーは（セキュリティやUACの複雑化なしに）アクセスでき、そのファイルの形式と内容は完全にyourの制御下にあり、通常のファイルシステムバックアップによってキャプチャされ、持ち運びが可能、シームレスに、ユーザーがログオンするすべてのマシン上にあり、オペレーティングシステムを再インストールする必要がある場合に、ユーザーが迷子になる可能性が低くなります。
昔は（INIファイルではなく）レジストリを使用することを提案していました。最近では、設定と構成のファイルベースの保存に頼っていました。ユーザー変更可能設定の一部は Isolated Storage APIを使用して永続化する必要があります。