Visual Studio または Visual Web Developer を使用したSQL Server Compactを使用した ASP.NET Web アプリケーションの展開: テスト環境として IIS に展開する - 5/12

作成者: Tom Dykstra

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

この一連のチュートリアルでは、Visual Studio 2012 RC または Visual Studio Express 2012 RC for Web を使用して、SQL Server Compact データベースを含む ASP.NET Web アプリケーション プロジェクトをデプロイ (発行) する方法について説明します。 Web Publish Update をインストールする場合は、Visual Studio 2010 を使用することもできます。 シリーズの概要については、シリーズ の最初のチュートリアルを参照してください。

Visual Studio 2012 の RC リリース後に導入されたデプロイ機能を示すチュートリアルでは、SQL Server Compact以外のSQL Serverエディションを展開する方法と、Azure App Service Web Appsに展開する方法については、「Visual Studio を使用した Web 配置の ASP.NET」を参照してください。

概要

このチュートリアルでは、ローカル コンピューター上の IIS に ASP.NET Web アプリケーションを展開する方法について説明します。

アプリケーションを開発するときは、通常、Visual Studio で実行してテストします。 既定では、Visual Studio Development Server (Cassini とも呼ばれます) を使用していることを意味します。 Visual Studio 開発サーバーを使用すると、Visual Studio の開発中に簡単にテストできますが、IIS とまったく同じようには機能しません。 その結果、Visual Studio でテストするときにアプリケーションが正しく実行される可能性がありますが、ホスト環境で IIS に展開されると失敗します。

次の方法で、アプリケーションをより確実にテストできます。

1. 開発中に Visual Studio でテストする場合は、Visual Studio 開発サーバーではなく、IIS Expressまたは完全な IIS を使用します。 通常、このメソッドは IIS でサイトを実行する方法をより正確にエミュレートします。 ただし、この方法では、デプロイ プロセスをテストしたり、デプロイ プロセスの結果が正しく実行されることを検証したりすることはありません。
2. 後で運用環境に展開するのと同じプロセスを使用して、開発用コンピューター上の IIS にアプリケーションを展開します。 このメソッドは、アプリケーションが IIS で正しく実行されることを検証するだけでなく、展開プロセスを検証します。
3. 運用環境にできるだけ近いテスト環境にアプリケーションをデプロイします。 これらのチュートリアルの運用環境はサードパーティのホスティング プロバイダーであるため、理想的なテスト環境はホスティング プロバイダーとの 2 番目のアカウントになります。 この 2 番目のアカウントはテストにのみ使用しますが、運用アカウントと同じ方法で設定されます。

このチュートリアルでは、オプション 2 の手順を示します。 オプション 3 のガイダンスは、 運用環境へのデプロイ に関するチュートリアルの最後に提供され、このチュートリアルの最後にはオプション 1 のリソースへのリンクがあります。

リマインダー: チュートリアルを進める際にエラー メッセージが表示されたり、何かが機能しない場合は、必ずトラブルシューティング ページをチェックしてください。

中程度の信頼で実行するようにアプリケーションを構成する

IIS をインストールして展開する前に、サイトを一般的な共有ホスティング環境と同じように実行するために、Web.config ファイルの設定を変更します。

ホスティング プロバイダーは通常、 中程度の信頼で Web サイトを実行します。つまり、実行が許可されていないことがいくつかあります。 たとえば、アプリケーション コードは Windows レジストリにアクセスできません。また、アプリケーションのフォルダー階層の外部にあるファイルの読み取りまたは書き込みを行うことはできません。 既定では、アプリケーションはローカル コンピューター上で 高い信頼 で実行されます。つまり、アプリケーションを運用環境に展開すると失敗する可能性があります。 そのため、テスト環境に運用環境をより正確に反映させるには、中程度の信頼で実行するようにアプリケーションを構成します。

アプリケーション Web.config ファイルで、この例に示すように、system.web 要素に trust 要素を追加します。

<configuration>
  <!-- Settings -->
  <system.web>
    <trust level="Medium" />
    <!-- Settings -->
  </system.web>
</configuration>

アプリケーションは、ローカル コンピューター上でも IIS で中程度の信頼で実行されるようになりました。 この設定を使用すると、運用環境で失敗する何かをアプリケーション コードが試みると、できるだけ早くキャッチできます。

