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

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

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

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

概要

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

一般に、アプリケーションを開発するときは、アプリケーションを実行して Visual Studio でテストします。既定では、Visual Studio 2017 の Web アプリケーションプロジェクトでは、IIS Expressが開発 Web サーバーとして使用されます。 IIS Expressは、Visual Studio 2017 が既定で使用する Visual Studio 開発サーバー (Cassini とも呼ばれます) よりも完全な 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 プラットフォームインストーラー (WPI) を使用して IIS と Web 配置をインストールすることをお勧めします。 WPI は、必要に応じて IIS と Web 配置の前提条件を含む推奨される IIS 構成をインストールします。

IIS、Web 配置、または必要なコンポーネントのいずれかが既にインストールされている場合、WPI は不足しているもののみをインストールします。
- Web プラットフォームインストーラーを使用して 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 Services] と [IIS 管理コンソール] が選択されていることを確認します。これにより、IIS と IIS マネージャーがインストールされます。
- [OK] を選択します。インストールが行われているというダイアログボックスメッセージが表示されます。

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

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

(Windows 8以降では、[スタート] ページに「run」と入力します。Windows 7 で、[スタート] メニューから [実行] を選択します。[実行] が [スタート] メニューにない場合は、タスクバーを右クリックし、[プロパティ] を選択し、[スタートメニュー] タブを選択し、[カスタマイズ] を選択して、[コマンドの実行] を選択します)。
「inetmgr」と入力し、[ OK] を選択します。
[Connections] ウィンドウで、サーバーノードを展開し、[アプリケーションプール] を選択します。次の図のように、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 を実行し、次のコマンドを使用して IIS に ASP.NET 4 をインストールします。 (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 エディションからダウンロードしてインストールします。

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

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

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

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

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

サードパーティのホスティングプロバイダーにデプロイする場合は、ホスティングプランによってそれらを組み合わせる理由が提供される場合もあります。たとえば、プロバイダーは複数のデータベースに対してより多くの料金を請求する場合や、複数のデータベースを許可しない場合があります。

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

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

Selecting_Create_New_SQL_Server_Database

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

aspnet-ContosoUniversity を作成する

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

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

サーバーエクスプローラーの新しいデータベース

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

アプリケーションが開発用コンピューター上の 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を参照して開きます。

注意

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

注意

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

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

データベースのデプロイで dbDacFx プロバイダーが使用されるため、デプロイ時にメンバーシップデータベースで許可スクリプトを実行するように発行プロファイルを構成できます。 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.DAL プロジェクトではなく) ContosoUniversity プロジェクトを右クリックします。 [発行] を選択します。 [ 発行] ページが表示されます。
[ 新しいプロファイル] を選択します。 [ 発行先の選択 ] ダイアログボックスが表示されます。
[IIS]、[FTP] などを選択します。[プロファイルの作成] を選択します。発行ウィザードが表示されます。
[発行方法] ドロップダウンメニューから、[Web 配置] を選択します。
[サーバー] に「localhost」と入力します。
[ サイト名] に「 Default Web Site/ContosoUniversity」と入力します。
[ 宛先 URL] に「」と入力します http://localhost/ContosoUniversity。

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

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

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

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

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

注意

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

たとえば、プロジェクトをルートフォルダーに配置するときに、サーバー上のサブフォルダーに Web アプリケーションがある場合、サブフォルダーは削除されます。 contoso.com にあるメインサイト用のプロジェクトと、contoso.com/blog のブログ用の別のプロジェクトがある場合があります。ブログアプリケーションはサブフォルダーにあります。メインサイトを展開するときに [保存先に追加のファイルを削除する] を選択すると、ブログアプリケーションが削除されます。

別の例として、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 ファイルに配置されます。

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

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

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

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

一部のシナリオでは、データベースを DbContext 使用しているが、Migrations ではなく dbDacFx プロバイダーを使用してデータベースをデプロイしたい場合があります。その場合は、MSDN の ASP.NET Web 展開に関する FAQ の「移行なしで Code First データベースをデプロイ操作方法」を参照してください。

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

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

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

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

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

[閉じる] を選択します。変更を保存するかどうかを確認するメッセージが表示されたら、[ はい ] を選択します。
ソリューションエクスプローラーで、[プロパティ] を展開し、[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" に設定されます。デプロイされたサイトでは、"Contoso University" H1 見出しの後に "(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 変換が成功したことを示しています。

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

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

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

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

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

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

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

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

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

Database_Publish 接続文字列

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

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

まとめ

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

テストのホームページ

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

詳細情報

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

IIS.net サイトの [概要] をIIS Expressします。
Scott Guthrie のブログでIIS Expressについて説明します。
ASP.NET Web プロジェクト用の Visual Studio の Web サーバー。
IIS と ASP.NET サイトの ASP.NET 開発サーバーの主な違い。

前へ次へ