28

「.NET アプリに設定を保存するにはどうすればよいですか?」というような質問に対する回答をよく目にします。次のように、手動で app.config (または web.config) にエントリを追加して、app.config ファイルを編集します。

<configuration> 
  <appSettings>
    **<add key="ConfigValueName" value="ABC"/>**
  </appSettings>
</configuration>

次に、次のようにアクセスします。

string configValue = Configuration.AppSettings["ConfigValueName"];

上で概説したアプローチを「app.config」アプローチと呼びます。プロジェクトに「設定」ファイルを追加することを勧める人はめったにいません。私はこれをウェブやスタックオーバーフローで何度も見てきました...何かが足りないのではないかと思い始めています...なぜなら、「設定" ファイル。私は VS2005 まで .NET を使用していなかったので、私が持っている 1 つの理論は、これは VS2003 で行われた方法であり、人々は決して切り替えなかったということですか?

app.config アプローチを推奨する人々の例:

私の見解では、「設定ファイル」アプローチには次の利点があります。

  1. アプリケーション設定 (すべてのユーザーに共通の設定) とユーザー設定の両方を同じインターフェイスから使用できます。
  2. Visual Studio で設定デザイナー サポートを使用する機能。XMLファイルを直接編集するよりもエラーが発生しにくいです。
  3. リファクタリング - 特定の設定名の名前を変更すると、コード内の参照が自動的に更新されます。
  4. コンパイルの型チェック。
  5. オートコンプリートのサポート。
  6. プロパティ グリッド機能。PropertyGrid コントロールは、クイック オプション フォームを作成するための非常に簡単な方法であることがわかりました。やるだけでpropertyGrid1.SelectedObject = Settings1.Default;完了です。

「設定」ファイル アプローチの意味がわからない場合は、この投稿を参照してください。これは、app.confg の代わりに設定ファイルを使用することを推奨する数少ない例の 1 つです。

編集: 理解してください: このトピックの意図は、人々が設定ファイルのアプローチよりも上で概説した app.config アプローチを使用する理由を理解することです。私は、設定ファイルのアプローチの限界に直面し、時には独自のカスタム ソリューションをロールバックすることを余儀なくされました。それはまったく別の議論です。

4

7 に答える 7

23

この 2 つの最大の違いは、アプリケーションが の値を変更できないことだと思いますapp.config。これらの値は実行時に読み取られ、構成ファイルに新しい値を書き込むための組み込みサポートはありません。

コマンドで設定ファイルを変更できますSave()。

組み込みの設定ファイルのサポートに関する主な問題の 1 つは、設定ファイルの保存場所です。APPDATA フォルダーを見ると、会社名のフォルダー、製品名のサブフォルダー、半ランダムな名前とバージョン情報のサブフォルダーがあることがわかります。 .

新しいバージョンをリリースするたびに、設定ファイルが保存されている場所が原因で、以前のバージョンの設定ファイルが見つかりません。また、設定ファイルの保存場所を変更する方法もありません。

私は 1 つのプロジェクトでこれを使用しましたが、設定に XML ファイルを使用する独自の AppSettings クラスを作成する方がはるかに便利であることがわかりました。ファイルの形式と場所を制御できます。

于 2009-06-19T07:17:01.293 に答える
2

議論がなければ、答えは次のとおりです。

「その方が簡単だからです。」

于 2009-06-19T07:47:57.143 に答える
1

2 つのシナリオ:

  • 構成設定がデフォルト値に設定された状態で出荷されるクライアント アプリ。このアプリは、1 人のユーザーまたはすべてのユーザーの設定を変更するための UI を提供します。

ここでは、「設定」アプローチが優勢です。

  • それぞれがいくつかの簡単な構成設定を必要とする、いくつかの比較的独立したアセンブリで構成されるアプリ。設定は通常、管理者によって設定され、デプロイされたアプリケーションによって変更されることはありません。

ここで「appSettings」は、管理がはるかに簡単になります。「設定」アプローチでは、メイン アプリケーションの構成ファイルに追加されるすべての構成可能なアセンブリのセクションがあります。

于 2009-06-19T11:48:59.483 に答える
1

設定ファイルのインフラストラクチャは (1) より複雑であり、(2) その複雑さを考えると十分に文書化されていないためです。

設定ファイルがデフォルトで機能する方法は、小規模なアプリケーションに役立ちます。より大きなものでは、このデフォルトを変更する必要があることがよくあります。設定ファイルのインフラストラクチャをニーズに合わせて活用できますが、適切なドキュメントがあっても、学習曲線が急になります。ドキュメントがなければ、ほとんど役に立たない。

この記事を参照して結論を​​出すだけです。私の主張と矛盾する概念的な MSDN ドキュメントへの便利なリンクを自由に貼り付けてください。

アップデート：

公平を期して、文書化されていない特定のユースケースを提供する必要があります。

アプリケーション設定デザイナーが好きです。保存された設定の XML 形式も気に入っています。これらの機能を保持したかったのですが、設定を保存する別の場所を使用しました。このユースケースがサポートされているかどうか、サポートされている場合は、タスクを達成する方法についてのヒントは見つかりませんでした。

于 2013-02-21T07:42:26.827 に答える
0

また、app.Config と [設定] ウィンドウの違いを 1 つ指摘したいと思います。[設定] で何かを保存すると、設定は次の場所に保存されます。

Windows XP: c:\Documents and Settings\%Username%\Local Settings\Application Data{発行者名}\

Windows 7: C:\Users\%Username%\AppData\Local{パブリッシャー名}\

app.config 設定は構成ファイルにのみ保存されます。

于 2012-04-17T20:03:24.077 に答える
0

不正解: 設定ファイル アプローチの問題の一部は、アプリを特定の場所に配置し、設定ファイルを正しい場所に配置する必要があることです。これらのいずれかが誤って移動された場合、削除された場合と同様に、設定が完全​​に失われる可能性があります。また、フォルダー内に同じ名前の設定ファイルが複数存在し、1 つが上書きされるという問題が発生する可能性もあります。ソフトウェアが設定ファイルに依存している場合、これは特に悪いことです。これらの問題は、インストールされたソフトウェアではそれほど顕著ではありませんが、インストールされておらず、ダウンロードして実行するだけのソフトウェアでは大きな問題になる可能性があります。誰かがこれらのプログラムのいくつかを同じディレクトリにダウンロードし、それらがすべて同じ設定ファイル名を使用したとします。

編集:質問をした人と議論したように、質問は設定ファイルに保存する2つの異なる方法に言及しているため、この回答は正しくありません。私が答えたとき、私は彼が 2 つの異なるファイルを参照していると考えていました。私が提供できる他の唯一の答えについては、それは個人的な好みの問題だということです.

于 2009-06-19T07:20:41.567 に答える