Visual Studio での Web アプリケーション プロジェクトと Web サイト プロジェクト
Visual Studio で Web アプリケーション プロジェクト または Web サイト プロジェクトを作成できます。 Visual Studio の ファイル のメニューの 新しいプロジェクト か プロジェクトを開く を選択して Web アプリケーション プロジェクトを作成するか、開きます。 [ファイル]メニューの 新しい Web サイト か Web サイトを開く を選択して Web サイト プロジェクトを作成または開きます。
プロジェクトの種類にはそれぞれ利点と欠点があるため、ニーズに最も適したプロジェクトの種類を選択するうえで違いを理解しておくと役立ちます。 プロジェクトを作成する前に、適切なプロジェクトの種類を選択する必要があります。プロジェクトの種類の変換は実用的ではないためです。
注意
一部のシナリオでは、オプションはありません。たとえば、ASP.NET MVC アプリケーションを作成する場合、Web アプリケーション プロジェクトを使用する必要があります。
このトピックは、次のセクションで構成されています。
シナリオ
相違点の概要
プロジェクト ファイルの構造
コンパイル
配置
シナリオ
Web アプリケーション プロジェクトが望ましいシナリオは次のとおりです。をです:
Visual Studio デバッガーの エディット コンティニュ 機能を使用できるようにする場合。
ASP.NET ページに関連付けられたクラス ファイル内のコードの単体テストを実行する場合。
スタンドアロン クラスから、ページおよびユーザー コントロールに関連付けられているクラスを参照する場合。
複数の Web プロジェクト間のプロジェクトの依存関係を確立する場合。
コンパイラでサイト全体に関して単一のアセンブリを作成する場合。
そのサイトで生成されるアセンブリ名とバージョン番号を制御する場合。
MSBuild またはチーム ビルドを使用してプロジェクトをコンパイルする場合。 たとえば、をおよびビルド後のステップを追加する必要があります。
ソース コードを運用サーバー上に置かないようにする場合。
Visual Studio に用意されている自動配置ツールを使用する場合。
Web サイト プロジェクトが望ましいシナリオとして、次のような場合があります。
単一 Web プロジェクトに C# と Visual Basic コードを含める場合 (既定では、Web アプリケーションは、プロジェクト ファイルの言語設定に基づいてコンパイルされます。 例外を作成できますが、これは相対的に困難です)。
Visual Studio で本番サイトを開き、FTP を使用してリアルタイムでサイトを更新する場合。
プロジェクトを配置するために、プロジェクトを明示的にコンパイルする必要がないようにする場合。
サイトをプリコンパイルする場合に、コンパイラでサイトの複数のアセンブリを作成する場合。ページまたはユーザー コントロールごとに 1 つのアセンブリを含めることも、フォルダーごとに 1 つ以上のアセンブリを含めることもできます。
新しいバージョンを運用サーバーにコピーするだけで、または運用サーバー上のファイルを直接編集することで、運用環境の個々のファイルを更新できるようにする場合。
サイトをプリコンパイルする場合、サイト全体を再コンパイルせず、個々の ASP.NET Web ページ (.aspx ファイル) を更新できるようにする場合。
追加のバックアップ コピーとして使用できるため、ソース コードを運用サーバー上に保持する場合。
相違点の概要
主な相違点の概要を次の表に示します。
区分 |
Web アプリケーション プロジェクト |
Web サイト プロジェクト |
|---|---|---|
プロジェクト ファイルの構造 |
Visual Studio プロジェクト ファイル (.csproj または .vbproj) には、プロジェクトに含まれるファイル一覧、プロジェクト間参照など、プロジェクトに関する情報が格納されます。 |
プロジェクト ファイル (.csproj または .vbproj) はありません。 フォルダー構造内のすべてのファイルは、自動的にサイトに含まれます。 |
コンパイル |
|
|
名前空間 |
既定で、明示的な名前空間がページ、コントロール、およびクラスに追加されます。 |
既定では、明示的な名前空間がページ、コントロール、およびクラスに追加されませんが、手動で追加できます。 |
配置 |
|
|
プロジェクト ファイルの構造
Web アプリケーション プロジェクトでは Visual Studio プロジェクト ファイル (.csproj または .vbproj) を使用して、プロジェクトに関する情報を追跡します。 これは、ファイルまたはファイルがビルド時にコンパイルされたプロジェクトから除外されており、結果として指定することもできます。
Web サイト プロジェクトの場合、フォルダー構造内のすべてのファイルは自動的に Web サイトに含まれると見なされます。 コンパイルで何かを除外する場合、Web サイト プロジェクト フォルダーからファイルを削除するか、IIS によってコンパイルし、提供されない拡張子にファイル名拡張子を変更する必要があります。
Web アプリケーション プロジェクトでプロジェクト ファイルを使用する利点は以下です:
- 一時的にサイトからファイルを削除することは容易ですが、ファイルはフォルダー構造に残るため、ファイルは継続して追跡されることを確認してください。 たとえば、ページを配置する準備が整っていない場合、フォルダー構造から削除することなくビルドから一時的に除外できます。 コンパイル済みのアセンブリを配置してから、改めてプロジェクトにファイルを含めることができます。 ソース管理リポジトリを操作している場合、この点は特に重要です。
Web サイト プロジェクトでプロジェクト ファイルなしでフォルダー構造を使用する利点は以下のとおりです。
- Visual Studio で排他的にプロジェクトの構造を管理する必要はありません。 たとえば、プロジェクトにファイルをコピーするか、またはファイル エクスプローラーを使用してプロジェクトから削除できます。
コンパイル
Web アプリケーション プロジェクトの場合、通常、運用 IIS サーバーではないコンピューターに Visual Studio のまたは ASP.NET バッチ コンパイラを使用してプロジェクトをビルドします。 プロジェクト内のすべての分離コード クラス ファイルとスタンドアロン クラス ファイルは Web アプリケーション プロジェクトの Bin フォルダーに、単一のアセンブリにコンパイルされます。 されることが、Web サイト プロジェクトの場合 (.aspx ファイルと .ascx ファイルは動的コンパイルには、同様です)。
Web サイト プロジェクトの場合、プロジェクトを手動でコンパイルする必要はありません。 Web サイト プロジェクトは通常、ASP.NET によって動的にコンパイルされます (開発コンピューターと運用 IIS サーバーの両方で)。 バッチ コンパイル モード (通常は 1 つのフォルダーにつき 1 つのアセンブリを生成します) と固定のコンパイル モード (通常はページまたはユーザー コントロールごとに 1 つのアセンブリを生成します) から選択できます。
Web アプリケーション プロジェクトのコンパイル モデルの利点は以下が含まれています:
MSBuild を使用してカスタムのバッチ コンパイル プロセスを作成できます。
名前とバージョンなど、アセンブリの属性を簡単に指定できます。
事前にコンパイルすることで、運用サーバー上でサイトのコンパイル中にユーザーが待機する必要がなくなります (大規模なサイト、Web サイト プロジェクトの動的コンパイルでは、時間がかかる場合があります。 動的なコンパイルが発生するのは、サイトの更新後にサイト リソースの要求が受信されるときです。要求されたリソースがコンパイルされている間に、コンパイルをトリガーした要求が遅延する可能性があります。 遅延を許容できない場合、サイトをプリコンパイルできます。 ただし、動的コンパイルが持ついくつかの利点は失われます)。
プロジェクト フォルダー構造にコード ファイルを配置する場所、およびプロジェクト内のクラスが相互に参照する方法は完全に管理できます (動的コンパイルの場合、サイト全体で使用するすべてのクラスのソース コードを App_Code フォルダーに配置する必要があります。 App_Code のクラスからページまたはユーザー コントロール クラスを参照することはできません)。
Web サイト プロジェクトのコンパイル モデルの利点は以下のとおりです。
他のページの状態に関係なく、特定のページをテストできます。 これは、個々のページを実行するには、サイト全体が正常にコンパイルされている必要がないためです。そのページと、そのページが依存するすべてのコンポーネント (App_Code フォルダー内のコードや Global.asax など) がコンパイルされているだけでページを実行できます サイトにコンパイル エラーがどこでもあるため、(Web アプリケーション プロジェクトのアセンブリを作成、コンパイルするサイトの一部をテストできません)。
運用環境の Web サイトを簡単に更新できます。 明示的にサイトを再コンパイルしなくても、運用サーバーにある個々のソース コード ファイルを更新できます。 他のファイルがコンパイル エラーのため配置できない場合でも、配置の準備が整った個々のファイルを更新できます。 また、運用 IIS サーバー上の Web サイトを Visual Studio で直接開き、リアルタイムで Web サイトを更新することもできます。
シナリオによっては、複数のアセンブリをプリコンパイルすることでパフォーマンス上の利点もあります。 一般的な例は、多数のページがあり、ページ用に作成されたコードも多数あるサイトの場合です。 多くのページはほとんど要求されず、一部のみが頻繁に使用されます。 このようなサイトを複数のアセンブリにコンパイルする場合、運用サーバーでは現在の要求に必要なアセンブリのみを読み込むことができます。 ページが要求されない場合、対応するアセンブリは読み込まれません。
注意
Web サイト プロジェクトと Web アプリケーション プロジェクトにパフォーマンスの違いはありません。唯一の重大な例外は既に説明した場合で、実用上の問題としては非常に大きなサイトにのみ該当します。Web サイトへの最初の要求が遅延が発生する可能性があるサイトをコンパイルする必要があります。と Web サイトがメモリが足りない IIS サーバーで実行され、複数のアセンブリに要求されている場合、単一のアセンブリにサイト全体がより多くのメモリを使用する場合があります。
配置
Web アプリケーション プロジェクトを配置するには、IIS サーバーへのプロジェクトをコンパイルして作成されるアセンブリをコピーします。 これに対し、Web サイト プロジェクトを配置するには、IIS サーバーにそのプロジェクトのソース ファイルをコピーします。
Web アプリケーション プロジェクトの配置戦略の利点は以下が含まれています:
ソース コードを IIS サーバーに配置する必要はありません。 シナリオによっては、共有のホスティング環境など、IIS サーバー上のソース コードに対する不正アクセスが懸念されることがあります (Web サイトのプロジェクトの場合、開発コンピューター上でプリコンパイルとソース・コードではなく生成されたアセンブリを配置することで、このリスクを回避できます。 ただし、その場合、容易なサイト更新が持つ利点の一部を失います)。
配置には、アセンブリまたはコードをサーバーにコピーするタスクとは別のタスクが必要になることもよくあります。 たとえば、データベース スクリプトを運用環境で実行する必要がある場合や、Web.config ファイルの接続文字列は運用サーバーに合わせて変更する必要がある場合があります。 Visual Studio は、これらのタスクの多くを自動化する Web アプリケーション プロジェクトをワンクリック発行を使用するなどのツールが用意されています。 これらのツールは Web サイト プロジェクトでは使用できません。
Web サイト プロジェクトの配置戦略の利点は以下が含まれています:
- Web サイトにわずかな変更を加えると、サイト全体を再配置する必要はありません。 変更したファイルを運用 IIS サーバーにコピーするだけです。 運用サーバー上でファイルを直接編集することもできます 唯一の変更が .aspx、.ascx ファイルにある Web アプリケーション プロジェクトのコード ファイルは単一のアセンブリ ファイルにコンパイルされるため、小さな変更のすべてのサイトを配置する必要があります)。
参照
概念
Visual Studio および ASP.NET の Web 配置コンテンツ マップ
その他の技術情報
Web Application Projects vs Web Site Projects (Web アプリケーション プロジェクトと Web サイト プロジェクト)