Visual Studio を使用した ASP.NET Web 配置: テスト環境へのデプロイ

[アーティクル]
05/29/2024

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

Azure へのデプロイの現在のバージョンについては、Azure での ASP.NET Core Web アプリの作成に関するページを参照してください。

概要

このチュートリアルでは、ASP.NET Web アプリをローカルコンピューター上のインターネットインフォメーションサービス (IIS) にデプロイします。

通常、アプリケーションをデプロイする場合、Visual Studio で実行してテストします。既定では、Visual Studio 2017 の Web アプリプロジェクトでは、開発 Web サーバーとして IIS Express が使用されます。 Visual Studio 2017 が既定で使用する Visual Studio 開発サーバー (Cassini とも呼ばれます) よりも IIS Express の方が、完全な IIS に似た動作をします。ただし、どちらの開発 Web サーバーも IIS とまったく同じようには機能しません。そのため、Visual Studio でアプリを正しく実行してテストできても、IIS にデプロイすると失敗します。

アプリケーションを確実にテストするには、次の 2 つの方法があります。

後で運用環境にデプロイするときに使用するプロセスと同じプロセスを使用して、アプリケーションを開発用コンピューター上の IIS に展開します。

Web プロジェクトの実行時に IIS を使用するように Visual Studio を構成できますが、デプロイプロセスはテストされません。この方法では、デプロイプロセスと、アプリケーションが IIS で正しく実行されることを検証します。
アプリケーションを運用環境と同様のテスト環境にデプロイします。

これらのチュートリアルの運用環境は、Azure App Service 内の Web Apps です。理想的なテスト環境は、Azure サービスで作成された追加の Web アプリです。これは、運用環境の Web アプリと同じ方法で設定されますが、テストにのみ使用します。

オプション 2 は、最も信頼性の高いテスト方法です。オプション 2 を使用する場合、必ずしもオプション 1 を使用する必要はありません。ただし、サードパーティのホスティングプロバイダーにデプロイする場合、オプション 2 は実現できないか、コストがかかる可能性があるため、このチュートリアルシリーズでは両方の方法を示します。オプション 2 のガイダンスは、運用環境へのデプロイに関するチュートリアルで提供されています。

Visual Studio で Web サーバーを使用する方法の詳細については、「ASP.NET Web プロジェクト用の Visual Studio の Web サーバー」を参照してください。

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

Contoso University スタータープロジェクトをダウンロードする

Contoso University Visual Studio スターターソリューションとプロジェクトをダウンロードしてインストールします。このソリューションには、完成したチュートリアルが含まれています。

スタートプロジェクトをダウンロードする

IIS のインストール

開発用コンピューター上の IIS にデプロイするには、IIS と Web 配置がインストールされていることを確認します。既定では、Visual Studio は Web 配置をデプロイしますが、IIS は、既定の Windows 10、Windows 8、または Windows 7 の構成に含まれていません。 IIS を既にインストールしており、既定のアプリケーションプールが既に .NET 4 に設定されている場合は、次のセクションに進んでください。

Web Platform Installer (WPI) を使用して IIS と Web 配置をインストールすることをお勧めします。 WPI を使用すると、必要に応じて IIS と Web 配置の前提条件を含む推奨される IIS 構成がインストールされます。

IIS、Web 配置、またはいずれかの必要なコンポーネントを既にインストールしている場合、WPI は、不足しているもののみをインストールします。
- Web Platform Installer を使用して IIS と Web 配置をインストールします。
  
  IIS 7 がインストールされることを示すメッセージが表示されます。このリンクは、Windows 8 の IIS 8 では機能しますが、Windows 8 以降の場合は、次の手順を実行して、ASP.NET 4.7 がインストールされていることを確認します。
- [コントロールパネル]>[プログラム]>[プログラムと機能]>[Windows の機能の有効化または無効化]の順に開きます。
- [インターネットインフォメーションサービス]、[World Wide Web サービス]、[アプリケーション開発機能] の順に展開します。
- [ASP.NET 4.7] がオンになっていることを確認します。
- [World Wide Web サービス] と [IIS 管理コンソール] がオンになっていることを確認します。これにより、IIS と IIS マネージャーがインストールされます。
- [OK] を選択します。インストール中であることを示すダイアログボックスメッセージが表示されます。

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

WINDOWS + R キーを押して、[実行] ダイアログボックスを開きます

