Visual Studio を使用した ASP.NET Web 配置: Web.config ファイル変換

著者: Tom Dykstra

スターター プロジェクトのダウンロード

このチュートリアル シリーズでは、Visual Studio 2012 または Visual Studio 2010 を使用して、ASP.NET Web アプリケーションを Azure App Service Web Apps またはサードパーティのホスティング プロバイダーに配置 (発行) する方法について説明します。 このシリーズについては、シリーズの最初のチュートリアルをご覧ください。

概要

このチュートリアルでは、別の配置先の環境に配置するときに Web.config ファイルを変更するプロセスを自動化する方法について説明します。 ほとんどのアプリケーションには、Web.config ファイルに、アプリケーションが配置時に変更する必要がある設定があります。 このような変更を行うプロセスを自動化すると、配置するたびに手動で面倒なミスが発生しやすい作業を行う必要がなくなります。

リマインダー: チュートリアルを進めていて、エラー メッセージが表示される場合や、うまくいかない場合は、必ずトラブルシューティングのページをご確認ください。

Web.config 変換と Web 配置パラメーターの比較

Web.config ファイルの設定を変更するプロセスを自動化するには、Web.config 変換と Web 配置パラメーターの 2 つの方法があります。 Web.config 変換ファイルには、配置時に Web.config ファイルを変更する方法を指定する XML マークアップが含まれています。 特定のビルド構成と特定の発行プロファイルに対して、さまざまな変更を指定できます。 既定のビルド構成はビルドとリリースですが、カスタム ビルド構成を作成することもできます。 発行プロファイルは通常、配置先の環境に対応します。 (発行プロファイルの詳細については、「テスト環境としての IIS への配置」チュートリアルを参照してください。)

Web 配置パラメーターは、配置時に構成する必要があるさまざまな種類の設定 (Web.config ファイル内の設定など) を指定するために使用できます。 Web.config ファイルの変更を指定するために使用する場合、Web 配置パラメーターの設定がより複雑になりますが、配置するまで設定する値がわからない場合に便利です。 たとえば、エンタープライズ環境では、展開パッケージを作成し、運用環境にインストールするように IT 部門の担当者に渡す場合がありますが、その担当者は、あなたが知らない接続文字列やパスワードを入力できる必要があります。

このチュートリアル シリーズで説明するシナリオでは、Web.config ファイルに対して行う必要があることはすべて事前に把握しているため、Web 配置パラメーターを使用する必要はありません。 使用するビルド構成によって異なる変換と、使用する発行プロファイルによって異なる変換を構成します。

Azure での Web.config 設定の指定

変更する Web.config ファイルの設定が <connectionStrings> または <appSettings> 要素内にあり、Azure App Service の Web Apps に配置している場合は、配置中に変更を自動化するための別のオプションがあります。 Web アプリの管理ポータル ページの [構成] タブで、有効にする設定を Azure に入力できます ([アプリの設定] と [接続文字列] セクションまで下にスクロールしてください)。 プロジェクトを配置すると、Azure によって変更が自動的に適用されます。 詳細については、「Windows Azure Web サイト: アプリケーション文字列と接続文字列のしくみ」を参照してください。

既定の変換ファイル

ソリューション エクスプローラーで、Web.config を展開して、2 つの既定のビルド構成用に既定で作成された Web.Debug.config 変換ファイルと Web.Release.config 変換ファイルを確認します。

カスタム ビルド構成の変換ファイルは、Web.config ファイルを右クリックし、コンテキスト メニューから [構成変換の追加] を選択することで作成できます。 このチュートリアルでは、カスタム ビルド構成を作成していないため、これを行う必要はなく、メニュー オプションは無効になっています。

後で、さらに 3 つの変換ファイルを作成します。各変換ファイルは、テスト環境、ステージング環境、運用環境の発行プロファイルにそれぞれ 1 つずつです。 配置先環境によって異なるため、発行プロファイル変換ファイルで処理する設定の一般的な例は、テスト環境と運用環境では異なる WCF エンドポイントです。 発行プロファイルの変換ファイルは、後のチュートリアルで、発行プロファイルを作成した後で作成します。

デバッグ モードを無効にする

