AppSettingsとapplicationSettingsの長所と短所（.NET app.config / Web.config）

.NET Windowsフォームアプリケーションを開発する場合App.config、設定値を格納するためにこれらのタグから選択できます。どちらがいいですか？

<configuration>

  <!-- Choice 1 -->
  <appSettings>
    <add key="RequestTimeoutInMilliseconds" value="10000"/>
  </appSettings>

  <!-- Choice 2 -->
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" >
        <section name="Project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Project1.Properties.Settings>
      <setting name="TABLEA" serializeAs="String">
        <value>TABLEA</value>
      </setting>
    </Project1.Properties.Settings>
  </applicationSettings>

</configuration>

基本的な<appSettings>方が扱いやすい- <add key="...." value="..." />エントリーを叩くだけで完了です。

欠点は、型チェックがないことです。たとえば、設定したい番号が実際にあると安全に想定することはできません。誰かがその設定に文字列を入力する可能性があります.....そのままアクセスしてConfigurationManager["(key)"]起動しますあなたが何を扱っているかを知るために。

また、時間の経過とともに、<appSettings>アプリの多くの部分がそこにデータを配置し始めた場合、古いコードはかなり複雑で面倒なものになる可能性があります（古いwindows.iniファイルを覚えていますか？:-)）。

可能であれば、独自の構成セクションを使用することをお勧めします-.NET 2.0を使用すると、非常に簡単になります。

• a）コードで構成設定を定義し、タイプセーフでチェックする
• B）あなたはきれいに分離することができYOUR皆のから設定を。また、設定コードを再利用することもできます！

CodeProjectの.NET 2.0構成システムをわかりやすく説明する一連の非常に優れた記事があります。

1. .NET 2.0構成の謎を解明する

2. .NET 2.0構成の謎を解読する

3. .NET 2.0構成の謎を解く

強くお勧めします！Jon Ristaは、.NET 2.0の構成システムを説明する素晴らしい仕事をしました。

アプリケーションの設定はデザイナーから制御できるため（通常、デフォルトではSettings.settingsファイルが存在します）、変更が簡単で、強く型付けされたプロパティのように表示されるSettingsクラスを介してプログラムから設定にアクセスできます。アプリケーションレベルとユーザーレベルの設定だけでなく、ロールバックのデフォルト設定も使用できます。

これは.NET 2.0以降で利用可能であり、（私の知る限り）他の方法での使用は推奨されません。

詳細については、msdn.microsoft.com / en-us / library / k4s6c3a0.aspxを参照してください。

しばらく前に見つけたパターンを使用していますが、基本的なxmlタグを使用しますが、設定を静的構成クラスにラップします。だから-DIY App.Settings。

DotNetPearls静的構成パターン

このようにすると、次のことができます。

• 異なる環境（dev、test、prod）に異なる設定値のセットを使用する
• 各設定に適切なデフォルトを提供する
• 値の定義とインスタンス化の方法を制御する

設定するのは面倒ですが、パフォーマンスが良く、キー名への参照を隠し、強く型付けされます。この種のパターンは、アプリケーションによって変更されない構成に対しては適切に機能しますが、おそらく変更のサポートにおいても機能する可能性があります。

構成：

<add key="machineName" value="Prod" />
<add key="anotherMachineName" value="Test" />
<add key="EnvTypeDefault" value="Dev" />

<add key="RootURLProd" value="http://domain.com/app/" />
<add key="RootURLTest" value="http://test.domain.com/app/" />
<add key="RootURLDev" value="http://localhost/app/" />

<add key="HumanReadableEnvTypeProd" value="" />
<add key="HumanReadableEnvTypeTest" value="Test Mode" />
<add key="HumanReadableEnvTypeDev" value="Development Mode" />

構成クラス：

using System;
using System.Collections.Generic;
using System.Web;
using WebConfig = System.Web.Configuration.WebConfigurationManager;

    public static class Config
    {
        #region Properties

        public static string EnvironmentType { get; private set; }

        public static Uri RootURL { get; private set; }

        public static string HumanReadableEnvType { get; private set; }

        #endregion

        #region CTOR

        /// <summary>
        /// Initializes all settings when the app spins up
        /// </summary>
        static Config()
        {
            // Init all settings here to prevent repeated NameValueCollection lookups
            // Can increase performance on high volume apps

            EnvironmentType =
                WebConfig.AppSettings[System.Environment.MachineName] ??
                "Dev";

            RootURL =
                new Uri(WebConfig.AppSettings["RootURL" + EnvironmentType]);

            HumanReadableEnvType =
                WebConfig.AppSettings["HumanReadableEnvType" + Config.EnvironmentType] ??
                string.Empty;
        }

        #endregion
    }

の設定の長所と短所を理解するにapp.configは、両方の技術的な詳細を確認することをお勧めします。処理するためのソースコードを見つけることができるリンクを含め、以下に技術的な詳細を説明します。

私が彼らと働いたときに私が認識したことを簡単に要約しましょう（注：同じことがweb.configWebサイト/ Webアプリケーションのファイルにも当てはまります）：

.NETのapplicationSettings
（ソースコードと技術的な詳細を表示するには、上記をクリックしてください）

長所

• （serializeAsプロパティを介して）オブジェクト型を含む型付きデータを格納できます。

• ユーザーとアプリケーションのスコープがあり、デフォルト値を保存できます

• Visual Studioの構成セクションでサポートされています

• 長い文字列や特殊文字を含むデータは非常によくサポートされています（たとえば、二重引用符を含む埋め込みJSON文字列）

短所

• ユーザー設定はユーザープロファイルの別の場所に保存されており（暗号化されたパスを使用）、クリーンアップが難しい場合があります

• アプリケーションのスコープ設定は、アプリケーションの実行中は読み取り専用です（実行時に変更できるのはユーザースコープ設定のみです）。

• Visual Studioの設定デザイナーによって構築された読み取り/書き込みメソッドコードで、サードパーティツールから直接提供されたものではありません（回避策については、上記のリンクを参照してください）

.NET
アップデートの AppSettings ：.NET CoreのAppSettings
（ソースコードと技術的な詳細を表示するには、上をクリックしてください）

長所

• 「軽量」、つまり扱いやすい

• アプリケーションの実行時の読み取りおよび書き込みアクセス

• これらは、
  インターネットインフォメーションサービス（IIS）マネージャーで 管理者が簡単に編集でき
  ^{ます（機能ビュー->アプリケーションの設定。アイコンの名前は、AppSettingsのみを処理でき、ApplicationSettingsは処理できないため、誤解を招く点に注意してください）}

短所

• 文字列データのみをサポートします。文字列の長さと特殊文字は制限されています

• ユーザースコープがありません

• デフォルト値をサポートしていません

• Visual Studioの構成セクションでは直接サポートされていません

単一の値を格納およびアクセスするためのより単純なバージョンを使用するのが好きです。

<appSettings>
    <add key="MyConfigKey" value="true"/>
</appSettings>

デフォルト値を許可するタイプセーフな方法で値にアクセスするユーティリティクラスを作成しました。デフォルトが提供されていない場合、役立つ例外メッセージが表示されます。

ここでクラスを表示/ダウンロードできます。

http://www.drewnoakes.com/code/util/app-settings-util/