(Windows 8 以降では、[スタート] ページに「実行」と入力します。Windows 7 では、[スタート] メニューから [実行] を選択します。[スタート] メニューに [実行] がない場合、タスクバーを右クリックし、[プロパティ]、[スタートメニュー] タブ、[カスタマイズ]、[実行コマンド] の順に選択します)。
「inetmgr」と入力し、[OK] を選択します。
[接続] ペインで、サーバーノードを展開し、[アプリケーションプール] を選択します。 [アプリケーションプール] ペインで、次の図のように、DefaultAppPool が .NET Framework バージョン 4 に割り当てられている場合は、次のセクションに進みます。
2 つのアプリケーションプールのみが表示され、両方とも .NET Framework 2.0 に設定されている場合は、IIS に ASP.NET 4 をインストールします。

Windows 8 以降の場合は、ASP.NET 4.7 がインストールされていることを確認するための前のセクションの手順を参照するか、Windows 8 と Windows Server 2012 に ASP.NET 4.5 をインストールする方法に関するページを参照してください。 Windows 7 の場合は、Windows の [スタート] メニューの [コマンドプロンプト] を右クリックし、[管理者として実行] を選択して、コマンドプロンプトウィンドウを開きます。次のコマンドを使用して、aspnet_regiis.exe を実行し、ASP.NET 4 を IIS にインストールします (32 ビットシステムでは、"Framework64" を "Framework" に置き換えます)。
```
cd %windir%\Microsoft.NET\Framework64\v4.0.30319
aspnet_regiis.exe –i
```
このコマンドを実行すると、.NET Framework 4 用の新しいアプリケーションプールが作成されますが、既定のアプリケーションプールは 2.0 に設定されたままになります。 .NET 4 を対象とするアプリケーションをそのアプリケーションプールにデプロイしているため、アプリケーションプールを .NET 4 に変更します。
IIS マネージャーを閉じている場合は、もう一度実行し、サーバーノードを展開して、[アプリケーションプール] を選択します。
[アプリケーションプール] ペインで、[DefaultAppPool] を選択します。 [アクション] ペインで、[基本設定] を選択します。
][アプリケーションプールの編集] ダイアログボックスで、[.NET CLR のバージョン] を [.NET CLR v4.0.30319] に変更します。 [OK] を選択します。

これで、Web アプリを IIS に発行する準備ができました。ただし、まず、テスト用のデータベースを作成します。

SQL Server Express をインストールする

LocalDB は IIS で動作するように設計されていないため、テスト環境には SQL Server Express がインストールされている必要があります。 Visual Studio 2010 SQL Server Express を使用している場合は、既定で既にインストールされています。 Visual Studio 2012 以降を使用している場合は、SQL Server Express をインストールします。

SQL Server Express をインストールするには、ダウンロードセンター: Microsoft SQL Server 2017 Express Edition からダウンロードしてインストールします。

SQL Server インストールセンターの最初のページで、[新しい SQL Server スタンドアロンインストール] を選択するか、既存のインストールに機能を追加し、手順に従って既定の選択を受け入れます。インストールウィザードで、既定の設定を受け入れます。インストールオプションの詳細については、「SQL Server をインストールウィザードからインストールする (セットアップ)」を参照してください。

テスト環境用の SQL Server Express データベースを作成する

Contoso University アプリケーションには、次の 2 つのデータベースがあります。

メンバーシップデータベース
アプリケーションデータベース

これらのデータベースを 2 つの個別のデータベースまたは 1 つのデータベースにデプロイできます。これらを組み合わせると、これらの間のデータベース結合が容易になります。

サードパーティのホスティングプロバイダーにデプロイする場合、ホスティングプランのために、これらを組み合わせる必要が生じる場合もあります。たとえば、プロバイダーが、複数のデータベースに対して追加料金を請求する場合や、複数のデータベースを許可しない場合などがあります。

このチュートリアルでは、テスト環境では 2 つのデータベースにデプロイし、ステージング環境と運用環境では 1 つのデータベースにデプロイします。

Visual Studio の [表示] メニューから [サーバーエクスプローラー] (Visual Web Developer では [データベースエクスプローラー]) を選択します。 [データ接続] を右クリックし、[新しい SQL Server データベースの作成] を選択します。

Selecting_Create_New_SQL_Server_Database

[新しい SQL Server データベースの作成] ダイアログボックスで、[サーバー名] ボックスに「.\SQLExpress」と入力し、[新しいデータベース名] ボックスに「aspnet-ContosoUniversity」と入力します。 [OK] を選択します。

Create aspnet-ContosoUniversity

同じ手順に従って、ContosoUniversity という名前の新しい SQL Server Express School データベースを作成します。

サーバーエクスプローラー に 2 つの新しいデータベースが表示されます。

New databases in Server Explorer

新しいデータベースの許可スクリプトを作成する

