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

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

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

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

展開のプロセスを何らかの方法で簡略化することは可能ですか？ありがとう！

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変換もサポートしています。

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

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

例えば;

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

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

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

注意：

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

Webデプロイメントプロジェクトを調べましたか？

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

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

私も知りたいです。これは私にとって問題を切り分けるのに役立ちます

<connectionStrings configSource = "connectionStrings.config" />

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

（そして、私はVSを使用していません。）

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

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

ここだ、私はそれで見つかった記事。

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

これは私たちにとってうまくいきました：

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

この場合はうまくいきましたが、どこでもうまくいくとは限りません。

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

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

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

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

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

拡張機能「Configuration Transform」を使用することもできます。「SlowCheetah」と同じように機能します。