Web アプリケーションプロジェクトと Web サイトプロジェクト

[アーティクル]
10/15/2014

Visual Studio では、Web アプリケーションプロジェクトまたは Web サイトプロジェクトを作成できます。プロジェクトの種類にはそれぞれ利点と欠点があるため、ニーズに最も適したプロジェクトの種類を選択するうえで違いを理解しておくと役立ちます。プロジェクトを作成する前に、適切なプロジェクトの種類を選択する必要があります。プロジェクトの種類の変換は実用的ではないためです。

注意

シナリオによっては、選択の余地がないこともあります。たとえば、ASP.NET MVC アプリケーションを作成する場合、Web アプリケーションプロジェクトを使用する必要があります。

このトピックは、次のセクションで構成されています。

シナリオ
相違点の概要
プロジェクトファイルの構造
コンパイル
配置

シナリオ

Web アプリケーションプロジェクトが望ましいシナリオとして、次のような場合があります。

デバッグセッションを停止せずにコードを編集できるようにする場合。
ASP.NET ページに関連付けられたクラスファイル内のコードの単体テストを実行する場合。
スタンドアロンクラスから、ページおよびユーザーコントロールに関連付けられているクラスを参照する場合。
複数の Web プロジェクト間にプロジェクトの依存関係を確立する場合。
コンパイラでサイト全体に関して単一のアセンブリを作成する場合。
そのサイトで生成されるアセンブリ名とバージョン番号を制御する場合。
MSBuild またはチームビルドを使用してプロジェクトをコンパイルする場合。たとえば、ビルド前およびビルド後のステップを追加できます。
ソースコードを運用サーバー上に置かないようにする場合。
Visual Studio 2010 に用意されている自動配置ツールを使用する場合。

Web サイトプロジェクトが望ましいシナリオとして、次のような場合があります。

1 つの Web プロジェクトに C# コードと Visual Basic コードの両方を含める場合 (既定では、Web アプリケーションはプロジェクトファイルの言語設定に基づいてコンパイルされます。例外を作成できますが、これは相対的に困難です)。
Visual Studio で本番サイトを開き、FTP を使用してリアルタイムでサイトを更新する場合。
プロジェクトを配置するために、プロジェクトを明示的にコンパイルする必要がないようにする場合。
サイトをプリコンパイルする場合に、コンパイラでサイトの複数のアセンブリを作成する場合。ページまたはユーザーコントロールごとに 1 つのアセンブリを含めることも、フォルダーごとに 1 つ以上のアセンブリを含めることもできます。
新しいバージョンを運用サーバーにコピーするだけで、または運用サーバー上のファイルを直接編集することで、運用環境の個々のファイルを更新できるようにする場合。
サイトをプリコンパイルする場合に、Web サイト全体を再コンパイルする必要なく、個々の ASP.NET Web ページ (.aspx ファイル) を更新できるようにする場合。
追加のバックアップコピーとして使用できるため、ソースコードを運用サーバー上に保持する場合。

相違点の概要

主な相違点の概要を次の表に示します。

区分	Web アプリケーションプロジェクト	Web サイトプロジェクト
プロジェクトファイルの構造	Visual Studio プロジェクトファイル (.csproj または .vbproj) には、プロジェクトに含まれるファイル一覧、プロジェクト間参照など、プロジェクトに関する情報が格納されます。	プロジェクトファイル (.csproj または .vbproj) はありません。フォルダー構造内のすべてのファイルは、自動的にサイトに含まれます。
コンパイル	開発またはソース管理に使用するコンピューター上のソースコードを明示的にコンパイルします。既定では、コードファイル (.aspx ファイルと .ascx ファイルを除きます) のコンパイルによって単一のアセンブリが生成されます。	通常、サイトがインストールまたは更新された後に初めて要求を受信したときに、ソースコードはサーバー上の ASP.NET によって動的に (自動的に) コンパイルされます。サイトをプリコンパイルできます (開発コンピューターまたはサーバー上で事前にコンパイルできます)。既定では、コンパイルによって複数のアセンブリが生成されます。
名前空間	既定で、明示的な名前空間がページ、コントロール、およびクラスに追加されます。	既定では、明示的な名前空間がページ、コントロール、およびクラスに追加されませんが、手動で追加できます。
配置	アセンブリをサーバーにコピーします。アプリケーションのコンパイルによってアセンブリが生成されます。 Visual Studio には、IIS Web 配置ツールと統合されたツールが用意されており、多くの配置タスクを自動化できます。	IIS がインストールされているコンピューターにアプリケーションソースファイルをコピーします。開発コンピューターでサイトをプリコンパイルする場合、コンパイルで生成されたアセンブリを IIS サーバーにコピーします。 Visual Studio に配置ツールがありますが、Web アプリケーションプロジェクトで使用できるツールほど多くの配置タスクを自動化できません。