開発用コンピューター上の IIS でアプリケーションが実行されると、アプリケーションは既定のアプリケーションプールの資格情報を使用して、データベースにアクセスします。ただし、既定では、アプリケーションプールに、データベースを開くアクセス許可はありません。つまり、そのアクセス許可を付与するスクリプトを実行する必要があります。このセクションでは、そのスクリプトを作成して実行し、アプリケーションが IIS で実行されるときにデータベースを確実に開くことができるようにします。

テキストエディターで、次の SQL コマンドを新しいファイルにコピーし、Grant.sql として保存します。

IF NOT EXISTS (SELECT name FROM sys.server_principals WHERE name = 'IIS APPPOOL\DefaultAppPool')
BEGIN
    CREATE LOGIN [IIS APPPOOL\DefaultAppPool] 
      FROM WINDOWS WITH DEFAULT_DATABASE=[master], 
      DEFAULT_LANGUAGE=[us_english]
END
GO
CREATE USER [ContosoUniversityUser] 
  FOR LOGIN [IIS APPPOOL\DefaultAppPool]
GO
EXEC sp_addrolemember 'db_owner', 'ContosoUniversityUser'
GO

Visual Studio で、Contoso University ソリューションを開きます。このソリューション (プロジェクトの 1 つではありません) を右クリックし、[追加] を選択します。 [既存の項目] を選択し、Grant.sql を参照して開きます。

Note

このスクリプトは、SQL Server Express 2012 以降で、このチュートリアルで指定する Windows 10、Windows 8、または Windows 7 の IIS 設定を使用して動作するように設計されています。別のバージョンの SQL Server または Windows を使用している場合、またはお使いのコンピューターで IIS を異なって設定している場合、このスクリプトの変更が必要になることがあります。 SQL Server スクリプトの詳細については、SQL Server オンラインブックを参照してください。

Note

セキュリティに関する注意 このスクリプトは、実行時にデータベースにアクセスユーザーに db_owner アクセス許可を付与します。これは、運用環境で使用できます。一部のシナリオでは、デプロイ時にのみ、完全なデータベーススキーマ更新アクセス許可を持つユーザーを指定し、実行時には、データの読み取りと書き込みのアクセス許可のみを持つ別のユーザーを指定することが必要な場合があります。詳細については、このチュートリアルで後述する「Code First Migrations の自動 Web.config 変更を確認する」を参照してください。

アプリケーションデータベースで許可スクリプトを実行する

データベースのデプロイでは dbDacFx プロバイダーが使用されるため、デプロイ中にメンバーシップデータベースで許可スクリプトを実行するように発行プロファイルを構成できます。 Code First Migrations のデプロイ中にスクリプトを実行することはできません。Code First Migrations は、アプリケーションデータベースをデプロイする方法です。つまり、このスクリプトは、アプリケーションデータベースにデプロイする前に手動で実行する必要があります。

Visual Studio で、先ほど作成した Grant.sql ファイルを開きます。
接続を選択します。
[サーバーへの接続] ダイアログボックスで、[サーバー名] として「.\SQLExpress」と入力します。接続を選択します。
データベースドロップダウンリストで、[ContosoUniversity] を選択します。 [実行] を選択します。

これで、既定のアプリケーションプール ID に、アプリケーションデータベースで、アプリケーションの実行時に Code First Migrations がデータベーステーブルを作成するための十分なアクセス許可が与えられます。

IIS に発行する

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

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

デプロイタスクを自動化するように Visual Studio を設定するために前のチュートリアルで実行したプロセスは、これらのすべての方法に適用されます。これらのチュートリアルでは、最初の 2 つの方法を使用します。展開パッケージの詳細については、Visual Studio および ASP.NET の Web 配置コンテンツマップの「Web 配置パッケージを作成してインストールして Web アプリケーションをデプロイする」を参照してください。

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

発行プロファイルを作成する

ソリューションエクスプローラーで、[ContosoUniversity] プロジェクト (ContosoUniversity.DAL プロジェクトではありません) を右クリックします。公開を選択します。 [発行] ページが表示されます。
[新しいプロファイル] を選択します。 [発行先を選択] ダイアログボックスが表示されます。
[IIS、FTP、その他] を選択します。[プロファイルの作成] を選択します。発行ウィザードが表示されます。
[発行方法] ドロップダウンメニューから [Web 配置] を選択します。
[サーバー] で、「localhost」と入力します。
[サイト名] で、「Default Web Site/ContosoUniversity」と入力します。
[宛先 URL] で、「http://localhost/ContosoUniversity」と入力します。

