ASP.NET WebサイトまたはASP.NET Webアプリケーション？
回答:
ウェブサイト：
Webサイトプロジェクトはその場でコンパイルされます。最終的には、より多くのDLLファイルが作成されることになり、苦痛になる可能性があります。他のディレクトリがまだコードにコンパイルされていない可能性があるため、別のディレクトリのページとコントロールを参照する必要があるページまたはコントロールがあるディレクトリにある場合にも問題が発生します。もう1つの問題はパブリッシングにあります。
Visual Studioが常に同じ名前を再利用するように指示されていない場合は、常にページによって生成されるDLLファイルの新しい名前が付けられます。これにより、同じクラス名を含むDLLファイルのいくつかの近いコピーが作成され、多くのエラーが生成される可能性があります。WebサイトプロジェクトはVisual Studio 2005で導入されましたが、人気がないことが判明しました。
ウェブアプリケーション：
Webアプリケーションアドイン今とは、Visual Studio 2005のWebアプリケーションプロジェクトは、それは意志のVisual Studio 2003に同梱されたWebプロジェクトに似て動作するように設計されたされている主な違いについてSP 1の一部として存在しているとして、プロジェクトが作成されましたビルド時にアプリケーションを1つのDLLファイルにコンパイルします。プロジェクトを更新するには、プロジェクトを再コンパイルして、変更を行うためにDLLファイルを公開する必要があります。
Webアプリケーションプロジェクトのもう1つの優れた機能は、プロジェクトビューからファイルを除外する方がはるかに簡単です。Webサイトプロジェクトでは、除外する各ファイルは、ファイル名に除外キーワードを使用して名前が変更されます。Webアプリケーションプロジェクトでは、プロジェクトは、ファイルの名前を変更することなく、プロジェクトビューに含める/除外するファイルを追跡するだけなので、物事をより整然とすることができます。
記事「ASP.NET 2.0-Webサイトvs Webアプリケーションプロジェクト」では、なぜ一方を使用し、もう一方を使用しないのかについての理由も説明しています。以下がその抜粋です。
- 大規模なVisual Studio .NET 2003アプリケーションをVS 2005に移行する必要がありますか？Webアプリケーションプロジェクトを使用します。
- プロジェクトファイルを作成せずに、任意のディレクトリをWebプロジェクトとして開いて編集しますか？Webサイトプロジェクトを使用します。
- コンパイル中にビルド前とビルド後のステップを追加する必要がありますか？ Webアプリケーションプロジェクトを使用します。
- 複数のWebプロジェクトを使用してWebアプリケーションを構築する必要がありますか？Webアプリケーションプロジェクトを使用します。
- ページごとに1つのアセンブリを生成しますか？Webサイトプロジェクトを使用します。
- 各ページビューでサイト全体を構築することなく、動的なコンパイルとページでの作業を好みますか？Webサイトプロジェクトを使用します。
- コードビハインドモデルよりも単一ページのコードモデルの方が好きですか？Webサイトプロジェクトを使用します。
WebアプリケーションプロジェクトとWebサイトプロジェクト（MSDN）の比較では、WebサイトとWebアプリケーションプロジェクトの違いについて説明しています。また、Visual Studioで行う構成についても説明します。
Webサイトは、IISなどのASP.NET Webサーバーに展開するものです。ファイルとフォルダのほんの一部です。Visual Studioに関連付けられているWebサイトには何もありません（プロジェクトファイルはありません）。Webページ（.aspx、.ascx、.masterなど）のコード生成とコンパイルは、実行時に動的に行われ、これらのファイルへの変更はフレームワークによって検出され、自動的に再コンパイルされます。ページ間で共有するコードを特別なApp_Codeフォルダーに配置するか、それをプリコンパイルしてアセンブリをBinフォルダーに配置できます。
Webアプリケーションは、特別なVisual Studioプロジェクトです。Webサイトとの主な違いは、プロジェクトをビルドすると、すべてのコードファイルが単一のアセンブリにコンパイルされ、binディレクトリに配置されることです。Webサーバーにコードファイルをデプロイしません。共有コードファイル用の特別なフォルダーを用意する代わりに、クラスライブラリの場合と同じように、どこにでもファイルを配置できます。Webアプリケーションには、プロジェクトやコードファイルなど、展開することを想定していないファイルが含まれているため、Webサイトを指定した場所に出力するためのVisual Studioの[ 発行]コマンドがあります。
App_CodeとBin
共有コードファイルをデプロイすることは一般的に悪い考えですが、それはWebアプリケーションを選択する必要があるという意味ではありません。Webサイトのすべてのコードを保持するクラスライブラリプロジェクトを参照するWebサイトを持つことができます。Webアプリケーションは、そのための便利な方法です。
コードビハインド
このトピックは、.aspxファイルと.ascxファイルに固有です。このトピックは、分離コードファイルを使用しないASP.NET MVCやASP.NET Webページなどの新しいアプリケーションフレームワークとの関連性が低くなります。
.aspxページのコードビハインドファイルや.ascxコントロールを含むすべてのコードファイルを単一のアセンブリにコンパイルすることで、Webアプリケーションで小さな変更ごとに再構築する必要があり、ライブの変更を行うことはできません。変更を確認するために再構築を続ける必要があるため、これは開発中に本当の苦痛になる可能性がありますが、Webサイトでは、ランタイムによって変更が検出され、ページ/コントロールが自動的に再コンパイルされます。
ランタイムにコードビハインドアセンブリを管理させることは、ページ/コントロールに一意の名前を付けたり、それらを異なる名前空間に整理したりする必要がないため、作業が少なくて済みます。
（特に共有コードファイルの場合を除いて）コードファイルの展開が常に良いアイデアであると言っているわけではありませんが、分離コードファイルには、UI固有のタスク、ワイヤーアップイベントハンドラーなどを実行するコードのみを含める必要があります。アプリケーションは重要なコードが常にBinフォルダーに配置されるように階層化されています。その場合は、分離コードファイルの展開は有害であると考えるべきではありません。
Webアプリケーションのもう1つの制限は、プロジェクトの言語しか使用できないことです。Webサイトでは、C＃やVBなどでいくつかのページを使用できます。特別なVisual Studioサポートは必要ありません。これが、ビルドプロバイダーの拡張性の利点です。
また、コンパイラーは実行時にコンパイルされるマークアップコード（MVCではMvcBuildViewsオプションを使用してこれを修正できます）ではなく、コードビハインドクラスのみをコンパイルするため、Webアプリケーションではページ/コントロールでエラーが検出されません。
Visual Studio
WebアプリケーションはVisual Studioプロジェクトであるため、Webサイトでは使用できない機能がいくつかあります。たとえば、ビルドイベントを使用して、JavaScriptファイルの縮小や結合など、さまざまなタスクを実行できます。
Visual Studio 2010で導入されたもう1つの優れた機能は、Web.config変換です。これはWebサイトでも利用できません。 VS 2013のWebサイトで動作するようになりました。
特に大規模なサイトの場合、Webアプリケーションの構築はWebサイトの構築よりも高速です。これは主に、Webアプリケーションがマークアップコードをコンパイルしないためです。MVCでは、MvcBuildViewsをtrueに設定すると、マークアップコードがコンパイルされ、エラーが検出されます。これは非常に便利です。欠点は、ソリューションを構築するたびに完全なサイトが構築されることです。これは、特にサイトを編集していない場合は、遅くて非効率的です。l MvcBuildViewsのオン/オフを切り替える（プロジェクトのアンロードが必要）。一方、Webサイトでは、サイトをソリューションの一部として構築するかどうかを選択できます。そうしないことを選択した場合、ソリューションの構築は非常に高速であり、変更を加えた場合は、いつでもWebサイトノードをクリックして[構築]を選択できます。
MVC Webアプリケーションプロジェクトには、「ビューの追加」、「ビューに移動」、「コントローラーの追加」などの一般的なタスク用の追加のコマンドとダイアログがあります。これらはMVC Webサイトでは使用できません。
IIS Expressを開発サーバーとして使用する場合は、Webサイトで仮想ディレクトリを追加できます。このオプションは、Webアプリケーションでは使用できません。
NuGetパッケージの復元はWebサイトでは機能しません。packages.configにリストされているパッケージを手動でインストールする必要がありますパッケージの復元がNuGet 2.7以降の Webサイトで機能するようになりました
Webサイト = Webサイトがグラフィックデザイナーによって作成され、プログラマーが1ページまたは2ページしか編集しない場合に使用します
Webアプリケーション =アプリケーションがプログラマーによって作成され、グラフィックデザイナーが1つまたは2つのページ/イメージのみを編集する場合に使用します。
プロジェクトファイルを更新する必要がないため、開発者スタジオがなくてもWebサイトをHTMLツールを使用して作業できます。Webアプリケーションは、チームがほとんど開発者スタジオを使用しており、コードコンテンツが多い場合に最適です。
（一部のコーディングエラーは、コンパイル時にWebアプリケーションで見つかりますが、実行時までWebサイトでは見つかりません。）
警告： 私は何年も前にこの回答を書き、それ以来Asp.netを使用していません。物事が進んでいると思います。
動的にコンパイルされるプロジェクトに特別な必要がない限り、Webサイトプロジェクトを使用しないでください。
どうして？Webサイトプロジェクトは、プロジェクトを変更または理解しようとするときに、壁を押し上げるからです。Visual Studioの静的型付け検索機能（たとえば、使用法の検索、リファクタリング）は、適切なサイズのプロジェクトではすべて永久にかかります。詳細については、Visual StudioのStack Overflow質問Slow "Find All References"を参照してください。
私は、彼らがVisual Studio 2005でWebアプリケーションをドロップした理由が本当にわかりません。
MSDNには、違いを説明する記事があります。
WebサイトプロジェクトとWebアプリケーションプロジェクトの比較
ところで：そのトピックに関して同様の質問がいくつかあります。例えば：
- Visual StudioでのWebサイトとASP.Net Webアプリケーションの比較 ：削除され、SO上ではなくなりました
- ASP.NETのWebサイトまたはWebアプリケーション
これは少し明白に聞こえるかもしれませんが、Visual Studio 2005は元々Webサイトにのみ同梱されていたため、誤解されていると思います。プロジェクトがかなり制限されており、論理的または物理的な分離があまりないWebサイトを扱っている場合、そのWebサイトは問題ありません。ただし、それが本当に多くのユーザーがデータを追加および更新するさまざまなモジュールを備えたWebアプリケーションである場合は、Webアプリケーションのほうが適しています。
ウェブサイトモデルの最大の利点は、app_codeセクション内のすべてが動的にコンパイルされることです。完全に再デプロイせずにC＃ファイルを更新できます。ただし、これは大きな犠牲になります。制御するのが難しい多くのことが隠れた状況下で起こります。名前空間の制御は困難であり、特定のDLLの使用法は、デフォルトで以下のすべてのものに対してウィンドウの外に出ますapp_code、すべてが動的にコンパイルさ。
Webアプリケーションモデルには動的コンパイルはありませんが、私が述べたことを制御できます。
n層開発を行う場合は、Webアプリケーションモデルを強くお勧めします。限定されたWebサイトを実行している場合、または迅速でダーティな実装を行っている場合は、Webサイトモデルに利点がある場合があります。
より詳細な分析は以下にあります：
MCTSセルフペーストレーニングキット試験70-515の本から：
Webアプリケーション（プロジェクト）では、
- MVCアプリケーションを作成できます。
- Visual Studioは、フォルダー構造に依存するのではなく、ファイルのリストをプロジェクトファイル（.csprojまたは.vbproj）に保存します。
- Visual BasicとC＃を混在させることはできません。
- デバッグセッションを停止せずにコードを編集することはできません。
- 複数のWebプロジェクト間の依存関係を確立できます。
- デプロイ前にアプリケーションをコンパイルする必要があります。これにより、別のページがコンパイルされない場合にページをテストできなくなります。
- サーバーにソースコードを保存する必要はありません。
- アセンブリ名とバージョンを制御できます。
- 再コンパイルしないと、展開後に個々のファイルを編集することはできません。
それはあなたが開発しているものに依存します。
コンテンツ指向のWebサイトではコンテンツが頻繁に変更されるため、Webサイトの方が適しています。
アプリケーションのデータはデータベースに保存される傾向があり、ページとコードはほとんど変更されません。この場合、アセンブリの展開がより制御され、単体テストのサポートが強化されたWebアプリケーションを用意することをお勧めします。
Compilationまず、コンパイルに違いがあります。Webサイトはサーバーで事前にコンパイルされておらず、ファイルでコンパイルされています。Webサイトの何かを変更したい場合は、サーバーから特定のファイルをダウンロードして変更し、このファイルをサーバーにアップロードすればすべて正常に機能するため、これは利点になる可能性があります。Webアプリケーションでは、すべてがプリコンパイルされており、dllが1つしかないため、これを行うことはできません。プロジェクトの1つのファイルで何かを変更した場合、すべてを再コンパイルする必要があります。したがって、サーバーのWebサイトにあるいくつかのファイルを変更する可能性がある場合は、より良いソリューションです。また、多くの開発者が1つのWebサイトで作業することもできます。反対に、サーバーでコードを使用できないようにする場合は、Webアプリケーションを選択する必要があります。
Project structure
プロジェクトの構造にも違いがあります。Webアプリケーションには、通常のアプリケーションと同じようにプロジェクトファイルがあります。Webサイトには、従来のプロジェクトファイルはなく、ソリューションファイルがあります。すべての参照と設定はweb.configファイルに保存されます。
@Page directive
このページに関連付けられたクラスを含むファイルの@Pageディレクティブには別の属性があります。Webアプリケーションでは標準の "CodeBehind"、Webサイトでは "CodeFile"を使用します。以下の例でこれを確認できます。
ウェブアプリケーション：
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="WebApplication._Default" %> ウェブサイト：
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 名前空間-上記の例では、別の違い、つまり名前空間の作成方法も確認できます。Webアプリケーションでは、名前空間は単にプロジェクトの名前です。Webサイトには、動的にコンパイルされるページ用のデフォルトの名前空間ASPがあります。
エディットコンティニュ-Webアプリケーションのエディットコンティニューオプションが利用できます（これをオンにするには、[ツール]メニューに移動し、[オプション]をクリックして、[デバッグ]で[エディットコンティニュ]を見つけます）。この機能は、Web Site.ASP.NET MVCでは機能しません。
ASP.NET MVC（Model View Controller）の最適なデフォルトオプションはWebアプリケーションです。WebサイトでMVCを使用することは可能ですが、お勧めできません。
概要-ASP.NET WebアプリケーションとWebサイトの最も重要な違いはコンパイルです。したがって、少数の人が変更できる大きなプロジェクトで作業する場合は、Webサイトを使用することをお勧めします。ただし、小規模なプロジェクトを実行している場合は、Webアプリケーションも使用できます。
はい、Webアプリケーションは私たちに自由を与えるので、Webサイトよりもはるかに優れています。
1つの傘の下に複数のプロジェクトを持ち、プロジェクト間の依存関係を確立する。たとえば、PCSの場合、Webアプリケーション内で次のことができます。
- ウェブポータル
- 通知コントローラー（Eメール送信用）
- ビジネス層
- データアクセス層
- 例外マネージャー
- サーバーユーティリティ
- WCFサービス（すべてのプラットフォームに共通）
- リストアイテム
ASP.NETページに関連付けられているクラスファイル内のコードで単体テストを実行するには
- スタンドアロンクラスのページとユーザーコントロールに関連付けられているクラスを参照するには
- サイト全体に対して単一のアセンブリを作成するには
- サイト用に生成されるアセンブリ名とバージョン番号の制御
- 本番サーバーにソースコードを配置しないようにするため。（IISサーバーへのソースコードの展開を回避できます。共有ホスティング環境などの一部のシナリオでは、IISサーバー上のソースコードへの不正アクセスが懸念される場合があります。（Webサイトプロジェクトの場合、このリスクを回避できます。開発コンピューターでプリコンパイルし、ソースコードの代わりに生成されたアセンブリを展開します。ただし、その場合、サイトを簡単に更新できるという利点の一部が失われます。）
- Webサイトのパフォーマンスの問題（Webサイトへの最初のリクエストでは、サイトのコンパイルが必要になる場合があり、遅延が発生する可能性があります。また、Webサイトがメモリ不足のIISサーバーで実行されている場合、サイト全体を含む単一のアセンブリは、複数のアセンブリに必要とされるよりも多くのメモリを使用する場合があります。）
主な違いの1つは、Webサイトが動的にコンパイルされ、その場でアセンブリを作成することです。Webアプリケーションは、1つの大きなアセンブリにコンパイルされます。
この2つの違いは、Visual Studio 2008では廃止されました。
アプリケーションは通常、Webサイトがapp_codeディレクトリを利用するように、展開前にコンパイルされます。アプリのコードフォルダーで何かが変更されると、サーバーはコードを再コンパイルします。これは、ウェブサイトを使ってコードをその場で追加/変更できることを意味します。
アプリの利点は、再コンパイルがないため、初回の起動時間が短縮されることです。
WebアプリケーションプロジェクトとWeb配置プロジェクトのビデオをご覧になることをお勧めしますASP.NET Webサイトで、違いを非常に詳しく説明する。これは私にとって非常に役に立ちました。
ちなみに、タイトルと混同しないでください。ビデオの大部分は、WebサイトプロジェクトとWebアプリケーションプロジェクトの違いと、MicrosoftがVisual Studio 2005でWebアプリケーションプロジェクトを再導入した理由を説明しています（おそらくご存じのとおり、当初はWebサイトプロジェクトのみで出荷されていたため、WebアプリケーションプロジェクトがSP1で追加されました。違いを知りたい人には是非オススメしたい動画です。
「Webサイト」のコードは特別なApp_Codeディレクトリにあり、実行時にいくつかのDLL（アセンブリ）にコンパイルされます。「Webアプリケーション」は、1つのDLLにプリコンパイルされています。
WebサイトとProject >> websiteは、Visual Studioを使用してASP.NETアプリケーションを作成する2つの異なる方法です。1つはプロジェクトレスで、もう1つはプロジェクト環境です。違いは
- ソリューションファイルは、プロジェクト環境のルートディレクトリと同じディレクトリに保存されます。
- プロジェクト環境にデプロイする前に、ソリューションとプロジェクトファイルを削除する必要があります。
- 完全なルートディレクトリがプロジェクトレス環境にデプロイされます。
どちらの方法を使用しても基本的な違いはほとんどありません。ただし、時間がかかるWebサイトを作成する場合は、プロジェクト環境を選択してください。
Webアプリケーションプロジェクトモデル
- Visual Studio .NET Webプロジェクトと同じWebプロジェクトセマンティクスを提供します。プロジェクトファイル（プロジェクトファイルに基づく構造）があります。ビルドモデル-プロジェクト内のすべてのコードが単一のアセンブリにコンパイルされます。IISと組み込みのASP.NET開発サーバーの両方をサポートします。Visual Studio 2005（リファクタリング、ジェネリックスなど）とASP.NET（マスターページ、メンバーシップとログイン、サイトナビゲーション、テーマなど）のすべての機能をサポートします。FrontPage Server Extensions（FPSE）を使用する必要はなくなりました。
Webサイトプロジェクトモデル
- プロジェクトファイルなし（ファイルシステムに基づく）。
- 新しいコンパイルモデル。
- 各ページビューでサイト全体を構築することなく、ページを動的に編集して作業します。
- IISと組み込みのASP.NET開発サーバーの両方をサポートします。
- 各ページには独自のアセンブリがあります。
- 異なるコードモデル。
Webサイト-ソリューションファイルは作成されません。ウェブサイトを作成したい場合は、ビジュアルスタジオは必要ありません。
Webアプリケーション-ソリューションファイルが作成されます。Webアプリケーションを作成する場合は、ビジュアルスタジオが必要です。.dllbinフォルダーに1つのファイルを作成します。
WebSite： app_codeフォルダーを自動的に生成します。サーバーに公開すると、特定のファイルまたはページに変更を加えると、すべてのファイルをコンパイルする必要がなくなります。
Webアプリケーションこれは、Webサイトが生成しないソリューションファイルを自動的に生成します。1つのファイルを変更した場合、プロジェクト全体をコンパイルしてその変更を反映する必要があります。
Webアプリケーションでは、プロジェクトの機能のレイヤーを作成し、それを多くのプロジェクトに分割することでそれらのレイヤー間の相互依存関係を作成できますが、これをWebサイトで行うことはできません。
間違いなくWebアプリケーション、単一のDLLファイル、維持が容易。しかし、ウェブサイトはより柔軟です。外出先でaspxファイルを編集できます。
Webアプリケーションはより多くのメモリを必要とします。おそらく、単一のアセンブリにコンパイルするしかないためです。大規模なレガシーサイトをWebアプリケーションに変換したところ、コンパイル時に、次のようなエラーメッセージが表示され、メモリ不足の問題が発生しました。
Unexpected error writing metadata to file '' --
Not enough storage is available to complete this operation. エラー、および実行時に以下のようなこのエラーメッセージが表示されます。
Exception information:
Exception type: HttpException
Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()メモリに制約のあるレガシーハードウェアで大規模なサイトを変換するための私の推奨は、Webサイトモデルに戻すオプションを選択することです。最初の成功後でも、後で問題が発生する可能性があります。
ここでは、Web支援アプリケーションがWebサイトの例です。WebサイトとWebアプリケーションはどちらも動的/静的であり、要件によって異なります。ここでは、WebサイトとWebアプリケーションの動作を理解するための例を示します。
上記の回答のいくつかを要約すると：
柔軟性、Webページにライブの変更を加えることができますか？
Webサイト：可能です。プロ：短期的なメリット。短所：プロジェクトの混乱の長期的なリスク。
Webアプリ：短所：できません。ページを編集し、ソース管理への変更をアーカイブしてから、サイト全体を構築して展開します。プロ：質の高いプロジェクトを維持する。
開発の問題
Webサイト：.csprojファイルのない単純なプロジェクト構造。2つの.aspxページは、競合することなく同じクラス名を持つことができます。ランダムなプロジェクトディレクトリ名により、.netフレームワークが独自の生成ファイルと競合する理由や、.netフレームワークが独自の生成ファイルと競合する理由などのビルドエラーが発生する。プロ：シンプル（単純）。短所：不安定。
Webアプリ：.csprojファイルを使用した、WebFormsプロジェクトと同様のプロジェクト構造。ASPページのクラス名は一意である必要があります。プロ：シンプル（スマート）。欠点：なし。Webアプリはまだシンプルです。