配置先環境ではなくビルド構成に依存する設定の例として、debug 属性があります。 リリース ビルドでは、配置先の環境にかかわらず、デバッグを無効にするのが一般的です。 そのため、既定では、Visual Studio プロジェクト テンプレートは、compilation 要素から debug 属性を削除するコードを含む Web.Release.config 変換ファイルを作成 します。 既定の Web.Release.config を次に示します。コメント アウトされた変換コードのサンプルに加えて、debug 属性を削除するコードが compilation 要素に含まれています。

<?xml version="1.0" encoding="utf-8"?>

<!-- For more information on using web.config transformation visit https://go.microsoft.com/fwlink/?LinkId=125889 -->

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!--
    In the example below, the "SetAttributes" transform will change the value of 
    "connectionString" to use "ReleaseSQLServer" only when the "Match" locator 
    finds an attribute "name" that has a value of "MyDB".
    
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>
  -->
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <!--
      In the example below, the "Replace" transform will replace the entire 
      <customErrors> section of your web.config file.
      Note that because there is only one customErrors section under the 
      <system.web> node, there is no need to use the "xdt:Locator" attribute.
      
      <customErrors defaultRedirect="GenericError.htm"
        mode="RemoteOnly" xdt:Transform="Replace">
        <error statusCode="500" redirect="InternalError.htm"/>
      </customErrors>
    -->
  </system.web>
</configuration>

この xdt:Transform="RemoveAttributes(debug)" 属性は、配置された Web.config ファイル内の system.web/compilation 要素から debug 属性を削除することを指定します。 これは、リリース ビルドを配置するたびに行われます。

エラー ログアクセスを管理者に制限する

アプリケーションの実行中にエラーが発生した場合、アプリケーションはシステムによって生成されたエラー ページの代わりに一般的なエラー ページを表示し、エラー ログとレポートに El mah NuGet パッケージを使用します。 アプリケーションの Web.config ファイル内の customErrors 要素は、エラー ページを指定します。

<customErrors mode="RemoteOnly" defaultRedirect="~/GenericErrorPage.aspx">
  <error statusCode="404" redirect="~/GenericErrorPage.aspx" />
</customErrors>

エラー ページを表示するには、customErrors 要素の mode 属性を一時的に "RemoteOnly" から "On" に変更し、Visual Studio からアプリケーションを実行します。 Studentsxxx.aspx など、無効な URL を要求してエラーを発生させます。 IIS によって生成された「リソースが見つかりません」 というエラー ページの代わりに、GenericErrorPage.aspx ページが表示されます。