[宛先 URL] 設定は必要ありません。 Visual Studio でアプリのデプロイが完了すると、既定のブラウザーでこの URL が自動的に開きます。デプロイ後にブラウザーを自動的に開かないようにする場合は、このボックスを空白のままにします。
[接続の検証] を選択して、設定が正しいことと、ローカルコンピューター上の IIS に接続できることを確認します。

緑色のチェックマークは、接続が成功したことを示します。
[次へ] を選択して、[設定] タブに進みます。
[構成] ドロップダウンボックスでは、デプロイするビルド構成を指定します。これは、既定値の [リリース] に設定したままにします。このチュートリアルでは、[デバッグ] ビルドをデプロイしません。
[ファイル発行オプション] を展開します。 [App_Data フォルダーのファイルを除外する] をオンにします。

テスト環境では、アプリケーションは、App_Data フォルダー内の .mdf ファイルではなく、ローカルの SQL Server Express インスタンス内に作成したデータベースにアクセスします。
[発行中にプリコンパイルする] と [発行先の追加ファイルを削除する] のチェックボックスはオフのままにします。

プリコンパイルは、主に大規模なサイトに役立つオプションです。これは、サイトの発行後に最初にページを要求する際の起動時間を短縮できます。

これは最初のデプロイであり、発行先フォルダーにはまだファイルが存在しないため、追加のファイルを削除する必要はありません。

Note

同じサイトへの後続のデプロイに対して [発行先の追加ファイルを削除する] オンにする場合は、デプロイする前に必ずプレビュー機能を使用して、削除されるファイルを事前に確認してください。想定される動作は、Web 配置によって、プロジェクトで削除したファイルが宛先サーバー上で削除されることです。ただし、ソースフォルダーと宛先フォルダーの下のフォルダー構造全体が比較されます。また、一部のシナリオでは、Web 配置によって削除したくないファイルが削除される可能性があります。

たとえば、サーバー上のサブフォルダーに Web アプリケーションがある場合、プロジェクトをルートフォルダーにデプロイすると、そのサブフォルダーは削除されます。 contoso.com のメインサイト用のプロジェクトが 1 つあり、contoso.com/blog のブログ用の別のプロジェクトがあるとします。ブログアプリケーションはサブフォルダー内にあります。メインサイトをデプロイするときに [発行先の追加ファイルを削除する] をオンにすると、ブログアプリケーションは削除されます。

もう 1 つの例として、App_Data フォルダーが予期せず削除される場合があります。 SQL Server Compact などの特定のデータベースでは、データベースファイルが App_Data フォルダーに格納されます。最初のデプロイ後、後続のデプロイでデータベースファイルのコピーを続けない場合は、[Web のパッケージ化/発行] タブで [App_Data を除外する] をオンにします。これを行った後、[発行先の追加ファイルを削除する] をオンにしている場合、次に発行するときに、データベースファイルと App_Data フォルダー自体が削除されます。

メンバーシップデータベースのデプロイを構成する

次の手順は、ダイアログボックスの [データベース] セクションの DefaultConnection データベースに適用されます。

[リモート接続文字列] ボックスに、新しい SQL Server Express メンバーシップデータベースを指す次の接続文字列を入力します。
```
Data Source=.\SQLExpress;Initial Catalog=aspnet-ContosoUniversity;Integrated Security=True
```
[実行時にこの接続文字列を使用する] がオンになっているため、デプロイプロセスでは、デプロイされた Web.config ファイルにこの接続文字列を格納します。

また、サーバーエクスプローラーから接続文字列を取得することもできます。 サーバーエクスプローラーで、[データ接続] を展開して <マシン名>\sqlexpress.aspnet-ContosoUniversity データベースを選択し、[プロパティ] ウィンドウから [接続文字列] の値をコピーします。この接続文字列には、削除できる追加の設定 (Pooling=False) が 1 つ含まれます。
[データベースの更新] を選択します。

これにより、デプロイ時に、宛先データベースにデータベーススキーマが作成されます。次の手順では、実行する必要がある追加のスクリプトを指定します。1 つは、既定のアプリケーションプールへのデータベースアクセスを許可するスクリプトで、もう 1 つはデータをデプロイするスクリプトです。
[データベース更新の構成] を選択します。
[データベース更新の構成] ダイアログボックスで、[SQL スクリプトの追加] を選択します。先ほどソリューションフォルダーに保存した Grant.sql スクリプトに移動します。
このプロセスを繰り返して、aspnet-data-dev.sql スクリプトを追加します。
[閉じる] を選択します。

アプリケーションデータベースのデプロイを構成する

Visual Studio で Entity Framework の DbContext クラスが検出されると、[データベースの更新] チェックボックスではなく [Code First Migrations の実行] チェックボックスを含むエントリが [データベース] セクションに作成されます。このチュートリアルの場合、そのチェックボックスを使用して、Code First Migrations によるデプロイを指定します。

