開発と運用の間の一般的な構成の違い (C#)

  • [アーティクル]

作成者: Scott Mitchell

PDF のダウンロード

以前のチュートリアルでは、関連するすべてのファイルを開発環境から運用環境にコピーして、Web サイトをデプロイしました。 ただし、環境間に構成の違いがあることは珍しくありません。そのため、各環境に固有の Web.config ファイルが必要です。 このチュートリアルでは、一般的な構成の違いについて説明し、個別の構成情報を維持するための戦略について説明します。

はじめに

最後の 2 つのチュートリアルでは、単純な Web アプリケーションのデプロイについて説明しました。 「 FTP クライアントを使用したサイトの展開 」チュートリアルでは、スタンドアロンの FTP クライアントを使用して、開発環境から運用環境に必要なファイルをコピーする方法について説明しました。 前のチュートリアル「 Visual Studio を使用したサイトの展開」では、Visual Studio の [Web サイトのコピー] ツールと [発行] オプションを使用した展開について説明しました。 どちらのチュートリアルでも、運用環境のすべてのファイルは開発環境上のファイルのコピーでした。 ただし、運用環境の構成ファイルが開発環境の構成ファイルと異なることがあります。 Web アプリケーションの構成はファイルに Web.config 格納され、通常はデータベース、Web、電子メール サーバーなどの外部リソースに関する情報が含まれます。 また、ハンドルされない例外が発生したときに実行するアクションのコースなど、特定の状況でのアプリケーションの動作も示します。

Web アプリケーションをデプロイする場合は、正しい構成情報が運用環境で終了することが重要です。 ほとんどの場合、 Web.config 開発環境のファイルをそのまま運用環境にコピーすることはできません。 代わりに、 のカスタマイズされたバージョン Web.config を運用環境にアップロードする必要があります。 このチュートリアルでは、より一般的な構成の違いをいくつか簡単に確認します。また、環境間で異なる構成情報を維持するためのいくつかの手法もまとめられています。

開発環境と運用環境の一般的な構成の違い

ファイル Web.config には、ASP.NET アプリケーションの構成情報が含まれています。 この構成情報の一部は、環境に関係なく同じです。 たとえば、ファイル<authentication>と 要素でWeb.configスペルアウトされた認証設定と <authorization> URL 承認規則は、通常、環境に関係なく同じです。 ただし、外部リソースに関する情報など、その他の構成情報は、通常、環境によって異なります。

データベース接続文字列は、環境によって異なる構成情報の主要な例です。 Web アプリケーションがデータベース サーバーと通信するときは、まず接続を確立する必要があります。これは、接続文字列によって実現されます。 データベース接続文字列 Web ページまたはデータベースに接続するコードに直接ハードコーディングすることもできますが、接続文字列情報が一元化された単一の場所に配置されるように、その要素を配置Web.config<connectionStrings>することをお勧めします。 多くの場合、開発中に運用環境で使用されるデータベースとは異なるデータベースが使用されます。そのため、接続文字列情報は環境ごとに一意である必要があります。

注意

今後のチュートリアルでは、データドリブン アプリケーションのデプロイについて説明します。その時点で、データベース接続文字列を構成ファイルに格納する方法の詳細について説明します。

開発環境と運用環境の意図された動作は大きく異なります。 開発環境の Web アプリケーションは、小規模な開発者グループによって作成、テスト、デバッグされています。 運用環境では、同じアプリケーションが多数の異なる同時ユーザーによってアクセスされています。 ASP.NET には、開発者がアプリケーションをテストおよびデバッグするのに役立つ多くの機能が含まれていますが、運用環境でのパフォーマンスとセキュリティ上の理由から、これらの機能を無効にする必要があります。 このような構成設定をいくつか見てみましょう。

パフォーマンスに影響する構成設定

ASP.NET ページが初めてアクセスされたとき (または変更後に初めて) アクセスする場合は、宣言型マークアップをクラスに変換し、このクラスをコンパイルする必要があります。 Web アプリケーションで自動コンパイルを使用する場合は、ページの分離コード クラスもコンパイルする必要があります。 ファイル<compilation>の 要素を使用して、さまざまなコンパイル オプションをWeb.config構成できます。

debug 属性は、 要素の中で最も重要な属性の <compilation> 1 つです。 属性が debug "true" に設定されている場合、コンパイルされたアセンブリにはデバッグ シンボルが含まれます。これは、Visual Studio でアプリケーションをデバッグするときに必要になります。 ただし、デバッグ シンボルはアセンブリのサイズを大きくし、コードの実行時に追加のメモリ要件を課します。 さらに、 属性が debug "true" に設定されている場合、 によって WebResource.axd 返されるコンテンツはキャッシュされません。つまり、ユーザーがページにアクセスするたびに、 によって WebResource.axd返される静的コンテンツを再ダウンロードする必要があります。

注意

WebResource.axd は、ASP.NET 2.0 で導入された組み込みの HTTP ハンドラーであり、スクリプト ファイル、イメージ、CSS ファイル、その他のコンテンツなどの埋め込みリソースの取得にサーバー コントロールが使用します。 のしくみ WebResource.axd と、それを使用してカスタム サーバー コントロールから埋め込みリソースにアクセスする方法の詳細については、「を使用した URL を使用 WebResource.axdした埋め込みリソースへのアクセス」を参照してください。

通常、 <compilation> 要素の debug 属性は開発環境で "true" に設定されます。 実際、Web アプリケーションをデバッグするには、この属性を "true" に設定する必要があります。Visual Studio から ASP.NET アプリケーションをデバッグしようとして、 debug 属性が "false" に設定されている場合、Visual Studio には、属性が "true" に設定されるまで debug アプリケーションをデバッグできないことを示すメッセージが表示され、この変更を行うことができます。

運用環境では、debugパフォーマンスへの影響のため、 属性を "true" に設定しないでください。 このトピックの詳細な説明については、 Scott Guthrie のブログ記事「 Don't run Production ASP.NET Applications With debug="true" Enabled」を参照してください。

カスタム エラーとトレース

ASP.NET アプリケーションで未処理の例外が発生すると、ランタイムにバブルアップし、その時点で次の 3 つのいずれかが発生します。

  • 汎用ランタイム エラー メッセージが表示されます。 このページでは、ランタイム エラーが発生したことをユーザーに通知しますが、エラーに関する詳細は提供しません。
  • 例外の詳細メッセージが表示されます。これには、スローされた例外に関する情報が含まれます。
  • カスタム エラー ページが表示されます。これは、必要なメッセージを表示する作成した ASP.NET ページです。

ハンドルされない例外が発生した場合の処理は、ファイルのWeb.config<customErrors>セクションによって異なります。

アプリケーションを開発してテストするときは、ブラウザーで例外の詳細を確認するのに役立ちます。 ただし、運用環境のアプリケーションで例外の詳細を表示することは、潜在的なセキュリティ リスクです。 さらに、それはお世辞であり、あなたのウェブサイトはプロフェッショナルに見えるようになります。 理想的には、未処理の例外が発生した場合、開発環境の Web アプリケーションに例外の詳細が表示され、運用環境の同じアプリケーションにカスタム エラー ページが表示されます。

注意

既定 <customErrors> のセクション設定では、ページが localhost 経由でアクセスされている場合にのみ例外の詳細メッセージが表示され、それ以外の場合は汎用ランタイム エラー ページが表示されます。 これは理想的ではありませんが、既定の動作では、ローカル以外の訪問者に例外の詳細が表示されていないことを知るのも安心です。 今後のチュートリアルでは、 <customErrors> セクションの詳細を確認し、運用環境でエラーが発生したときにカスタム エラー ページを表示する方法を示します。

開発中に役立つもう 1 つの ASP.NET 機能は、トレースです。 トレースを有効にすると、各受信要求に関する情報が記録され、 Trace.axd最近の要求の詳細を表示するための特別な Web ページが提供されます。 で 要素Web.configを使用してトレースを<trace>有効にして構成できます。

トレースを有効にする場合は、運用環境で無効になっていることを確認します。 トレース情報には Cookie、セッション データ、およびその他の機密情報が含まれているため、運用環境でトレースを無効にすることが重要です。 良いニュースは、既定ではトレースが無効になっており Trace.axd 、ファイルには localhost を介してのみアクセスできるということです。 開発中にこれらの既定の設定を変更する場合は、運用環境でオフになっていることを確認してください。

個別の構成情報を維持するための手法

開発環境と運用環境で構成設定が異なると、デプロイ プロセスが複雑になります。 前の 2 つのチュートリアルでは、展開プロセスでは必要なすべてのファイルを開発から運用環境にコピーする必要がありますが、この方法は両方の環境で構成情報が同じ場合にのみ機能します。 さまざまな構成情報を使用してアプリケーションをデプロイするためのさまざまな手法があります。 ホストされている Web アプリケーションに対して、これらのオプションの一部をカタログ化してみましょう。

運用環境の構成ファイルを手動で展開する

最も簡単な方法は、開発環境用と運用環境用の Web.config 2 つのバージョンのファイルを維持することです。 サイトを運用環境に展開するには、ファイルを 除き 、開発環境のすべてのファイルを運用環境の運用サーバーにコピーする Web.config 必要があります。 代わりに、運用環境固有 Web.config のファイルが運用環境にコピーされます。

この方法はあまり高度ではありませんが、構成情報が変更される頻度が低いため、簡単に実装できます。 これは、1 つの Web サーバーでホストされ、構成情報の変更頻度が低い小規模な開発チームを持つアプリケーションに最適です。 スタンドアロン FTP クライアントを使用してアプリケーション ファイルを手動でデプロイする場合に最も有効です。 Visual Studio の [Web サイトのコピー] ツールまたは [発行] オプションを使用する場合は、展開の前に展開固有 Web.config のファイルと運用環境固有のファイルを入れ替えてから、展開の完了後に元に戻す必要があります。

ビルドまたは配置プロセス中に構成を変更する

これまでの議論では、アドホックなビルドとデプロイのプロセスが想定されています。 多くの大規模なソフトウェア プロジェクトには、オープンソース、自宅で成長した、またはサードパーティ製のツールを使用する、より正式なプロセスがあります。 このようなプロジェクトでは、ビルドまたはデプロイ プロセスをカスタマイズして、構成情報を運用環境にプッシュする前に適切に変更できます。 MSBuild、NAnt、またはその他のビルド ツールを使用して Web アプリケーションをビルドする場合は、ビルド ステップを追加して、運用環境固有のWeb.config設定を含むようにファイルを変更できます。 または、展開ワークフローでプログラムによってソース管理サーバーに接続し、適切な Web.config ファイルを取得することもできます。

運用環境に適切な構成情報を取得するための実際のアプローチは、ツールとワークフローによって大きく異なります。 そのため、このトピックについては詳しく説明しません。 MSBuild や NAnt などの一般的なビルド ツールを使用している場合は、Web 検索を使用して、これらのツールに固有のデプロイに関する記事とチュートリアルを見つけることができます。

Web 配置プロジェクトを使用した構成の違いの管理 Add-In

2006 年に、Microsoft は Visual Studio 2005 用 Web 開発プロジェクト Add-In をリリースしました。 Visual Studio 2008 用の Add-In は、2008 年にリリースされました。 この Add-In を使用すると、ASP.NET 開発者は Web アプリケーション プロジェクトと共に別の Web 配置プロジェクトを作成し、ビルド時に Web アプリケーションを明示的にコンパイルし、ファイルをコピーしてローカル出力ディレクトリに配置できます。 Web アプリケーション プロジェクトでは、バックグラウンドで MSBuild が使用されます。

既定では、開発環境の Web.config ファイルは出力ディレクトリにコピーされますが、Web 配置プロジェクトを設定して、

次の方法でこのディレクトリにコピーされる構成情報。

  • ファイル セクションの置換を使用して Web.config 、置き換えるセクションと、置換テキストを含む XML ファイルを指定します。
  • 外部構成ソース ファイルへのパスを指定します。 このオプションを選択すると、Web 配置プロジェクトは特定 Web.config のファイルを (開発環境で使用されるファイルではなく Web.config ) 出力ディレクトリにコピーします。
  • Web 配置プロジェクトで使用される MSBuild ファイルにカスタム 規則を追加します。

Web アプリケーションを配置するには、Web 配置プロジェクトをビルドし、プロジェクトの出力フォルダーから運用環境にファイルをコピーします。

Web 配置プロジェクトの使用の詳細については、MSDN マガジンの 2007 年 4 月号のこの Web 配置プロジェクトに関する記事をチェックするか、このチュートリアルの最後にある「その他の読み取り」セクションのリンクを参照してください。

注意

Web 配置プロジェクトは Visual Studio Add-In として実装されており、Visual Studio Express エディション (Visual Web Developer を含む) はアドインをサポートしていないため、Visual Web Developer で Web 配置プロジェクトを使用することはできません。

まとめ

開発中の Web アプリケーションの外部リソースと動作は、通常、同じアプリケーションが運用環境にある場合とは異なります。 たとえば、データベース接続文字列、コンパイル オプション、ハンドルされない例外が発生した場合の動作は、一般的に環境によって異なります。 デプロイ プロセスでは、これらの違いに対応する必要があります。 このチュートリアルで説明したように、最も簡単な方法は、代替構成ファイルを運用環境に手動でコピーすることです。 Web 配置プロジェクト Add-In を使用する場合や、このようなカスタマイズに対応できるより正式なビルドまたは配置プロセスを使用する場合は、よりエレガントなソリューションが可能です。

プログラミングに満足!

もっと読む

このチュートリアルで説明するトピックの詳細については、次のリソースを参照してください。

前へ次へ