注意

Entity Framework Code First Migrationsを使用している場合は、バージョン 5.0 以降がインストールされていることを確認してください。 Entity Framework バージョン 4.3 では、データベース スキーマを更新するために移行に完全な信頼が必要です。

IIS と Web 配置のインストール

開発用コンピューター上の IIS に展開するには、IIS と Web 配置がインストールされている必要があります。 これらは、既定の Windows 7 構成には含まれません。 IIS と Web 配置の両方が既にインストールされている場合は、次のセクションに進んでください。

Web プラットフォーム インストーラーは IIS の推奨構成をインストールし、必要に応じて IIS と Web 配置の前提条件を自動的にインストールするため、WEB プラットフォーム インストーラーを使用して IIS と Web 配置をインストールすることをお勧めします。

Web プラットフォーム インストーラーを実行して IIS と Web 配置をインストールするには、次のリンクを使用します。 IIS、Web 配置、またはその必要なコンポーネントを既にインストールしている場合、Web プラットフォーム インストーラーは不足しているもののみをインストールします。

• WebPI を使用して IIS と Web 配置をインストールする

既定のアプリケーション プールを .NET 4 に設定する

IIS をインストールした後、IIS マネージャーを実行して、.NET Framework バージョン 4 が既定のアプリケーション プールに割り当てられていることを確認します。

Windows の [スタート] メニューから [ 実行] を選択し、「inetmgr」と入力して、[OK] をクリック します。 ( [実行 ] コマンドが [スタート ] メニューにない場合は、Windows キーと R キーを押して開くことができます。または、タスク バーを右クリックし、[ プロパティ] をクリックし、[ スタート メニュー ] タブを選択し、[ カスタマイズ] をクリックして、[ コマンドの実行] を選択します)。

[Connections] ウィンドウで、サーバー ノードを展開し、[アプリケーション プール] を選択します。 [ アプリケーション プール ] ウィンドウで、次の図のように DefaultAppPool が .NET Framework バージョン 4 に割り当てられている場合は、次のセクションに進みます。

2 つのアプリケーション プールのみが表示され、その両方が .NET Framework 2.0 に設定されている場合は、IIS に ASP.NET 4 をインストールする必要があります。

• Windows の [スタート] メニューの [コマンド プロンプト] を右クリックし、[管理者として実行] を選択して、コマンド プロンプト ウィンドウを開きます。 次 に、aspnet_regiis.exe を実行し、次のコマンドを使用して、IIS ASP.NET 4 をインストールします。 (64 ビット システムでは、"Framework" を "Framework64" に置き換えます)。

  cd %windir%\Microsoft.NET\Framework\v4.0.30319
  aspnet_regiis.exe –iru
  

  

  このコマンドにより、.NET Framework 4 用の新しいアプリケーション プールが作成されますが、既定のアプリケーション プールは引き続き 2.0 に設定されます。 .NET 4 を対象とするアプリケーションをそのアプリケーション プールにデプロイするので、アプリケーション プールを .NET 4 に変更する必要があります。

IIS マネージャーを閉じた場合は、もう一度実行し、サーバー ノードを展開し、[アプリケーション プール] をクリックして[アプリケーション プール] ウィンドウをもう一度表示します。

[ アプリケーション プール ] ウィンドウで [ DefaultAppPool] をクリックし、[ 操作 ] ウィンドウで [ 基本設定] をクリックします。

[アプリケーション プールの編集] ダイアログ ボックスで、.NET Frameworkバージョンを v4.0.30319 .NET Frameworkに変更し、[OK] をクリックします。

これで IIS に発行する準備ができました。

IIS への発行

Visual Studio 2010 と Web 配置を使用してデプロイするには、いくつかの方法があります。

• Visual Studio をワンクリックで発行するを使用します。
• 展開パッケージを作成し、IIS マネージャー UI を使用してインストールします。 展開パッケージ は、IIS にサイトをインストールするために必要なすべてのファイルとメタデータを含む.zipファイルで構成されます。
• 配置パッケージを作成し、コマンド ラインを使用してインストールします。