一部のシナリオでは、DbContext データベースを使用しているが、データのデプロイに Migratios ではなく dbDacFx プロバイダーを使用することが必要な場合があります。その場合は、MSDN の ASP.NET Web 配置に関する FAQ の「Migratios を使用せずに Code First データベースをデプロイするにはどうすればいいですか?」を参照してください。

次の手順は、ダイアログボックスの [データベース] セクションの SchoolContext データベースに適用されます。

[リモート接続文字列] ボックスに、新しい SQL Server Express アプリケーションデータベースを指す次の接続文字列を入力します。
```
Data Source=.\SQLExpress;Initial Catalog=ContosoUniversity;Integrated Security=True
```
[実行時にこの接続文字列を使用する] がオンになっているため、デプロイプロセスでは、デプロイされた Web.config ファイルにこの接続文字列を格納します。

メンバーシップデータベースの接続文字列を取得した場合と同じ方法で、サーバーエクスプローラーからアプリケーションデータベースの接続文字列を取得することもできます。
[Code First Migrations の実行 (アプリケーションの起動時に実行)] を選択します。

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

発行プロファイル変換を構成する

[閉じる] を選択します。変更を保存するかどうかを確認するメッセージが表示されたら、[はい] を選択します。
ソリューションエクスプローラーで、[プロパティ]、[PublishProfiles] の順に展開します。
CustomProfile.pubxml を右クリックし、その名前を Test.pubxml に変更します。
Test.pubxml を右クリックします。 [構成変換の追加] を選択します。

Visual Studio によって、Web.Test.config 変換ファイルが作成されて開かれます。
Web.Test.config 変換ファイルで、開始構成タグの直後に次のコードを挿入します。
```
<appSettings>
    <add key="Environment" value="Test" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>
```
テスト発行プロファイルを使用すると、この変換によって、環境インジケーターが "Test" に設定されます。デプロイされたサイトでは、H1 見出し "Contoso University" の後に "(Test)" と表示されます。
ファイルを保存して閉じます。
Web.Test.config ファイルを右クリックし、[変換のプレビュー] を選択して、コード化した変換によって期待される変更が生成されることを確認します。

[Web.config のプレビュー] ウィンドウに、Web.Release.config 変換と Web.Test.config 変換の両方を適用した結果が表示されます。

デプロイ更新をプレビューする

Web の発行ウィザードをもう一度開きます (ContosoUniversity プロジェクトを右クリックし、[発行]、[プレビュー] の順に選択します)。
[プレビュー] ダイアログボックスで、[プレビューの開始] を選択して、コピーされるファイルの一覧を表示します。

また、[データベースのプレビュー] リンクを選択して、メンバーシップデータベースで実行されるスクリプトを確認することもできます (Code First Migrations によるデプロイの場合はスクリプトが実行されないため、アプリケーションデータベースについてはプレビューするものはありません)。
公開を選択します。

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

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

発行プロファイルの [接続] タブで、[宛先 URL] に URL を入力した場合、ブラウザーによって、コンピューター上の IIS で実行されている Contoso University のホームページが自動的に開かれます。

テスト環境でテストする

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

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

[学生] タブを選択して、デプロイされたデータベースに学生が含まれていないことを確認します。

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

[課程] メニューから [単位の更新] を選択します。 [単位の更新] ページには、管理者アクセス許可が必要であるため、[ログイン] ページが表示されます。前に作成した管理者アカウントの資格情報 ("admin" と "devpwd") を入力します。 [単位の更新] ページが表示されます。これにより、前のチュートリアルで作成した管理者アカウントがテスト環境に正しくデプロイされたことが確認されます。

プレースホルダーファイルのみを含む c:\inetpub\wwwroot\ContosoUniversity フォルダー内に ELMAH フォルダーがあることを確認します。

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

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

$Open the Web.config file in the deployed application at C:\inetpub\wwwroot\ContosoUniversity and see where the deployment process configured Code First Migrations to automatically update the database to the latest version.$

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

Database_Publish connection string

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

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

まとめ

これで、開発用コンピューター上の IIS にアプリケーションをデプロイし、そこでのテストが完了しました。

Home page in Test

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

詳細

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

IIS Express の概要 (IIS.net サイト)。
IIS Express の紹介 (Scott Guthrie のブログ)。
ASP.NET Web プロジェクト用の Visual Studio の Web サーバー。
IIS と ASP.NET 開発サーバーの中心的な違い (ASP.NET サイト)。

前へ次へ

次の方法で共有