エラー ログを表示するには、URL のポート番号の後をすべて elmah.axd (たとえば http://localhost:51130/elmah.axd) に置き換えて、Enter キーを押します。

完了したら、必ず customErrors 要素を "RemoteOnly" モードに戻してください。

開発用コンピューターでは、エラー ログ ページへの自由なアクセスを許可すると便利ですが、運用環境ではセキュリティ 上のリスクになります。 運用サイトの場合は、エラー ログへのアクセスを管理者に制限する認可規則を追加し、この制限がテスト環境およびステージング環境でも機能することを確認する必要があります。 したがって、これもリリース ビルドをデプロイするたびに実装する変更の 1 つであるため、Web.Release.config ファイルに属します。

次に示すように、Web.Release.config を開き、configuration タグを閉じる直前に新しい location 要素を追加します。

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!--
    In the example below, the "SetAttributes" transform will change the value of 
    "connectionString" to use "ReleaseSQLServer" only when the "Match" locator 
    finds an attribute "name" that has a value of "MyDB".
    
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>
  -->
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <!--
      In the example below, the "Replace" transform will replace the entire 
      <customErrors> section of your web.config file.
      Note that because there is only one customErrors section under the 
      <system.web> node, there is no need to use the "xdt:Locator" attribute.
      
      <customErrors defaultRedirect="GenericError.htm"
        mode="RemoteOnly" xdt:Transform="Replace">
        <error statusCode="500" redirect="InternalError.htm"/>
      </customErrors>
    -->
  </system.web>
  <location path="elmah.axd" xdt:Transform="Insert">
    <system.web>
      <authorization>
        <allow roles="Administrator" />
        <deny users="*" />
      </authorization>
    </system.web>
  </location>
</configuration>

Transform 属性の値 "Insert" は、このlocation 要素を Web.config ファイル内の既存の location 要素に兄弟として追加されます。 ([クレジットの更新] ページの認可規則を指定する location 要素が既に 1 つあります。)

これで、変換をプレビューして、正しくコーディングされていることを確認できます。

ソリューション エクスプローラーで、Web.Release.config を右クリックし、[変換のプレビュー] をクリックします。

左側の開発用の Web.config ファイル、右側に配置された Web.config ファイルが表示され、変更点が強調表示されているページが開きます。

(プレビューでは、変換を書き込んでいない追加の変更に気付く場合があります。これには、通常、機能に影響しない空白の削除が含まれます。)

配置後にサイトをテストする場合は、認可規則が有効であることを確認するテストも行います。

Note

セキュリティ上の注意 運用アプリケーションでは、決してエラーの詳細を一般公開したり、その情報をパブリックな場所に保存したりしないでください。 攻撃者は、エラー情報を使用してサイトの脆弱性を検出できます。 独自のアプリケーションで ELMAH を使用する場合は、セキュリティ リスクを最小限に抑えるように ELMAH を構成します。 このチュートリアルの ELMAH の例は、推奨される構成ではありません。 これは、アプリケーションがファイルを作成できる必要があるフォルダーを処理する方法を示すために選択された例です。 詳細については、「ELMAH エンドポイントのセキュリティ保護」を参照してください。

発行プロファイルの変換ファイルで処理する設定

一般的なシナリオは、Web.config ファイルの設定を、配置する環境ごとに異なるものにすることです。 たとえば、WCF サービスを呼び出すアプリケーションでは、テスト環境と運用環境で異なるエンドポイントが必要になる場合があります。 Contoso University アプリケーションには、この種の設定も含まれています。 この設定は、サイトのページに表示されるインジケーターを制御し、開発、テスト、本番など、どの環境にいるかを示します。 設定値は、アプリケーションが Site.Master マスター ページのメイン見出しに "(Dev)" または "(Test)" のどちらを追加するかを決定します。

アプリケーションがステージング環境または運用環境で実行されている場合、環境インジケーターは省略されます。

Contoso University の Web ページは、Web.config ファイルの appSettings で設定された値を読み取り、アプリケーションがどの環境で実行されているかを判断します。

<appSettings>
    <add key="Environment" value="Dev" />
</appSettings>

この値は、テスト環境では "Test"、ステージング環境と運用環境では "Prod" にする必要があります。

変換ファイル内の次のコードは、この変換を実装します。

<appSettings>
    <add key="Environment" value="Test" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>

xdt:Transform 属性値 "SetAttributes" は、この変換の目的が、Web.config ファイル内の既存の要素の属性値を変更することであることを示しています。 xdt:Locator 属性値 "Match(key)" は、変更される要素が、ここで指定された key 属性と一致する key 属性を持つものであることを示します。 add 要素の他の唯一の属性は value で、これが配置された Web.config ファイルで変更される属性です。 ここで示すコードにより、Environment appSettings要素のvalue属性が、デプロイされる Web.config ファイルで "Test" に設定されます。

この変換は、まだ作成していない発行プロファイルの変換ファイルに属します。 テスト環境、ステージング環境、運用環境の発行プロファイルを作成するときに、この変更を実装する変換ファイルを作成して更新します。 これは、「IISへの配置」と「運用環境への配置」チュートリアルで行います。

Note

この設定は <appSettings> 要素内にあるため、Azure App Service の Web Apps に配置するときに変換を指定する別の方法があります。詳細については、このトピックの前半にある「Azure での Web.config 設定の指定」を参照してください。

接続文字列の設定

既定の変換ファイルには接続文字列を更新する方法を示す例が含まれていますが、ほとんどの場合、発行プロファイルで接続文字列を指定できるため、接続文字列変換を設定する必要はありません。 これは、「IISへの配置」と「運用環境への配置」チュートリアルで行います。

まとめ

これで、発行プロファイルを作成する前に、Web.config 変換でできることをできる限り行い、配置される Web.config ファイルに含まれる内容のプレビューを確認することができました。

次のチュートリアルでは、プロジェクトのプロパティを設定する必要がある配置のセットアップ作業を行います。

その他の情報

このチュートリアルで説明するトピックの詳細については、Visual Studio および ASP.NET の Web 配置コンテンツ マップの「デプロイ時に Web.config 変換を使用して変換先の Web.config ファイルまたは app.config ファイルの設定を変更する」を参照してください。

前へ次へ