.net - .NETの「アプリケーション設定」がレジストリに保存されないのはなぜですか？

Question

90年代のある時期に、MicrosoftはWindowsレジストリを導入しました。アプリケーションは、設定をさまざまなハイブに保存できます。アプリケーション全体およびユーザー固有のスコープ用のハイブがあり、ローミングプロファイルが正しく機能するように、これらは適切な場所に配置されました。

.NET 2.0以降では、アプリケーション設定と呼ばれるものがあります。アプリケーションはそれらを使用して、XMLファイル、app.exe.configおよびuser.configに設定を保存できます。これらはアプリケーション全体およびユーザー固有のスコープ用であり、移動プロファイルが正しく機能するように適切な場所に配置されます。

おなじみですか？これらのアプリケーション設定が、単にレジストリを使用するのではなく、XMLファイルによってサポートされている理由は何ですか？これはまさにレジストリが意図したものではありませんか？

私が考えることができる唯一の理由は、レジストリがWindows固有であり、.NETがプラットフォームに依存しないようにしようとしていることです。これは（または）理由でしたか、それとも私が見落としている他の考慮事項がありますか？

score 28 · Accepted Answer

28

レジストリに依存することで、XCOPYの展開が妨げられます。

于 2010-04-08T13:32:32.257 に答える

score 24 · Accepted Answer

私はそれが1つの答えではないと思います。それは組み合わせだと思います：

作成時のレジストリは、以前は一般的に使用されていた .ini ファイルとは対照的に、すべてのプログラムのすべての設定を 1 か所に保存することをお勧めします。当時、低速のハードドライブから小さな .ini ファイルを読み取るにはコストがかかるため、これによりパフォーマンスが向上しました。1 つのレジストリファイルでパフォーマンスがいくらか向上しました。ハードドライブがはるかに高速になり、レジストリにダンプされる設定がますます多くなるため、システムに負担がかかるため、これは異なります。これは、Windows で多くのプログラムをインストールおよびアンインストールすると速度が低下し始め、最終的にはおそらく再フォーマットすることになります。
現在のユーザー設定であっても、レジストリへの不適切な書き込みはシステムを台無しにする可能性があります。
レジストリは、レジストリキーの不足を処理するための特定のコードがなければ、プログラムの xcopy 展開には役立ちません...これには、多くの場合、単にフォルダーを削除することによるプログラムの削除が含まれます
レジストリへのアクセスが必要な場合、アプリケーションをインストールするために、より大きな権限が必要になる場合があります
.config ファイルを使用すると、デフォルトのアプリケーションとユーザー設定を簡単に許可できます。これは、エンドユーザーがプログラムを最初に実行するときに変更できます。
OS 固有のコードがなくても、.NET を他のシステムで実行できる可能性があります。これは、Silverlight と分離ストレージで多少見られます。
アプリケーションとユーザーに分離ストレージを使用することによるセキュリティの強化
マイクロソフトが将来、多くの古い依存関係を持たないマネージコードのみの OS を持つ可能性を提供します。フレームワークは、任意の OS とマネージコードの間のレイヤーと考えてください。

score 15 · Accepted Answer

もう1つの理由は、レジストリを編集するには、より多くのアクセス許可が必要になるためです。アプリの構成ファイルを編集しているだけの場合は、そのファイルに対する権限のみが必要です。

score 12 · Accepted Answer

レジストリは巨大であるため、関連情報を見つけるのは面倒です（検索しても）。
レジストリを変更するときに、誤って他のアプリケーションに影響を与える可能性があります。
レジストリが破損している場合、すべてのアプリケーション（OSを含む）が影響を受ける可能性があります。
レジストリを検索、変更、さらにはコピーするには、特別な目的のツールが必要です。

私は設定ファイルが好きです。

score 7 · Accepted Answer

これは、レジストリが使用するのが醜い悪夢であり、人々がそれを気に入らなかったためです。また、xcopyの展開もサポートしていませんでした。構成にxmlファイルを使用すると、インストーラーを必要とせずにアプリをマシン間で移動できます。これは、90年代にコードを書くことに対する最大の不満の1つでした。

レジストリを使用すると、多くの組織で禁止されているアプリケーションをインストールするときに、レジストリを変更する権限を誰かに付与する必要があります。アプリケーションの設定を変更するには、レジストリのどこを見ればよいかを知る必要がありますが、これは多くの場合、せいぜい困難です。設定ファイルを使用すると、他のほとんどのアプリから分離されます。通常、必要なすべての設定は、簡単に表示および変更できるようにそこにあります。

score 5 · Accepted Answer

1つの即時の（しかし重要な）利点：

構成ファイルをplain使用すると、ユーザーは、バックアップからの再インストール/復元の場合に設定を簡単に復元できます。レジストリ値からこれを行うのは非常に困難です。

score 3 · Accepted Answer

レジストリを介して構成ファイルに移動することの大きな利点の 1 つは、同じプログラムのサイドバイサイドインストールが可能になることです。レジストリを使用すると、これらの重複したインストールの中央構成情報が重複しますが、構成ファイルを使用すると、情報は特定のインストールごとに非公開に保たれます。ユーザー固有の構成の上書きが潜在的に重複する可能性があることは事実ですが (インストールパスに固有ではなく、ユーザーのアプリデータフォルダーに格納されているため)、異なるユーザーが異なるインストールを使用するシナリオを想像してください。この場合、この潜在的な問題は次のようになります。無関係。

