次の方法で共有

開発と運用の間の一般的な構成の違い (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 アプリケーションのさまざまな構成情報が含まれています。 この構成情報の一部は、環境に関係なく同じです。 たとえば、Web.config ファイルの <authentication> および <authorization> 要素内に記述されている認証設定と URL 認可規則は、通常、環境に関係なく同じです。 しかし、外部リソースに関する情報など、その他の構成情報は、通常、環境によって異なります。

データベース接続文字列は、環境に基づいて異なる構成情報の典型的な例です。 Web アプリケーションがデータベース サーバーと通信する際は、まず接続を確立する必要があります。そして、これは接続文字列を介して実現されます。 Web ページまたはデータベースに接続するコード内にデータベース接続文字列を直接ハードコーディングすることは可能ですが、接続文字列の情報が 1 つの、一元化された場所の中に存在するように、 Web.configの <connectionStrings> 要素にそれを配置するのが最適です。 多くの場合、開発中は運用環境の中で使用されるものとは異なるデータベースが使用されます。そのため、その接続文字列情報は環境ごとに固有である必要があります。

Note

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

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

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

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

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

Note

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

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

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

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

ASP.NET アプリケーション内でハンドルされない例外が発生すると、それはランタイムに伝播し、その時点で次の 3 つのいずれかが発生します。

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

ハンドルされない例外が発生した場合に何が起きるかは、Web.config ファイルの <customErrors> セクションに依存します。

アプリケーションを開発してテストする際は、ブラウザー内で例外の詳細を確認すると役立ちます。 ただし、運用環境上のアプリケーション内で例外の詳細を表示することは、潜在的なセキュリティ リスクになります。 さらに、見栄えが悪く、そのウェブサイトの質が低く見られてしまいます。 理想的には、ハンドルされない例外が発生した場合、開発環境内の Web アプリケーションでは例外の詳細を表示し、運用環境内の同じアプリケーションではカスタム エラー ページを表示します。

Note

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

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

トレースを有効にする場合は、運用環境内では必ず無効にしてください。 トレース情報には Cookie、セッション データ、その他の潜在的な機密情報が含まれているため、運用環境内ではトレースを無効にすることが重要です。 幸い、既定でトレースは無効であり、Trace.axd ファイルには localhost 経由でのみアクセスできます。 開発環境内でこれらの既定の設定を変更する場合は、運用環境内では必ず無効に戻してください。

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

開発と運用環境内で構成設定が異なると、配置プロセスが複雑になります。 前の 2 つのチュートリアルでは、配置プロセスにおいてすべての必要なファイルを開発から運用にコピーする必要がありました。しかし、そのアプローチは、両方の環境内で構成情報が同じ場合にのみ機能します。 さまざまな構成情報が含まれるアプリケーションを配置するための、さまざまな手法があります。 ホストされた Web アプリケーション向けの、これらのオプションのいくつかを挙げてみましょう。

運用環境構成ファイルの手動での配置

最も単純なアプローチは、2 つのバージョンの Web.config ファイルを維持することです。1 つは開発環境用で、1 つは運用環境用です。 サイトを運用環境に配置するには、Web.config ファイルを "除く" すべての開発環境内のファイルを、運用サーバーにコピーする必要があります。 その代わりとして、運用環境固有の Web.config ファイルを運用環境にコピーします。

このアプローチはあまり洗練されていませんが、構成情報は変更される頻度が低いため、これを実装するのは簡単です。 これは、1 つの Web サーバー上でホストされ、構成情報が変更される頻度が低い、小規模な開発チームによるアプリケーションに最適です。 これは、スタンドアロンの FTP クライアントを使用して、アプリケーション ファイルを手動で配置する場合には最も妥当です。 Visual Studio の [Web サイトのコピー] ツールまたは [発行] オプションを使用する場合は、配置する前に、まず開発環境固有の Web.config ファイルを運用環境固有のものと交換し、配置の完了後にそれを交換し直す必要があります。

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

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

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

Web 配置プロジェクト アドインを使用した構成の相違点の管理

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

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

このディレクトリにコピーされる構成情報を、次の方法でカスタマイズできます。

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

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

Web 配置プロジェクトの使用の詳細については、MSDN Magazine 2007 年 4 月号の、この Web 配置プロジェクトの記事を確認するか、このチュートリアルの最後にある「もっと読む」セクション内のリンクを参照してください。

Note

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

まとめ

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

プログラミングに満足!

もっと読む

この記事で説明したトピックの詳細については、次のリソースを参照してください。

前へ次へ