204

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

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

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

どういうわけか展開のプロセスを簡素化することは可能ですか? ありがとう！

4

10 に答える 10

172

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

于 2010-06-17T18:46:19.823 に答える
85

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 ワーカー プロセスの再起動はトリガーされません。
于 2008-11-20T15:55:36.083 に答える
24

Web 展開プロジェクトを調べましたか?

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

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

于 2008-11-20T14:36:50.207 に答える
13

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

<connectionStrings configSource="connectionStrings.config"/>

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

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

于 2008-11-20T14:38:53.167 に答える
6

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

セットアップには 1 ～ 2 分かかりますが、一度だけ行う必要があります。次に、コーヒーをもう 1 杯飲みに行く間、バッチ ファイルが引き継ぎます。:)

その中で見つけた記事がこちら。

于 2008-11-20T14:54:44.023 に答える
5

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

これは、次の理由でうまくいきました。

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

この例ではうまく機能しましたが、おそらくどこでも機能するとは限りません。

于 2008-11-20T15:24:55.960 に答える
3

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

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

于 2008-11-20T15:13:03.270 に答える
3

Enterprise Library 構成エディターは、これを行うのに役立ちます。ベース構成ファイルを作成してから、各環境のデルタを作成できます。その後、ベース構成とデルタをマージして、環境固有の web.config を作成できます。こちらの情報をご覧ください。私よりもうまく説明できます。

于 2008-11-20T14:45:14.993 に答える
3

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

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

于 2008-11-20T14:52:53.200 に答える