前のチュートリアルでデプロイ タスクを自動化するように Visual Studio を設定したプロセスは、これら 3 つの方法すべてに適用されます。 これらのチュートリアルでは、最初のメソッドを使用します。 展開パッケージの使用については、「ASP.NET 展開コンテンツ マップ」を参照してください。

発行する前に、管理者モードで Visual Studio を実行していることを確認します。 (Windows 7 の [スタート ] メニューで、使用している Visual Studio のバージョンのアイコンを右クリックし、[ 管理者として実行] を選択します)。管理者モードは、ローカル コンピューター上の IIS に発行する場合にのみ発行するために必要です。

ソリューション エクスプローラーで、ContosoUniversity プロジェクト (ContosoUniversity.DAL プロジェクトではありません) を右クリックし、[発行] を選択します。

Web の発行 ウィザードが表示されます。

ドロップダウン リストで[新規...] を選択 <します>。

[ 新しいプロファイル ] ダイアログ ボックスで、「テスト」と入力し、[ OK] をクリックします。

この名前は、前に作成した Web.Test.config 変換ファイルの中央ノードと同じです。 この対応により、このプロファイルを使用して発行するときに Web.Test.config 変換が適用されます。

ウィザードは自動的に [ 接続 ] タブに進みます。

[ サービス URL ] ボックスに「 localhost」と入力します。

[ サイト/アプリケーション ] ボックスに、「 既定の Web サイト/ContosoUniversity」と入力します。

[ 宛先 URL ] ボックスに「」と入力 http://localhost/ContosoUniversityします。

[宛先 URL] 設定は必要ありません。 Visual Studio でアプリケーションのデプロイが完了すると、既定のブラウザーがこの URL に自動的に開きます。 デプロイ後にブラウザーを自動的に開かないようにするには、このボックスを空白のままにします。

[ 接続の検証 ] をクリックして、設定が正しいことと、ローカル コンピューター上の IIS に接続できることを確認します。

緑色のチェックマークは、接続が成功したことを確認します。

[ 次へ ] をクリックして、[ 設定] タブに進みます。

[ 構成] ドロップダウン ボックスは、デプロイするビルド構成を指定します。 既定値は Release です。これは目的の値です。

[移動先のファイルを削除するチェック] ボックスはオフのままにします。 これは最初のデプロイであるため、宛先フォルダーにはまだファイルはありません。

[データベース] セクションで、SchoolContext の [接続文字列] ボックスに次の値を入力します。

Data Source=|DataDirectory|School-Prod.sdf

[実行時にこの接続文字列を使用する] が選択されているため、この接続文字列はデプロイされた Web.config ファイルに配置されます。

また、[SchoolContext] で [Code First Migrationsの適用] を選択します。 このオプションを指定すると、デプロイ プロセスで、初期化子を指定するようにデプロイされた Web.config ファイルが MigrateDatabaseToLatestVersion 構成されます。 この初期化子は、アプリケーションがデプロイ後に初めてデータベースにアクセスするときに、データベースを最新バージョンに自動的に更新します。

[DefaultConnection] の接続文字列 ボックスに、次の値を入力します。

Data Source=|DataDirectory|aspnet-Prod.sdf

[ データベースの更新] はオフのままにします。 メンバーシップ データベースは、App_Dataで .sdf ファイルをコピーすることによってデプロイされます。このデータベースで他の操作を行う展開プロセスは必要ありません。

[ 次へ ] をクリックして、[ プレビュー ] タブに進みます。

[ プレビュー ] タブで、[ プレビューの開始 ] をクリックして、コピーされるファイルの一覧を表示します。

[発行] をクリックします。

Visual Studio が管理者モードでない場合は、アクセス許可エラーを示すエラー メッセージが表示されることがあります。 その場合は、Visual Studio を閉じ、管理者モードで開き、もう一度発行してみてください。

Visual Studio が管理者モードの場合は、[ 出力 ] ウィンドウにビルドと発行が成功したことが報告されます。

ブラウザーが自動的に開き、ローカル コンピューター上の IIS で実行されている Contoso University ホーム ページが表示されます。

テスト環境でのテスト

環境インジケーターに "(Dev)" ではなく "(Test)" が表示されていることに注意してください。これは、環境インジケーターの Web.config 変換が成功したことを示しています。