プロジェクトファイルの構造

Web アプリケーションプロジェクトでは Visual Studio プロジェクトファイル (.csproj または .vbproj) を使用して、プロジェクトに関する情報を追跡します。特にこのタスクによって、プロジェクトに含めるファイルと除外するファイルを指定でき、結果としてビルド中にコンパイルするファイルを指定できるようになります。

Web サイトプロジェクトの場合、フォルダー構造内のすべてのファイルは自動的に Web サイトに含まれると見なされます。コンパイルから何かを除外する場合、Web サイトプロジェクトフォルダーからファイルを削除するか、ファイル名の拡張子を、コンパイルされない拡張子または IIS から提供されない拡張子に変更します。

Web アプリケーションプロジェクトでプロジェクトファイルを使用する利点は以下のとおりです。

一時的にサイトからファイルを削除することは容易ですが、ファイルはフォルダー構造に残るため、ファイルは継続して追跡されることを確認してください。たとえば、ページを配置する準備が整っていない場合、フォルダー構造から削除することなくビルドから一時的に除外できます。コンパイル済みのアセンブリを配置してから、改めてプロジェクトにファイルを含めることができます。ソース管理リポジトリを操作している場合、この点は特に重要です。

Web サイトプロジェクトでプロジェクトファイルなしでフォルダー構造を使用する利点は以下のとおりです。

Visual Studio で排他的にプロジェクトの構造を管理する必要はありません。たとえば、エクスプローラーを使用してファイルをプロジェクトにコピーすることや、プロジェクトから削除することができます。

コンパイル

Web アプリケーションプロジェクトの場合、通常、Visual Studio でプロジェクトをビルドするか、運用 IIS サーバーではないコンピューター上で ASP.NET バッチコンパイラを使用してビルドします。プロジェクトに含まれるすべての分離コードクラスファイルとスタンドアロンクラスファイルは、単一のアセンブリにコンパイルされます。このアセンブリは Web アプリケーションプロジェクトの Bin フォルダーに配置されます (.aspx ファイルと .ascx ファイルは、Web サイトプロジェクトと似た方法で動的にコンパイルされます)。

Web サイトプロジェクトの場合、プロジェクトを手動でコンパイルする必要はありません。通常、Web サイトプロジェクトは (開発コンピューターと運用 IIS サーバーの両方で) ASP.NET によって動的にコンパイルされます。バッチコンパイルモード (通常は 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 サイトに対する最初の要求でサイトのコンパイルが必要になることがあります。その結果、遅延が発生する可能性があります。また、メモリが足りない IIS サーバー上で Web サイトが実行されている場合、単一のアセンブリにサイト全体を含めると、複数のアセンブリに必要なメモリよりも多くのメモリが使用される可能性があります。

配置

Web アプリケーションプロジェクトを配置するには、プロジェクトをコンパイルして作成されるアセンブリを IIS サーバーにコピーします。それとは対照的に、Web サイトプロジェクトを配置するには、通常、プロジェクトのソースファイルを IIS サーバーにコピーします。

Web アプリケーションプロジェクトの配置戦略の利点は以下のとおりです。

ソースコードを IIS サーバーに配置する必要はありません。シナリオによっては、共有のホスティング環境など、IIS サーバー上のソースコードに対する不正アクセスが懸念されることがあります (Web サイトプロジェクトの場合、開発コンピューター上でプリコンパイルし、ソースコードではなく生成されたアセンブリを配置することで、このリスクを回避できます。ただし、その場合、容易なサイト更新が持つ利点の一部を失います)。
配置には、アセンブリまたはコードをサーバーにコピーするタスクとは別のタスクが必要になることもよくあります。たとえば、データベーススクリプトを運用環境で実行する必要がある場合や、Web.config ファイルの接続文字列は運用サーバーに合わせて変更する必要がある場合があります。 Visual Studio には、Web アプリケーションプロジェクトを操作してこのようなタスクの多くを自動化できるワンクリック発行などのツールが用意されています。このようなツールは Web サイトプロジェクトには使用できません。

Web サイトプロジェクトの配置戦略の利点は以下のとおりです。

Web アプリケーションのごく一部を変更する場合、アプリケーション全体を再配置する必要はありません。変更したファイルを運用 IIS サーバーにコピーするだけです。運用サーバー上でファイルを直接編集することもできます (Web アプリケーションプロジェクトのコードファイルは単一のアセンブリファイルにコンパイルされるため、.aspx ファイルまたは .ascx ファイルのみが変更された場合を除き、少しの変更でもサイト全体を配置する必要があります)。