web-dev-qa-db-ja.com

開発環境と運用環境で異なるWeb.configを使用する

開発環境または運用環境で実行されるASP.NETアプリケーションに応じて、ASP.NETアプリケーションで異なるデータベース接続文字列とSMTPサーバーアドレスを使用する必要があります。

アプリケーションは、 WebConfigurationManager.AppSettings プロパティを介してWeb.configファイルから設定を読み取ります。

Build/Publishコマンドを使用してFTP経由でアプリケーションを運用サーバーに展開し、手動でリモートWeb.configを正しいものに置き換えます。

展開プロセスを何らかの形で単純化することは可能ですか？ありがとう！

asp.netvisual-studioconfigurationweb-config
188
Alexander Prokofyev

Visual Studio 2010以降では、ビルド構成に応じてweb.configに変換を適用できるようになりました。

Web.configを作成するときに、ソリューションエクスプローラーでファイルを展開すると、2つのファイルが表示されます。

  • Web.Debug.Config
  • Web.Release.Config

これらには、以下に使用できる変換コードが含まれています

  • 接続文字列を変更する
  • デバッグトレースと設定を削除する
  • エラーページを登録する

詳細については、MSDNの Webアプリケーションプロジェクトの展開のためのWeb.config変換構文 を参照してください。

公式にはサポートされていませんが、非Webアプリケーションapp.configファイルに同じ種類の変換を適用することもできます。プロジェクトファイルを変更してmsbuildに新しいタスクを追加する方法については、 Phil Bolducブログ を参照してください。

これは長い間耐えられます Visual Studio Uservoiceでのリクエスト 。

Visual Studio 2010の拡張機能 以上、 " SlowCheetah 、"を使用して、構成ファイルの変換を作成できます。 Visual Studio 2017.3以降、 SlowCheetahはIDEに統合されました であり、コードベースはMicrosoftによって管理されています。この新しいバージョンはJSON変換もサポートしています。

153
Pierre-Alain Vigeant

Web.configの<appSettings>タグは、独自のキー/値のセットで外部構成をロードするファイル属性をサポートします。これらは、web.configにある設定を上書きするか、それらに追加します。

サイトをインストールする環境に一致するファイル属性を使用して、インストール時にweb.configを変更することにより、これを利用します。これを行うには、インストーラーのスイッチを使用します。

例えば;

<appSettings file=".\EnvironmentSpecificConfigurations\dev.config">

<appSettings file=".\EnvironmentSpecificConfigurations\qa.config">

<appSettings file=".\EnvironmentSpecificConfigurations\production.config">

注意：

  • 属性で指定された.configを変更しても、asp.netワーカープロセスの再起動はトリガーされません。
79
Jason Slocomb

Web展開プロジェクトを検討しましたか？

http://www.Microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en

2008を使用していない場合は、VS2005のバージョンもあります。

24
wulimaster

私も知りたいです。これは問題を特定するのに役立ちます

 <connectionStrings configSource = "connectionStrings.config" />

次に、connectionStrings.configと「{Host} connectionStrings.config」を保持します。それでも問題はありますが、2つの環境で異なるセクションに対してこれを行うと、同じweb.configを展開してバージョン管理できます。

（そして、私はVSを使用しません、ところで。）

12
harpo

NAntビルドスクリプトを使用して、さまざまな環境に展開します。配置先に応じてXPath経由で構成ファイルを変更し、 Beyond Compare を使用して自動的に環境に配置します。

セットアップには1〜2分かかりますが、必要なのは一度だけです。その後、別のコーヒーを飲みながらバッチファイルが引き継ぎます。 :)

こちら 私が見つけた記事。

6
Jeff Sheldon

4つの環境（開発、テスト、ステージング、および本番）がある1つのプロジェクトで、アプリケーションが展開先のマシン名に基づいて適切な構成を選択するシステムを開発しました。

これは私たちのために働いた：

  • 管理者は、開発者が関与することなく（要件）、構成ファイルをいじる必要がない（彼らが嫌いだった）アプリケーションをデプロイできました。
  • マシン名は慣習に従っています。正規表現を使用して名前を照合し、環境内の複数のマシンに展開しました。そして
  • 接続文字列に統合セキュリティを使用しました。これは、パスワードを明かすことなく、設計時に構成ファイルにアカウント名を保持できることを意味します。

この例ではうまく機能しましたが、おそらくどこでも動作しません。

4
dariom

これを行うには、Enterprise Library構成エディターが役立ちます。基本構成ファイルを作成してから、各環境のデルタを作成できます。その後、基本構成とデルタをマージして、環境固有のweb.configを作成できます。情報をご覧ください こちら これは、私ができる以上にあなたをよく案内してくれます。

3
PhilPursglove

ビルド後のステップにすることもできます。デバッグとリリースに加えて「デプロイ」である新しい構成をセットアップし、ビルド後のステップで正しいweb.configをコピーします。

すべてのプロジェクトに自動ビルドを使用し、それらを使用してビルドスクリプトがweb.configファイルを更新して正しい場所を指すようにします。しかし、VSのすべてを実行している場合、それは役に立ちません。

3
Cory Foy

これは、machine.configを使用する大きな利点の1つです。私の最後の仕事では、開発、テスト、および実稼働環境がありました。 machine.configは、接続文字列（適切なdev/test/prod SQLマシンへ）のようなものに使用できます。

実際の本番マシンにアクセスできない場合（共有ホストでホスティング会社を使用している場合など）、これは解決策ではありません。

3
Timothy Khouri