[ 学生 ] ページを実行して、デプロイされたデータベースに学生がいないことを確認します。 このページを選択すると、Code First によってデータベースが作成され、 メソッドが実行 Seed されるため、読み込みに数分かかる場合があります。 (アプリケーションがまだデータベースへのアクセスを試みていないため、ホーム ページにいたときは、この操作は行われませんでした。

[Instructors] ページを実行して、Code First がインストラクター データを使用してデータベースをシード処理したことを確認します。

[学生] メニューから [学生の追加] を選択し、学生を追加し、[学生] ページで新しい学生を表示して、データベースに正常に書き込むことができることを確認します。

[コース] メニューの [クレジットの更新] を選択します。 [ クレジットの更新] ページには管理者権限が必要であるため、[ ログイン ] ページが表示されます。 前に作成した管理者アカウントの資格情報 ("admin" と "Pas$w0rd") を入力します。 [ クレジットの更新] ページが表示され、前のチュートリアルで作成した管理者アカウントがテスト環境に正しくデプロイされたことを確認します。

プレースホルダー ファイルのみが含まれる Elmah フォルダーが存在することを確認します。

Code First Migrationsの自動 Web.config 変更の確認

デプロイされたアプリケーションの Web.config ファイルを C:\inetpub\wwwroot\ContosoUniversity で開くと、データベースを最新バージョンに自動的に更新するようにCode First Migrations展開プロセスが構成されている場所を確認できます。

デプロイ プロセスでは、データベース スキーマの更新専用に使用するCode First Migrations用の新しい接続文字列も作成されました。

この追加の接続文字列を使用すると、データベース スキーマの更新に 1 つのユーザー アカウントを指定し、アプリケーション データ アクセス用に別のユーザー アカウントを指定できます。 たとえば、db_owner ロールをCode First Migrationsに割り当て、アプリケーションにロールをdb_datareaderおよびdb_datawriterできます。 これは、アプリケーション内の悪意のある可能性のあるコードがデータベース スキーマを変更するのを防ぐ一般的な多層防御パターンです。 (たとえば、これは SQL インジェクション攻撃が成功した場合に発生する可能性があります)。このパターンは、これらのチュートリアルでは使用されません。 SQL Server Compactには適用されず、このシリーズの後半のチュートリアルでSQL Serverに移行する場合は適用されません。 Cytanium サイトには、Cytanium で作成したSQL Server データベースにアクセスするためのユーザー アカウントが 1 つだけ用意されています。 シナリオでこのパターンを実装できる場合は、次の手順を実行して実装できます。

1. [Web の発行] ウィザードの [設定] タブで、データベース スキーマの完全な更新アクセス許可を持つユーザーを指定する接続文字列を入力し、[実行時にこの接続文字列を使用チェック] ボックスをオフにします。 デプロイされた Web.config ファイルでは、これが接続文字列になりますDatabasePublish。
2. アプリケーションで実行時に使用する接続文字列の Web.config ファイル変換を作成します。

これで、開発用コンピューター上の IIS にアプリケーションを展開し、そこでテストしました。 これにより、展開プロセスによってアプリケーションのコンテンツが適切な場所にコピーされ (展開しないファイルを除く)、デプロイ時に Web 配置によって IIS が正しく構成されていることも確認されます。 次のチュートリアルでは、まだ実行されていない展開タスクを見つけるもう 1 つのテストを実行します。 Elmah フォルダーに対するフォルダーのアクセス許可を設定します。

詳細情報

Visual Studio での IIS またはIIS Expressの実行の詳細については、次のリソースを参照してください。

• IIS.net サイトの [概要] をIIS Expressします。
• Scott Guthrie のブログでIIS Expressについて紹介します。
• 方法: Visual Studio で Web プロジェクト用の Web サーバーを指定する。
• IIS と ASP.NET サイトの ASP.NET 開発サーバーの主な違い 。
• Rick Anderson のブログで、IIS 7 で ASP.NET MVC または Web Forms アプリケーションを 30 秒でテストします。 このエントリでは、Visual Studio Development Server (Cassini) を使用したテストがIIS Expressでのテストほど信頼性が高くない理由と、IIS Expressでのテストが IIS でのテストほど信頼性が高くない理由の例を示します。

前へ次へ