score 2 · Accepted Answer

これの主な理由の1つは、アプリケーションの更新だったと思います。更新プログラムをインストールすると（つまり、ClickOnceを使用して）、新しい設定は実際には新しいフォルダーに移動します。アンインストールすると、新しいフォルダは削除され、古い設定はそのまま残ります。代わりにレジストリが使用された場合、この「バージョン管理」を行う方法はありません。

その他の理由は次のとおりです。

アクセス許可（アプリの設定は常にAppData / LocalAppDataに移動し、特権は必要ありません）
メンテナンス/バックアップのしやすさ
移植性（.NET Compact Frameworkを使用してレジストリを処理するのはかなり困難です。Monoをサポートしようとしている場合は、神が助けてくれます）。

score 2 · Accepted Answer

レジストリは、他の人がすでに挙げた多くの理由から、「当時は良いアイデアのように思えた」ものの 1 つであるように私には思えます。結局のところ、何かがそれほど素晴らしいアイデアではなかったことに気づき、代わりに、よりシンプルで便利な代替手段を使用することには何の問題もありません。

score 1 · Accepted Answer

シェアポイントとチームファウンデーションサーバーで使用され、SQL に裏打ちされたデータストレージフォーマットは、もともと Windows 7 で Windows ファイルシステムを置き換えることを意図していたというかなり大きな噂を耳にしました。いつの日か?) データのリストを格納するためのトランザクションデータストアを取得します。このデータ保存方法は、おそらくあらゆる点でレジストリよりも優れています。

それを考えると、Microsoft が .net フレームワークの採用を進める中で、レジストリの使用を最小限に抑えていることは驚くに値しません。

score 1 · Accepted Answer

単にレジストリを使用する代わりに

レジストリは単純ではありません。私の PC では、40MB のバイナリの混乱があり、その中のビットが彼らの考えを変えないことを願っています。

これはまさにレジストリが意図したものではありませんか?

はい。しかし、繰り返しになりますが、DLLは、さまざまなアプリケーションに共有機能を提供することを目的としていました。

score 0 · Accepted Answer

.configファイルの新しい方法は次のように役立つと思います。

提供されているデフォルト構成のオーバーライドとして、アプリケーションに独自の構成を提供する柔軟性を与えます。web.configがmachine.configをオーバーライドする場合を考えてみてください。
必要な権限がないため、レジストリ設定を変更できない場合があります。したがって、構成ファイルを使用すると、追加の権限を必要とせずに、独自のアプリケーションに適用可能な変更を加えることができます。
レジストリエントリを使用すると、複数のアプリケーションが同じ構成を使用している可能性があります。ただし、アプリケーションに合わせて変更すると、他のアプリケーションで意図しない動作が発生する可能性があり、これに関する完全な情報がない可能性があります。

頭に浮かぶいくつかの考え...

HTH。

score 0 · Accepted Answer

0

リモート展開の容易さが決定的な要因であると思い切って思います。

于 2010-04-08T13:33:10.797 に答える

score 0 · Accepted Answer

これは、プラットフォームに依存しないという問題ではないと思います。過去に多くのアプリケーションが Linux、Mac、および Windows で開発されており、構成ファイルを使用するものもあれば、レジストリを使用するものもあります。

主な理由は「COM体験」にあると思います。全体の原則は、コンポーネントオブジェクトをレジストリに集中的に登録して、どのアプリケーションでも dll をコピーしなくてもコンポーネントオブジェクトを使用できるようにすることでした。これにより、バージョン管理の問題が急速に発生しました。複数のアプリケーションが同じコンポーネントの異なるバージョンを使用することはほとんどありませんでした。

レジストリの構成では、同じ問題があります。開発が正しく行われなかった場合、同じアプリケーションの 2 つのバージョンを持つことは実際の問題になる可能性があります。ずっと前に、複数のバージョンの Oracle を使用していると、この種の問題が発生しました。

.Net とハードドライブの爆発的な容量と帯域幅により、ファイルの重複はもはや問題ではありません。依存関係をフォルダープロジェクトにコピーすると、アプリケーションの展開が大幅に簡素化されます。同じことが構成ファイルにも当てはまります。レジストリの限られたマシン/ユーザーアーキテクチャの問題を抱えることなく、同じアプリケーションの複数のコピー/バージョンをホストできます。

score 0 · Accepted Answer

アプリケーションの移植性は、その理由の 1 つです。アプリケーションフォルダは、あるコンピュータから別のコンピュータにコピーすることができ、設定はアプリケーションと共に移動します。複数のコンピューターで USB フラッシュドライブからアプリケーションを実行する場合に便利です。

score -1 · Accepted Answer

アプリケーション設定 (.config ファイル) には大きなセキュリティ上の問題があると思います。それは、任意のテキストエディターで編集でき、あらゆるものを変更できることです。

connectionString が保存されていて、構成ファイル内のすべての値を削除または変更した場合、アプリケーションには多くの問題が発生するため、構成ファイルを保護する必要があります。

または、たとえばDLLファイルに設定を保存します。

.net - .NETの「アプリケーション設定」がレジストリに保存されないのはなぜですか？

17 に答える 17

Related

Reference