ASP.NET WebサイトまたはASP.NET Webアプリケーションのどちらですか。
Visual Studioで新しいASP.NETプロジェクトを開始するときに、ASP.NET Webアプリケーションを作成することも、ASP.NET Webサイトを作成することもできます。
ASP.NET WebアプリケーションとASP.NET Webサイトの違いは何ですか？なぜ私は他のものを選ぶのでしょうか？
答えは、使用しているVisual Studioのバージョンによって異なりますか？
ウェブサイト：
Web Siteプロジェクトはその場でコンパイルされます。あなたはもっとたくさんのDLLファイルを作成することになりますが、これは面倒かもしれません。他のディレクトリはまだコードにコンパイルされていない可能性があるため、他のディレクトリのページやコントロールを参照する必要があるページまたはコントロールがあるディレクトリにあるときにも問題が発生します。もう一つの問題は出版にあります。
Visual Studioが常に同じ名前を再利用するように指示されていない場合は、常にページによって生成されるDLLファイルに新しい名前が付けられます。そのため、同じクラス名を含むDLLファイルのコピーが複数作成される可能性があります。これにより、多くのエラーが発生します。 WebサイトプロジェクトはVisual Studio 2005で導入されましたが、それほど人気があるわけではありません。
Webアプリケーション：
Webアプリケーションプロジェクトはアドインとして作成され、現在はVisual Studio 2005用のSP 1の一部として存在しています。ビルド時にアプリケーションを単一のDLLファイルにコンパイルします。プロジェクトを更新するには、プロジェクトを再コンパイルし、DLLファイルを発行して変更を反映させる必要があります。
Webアプリケーションプロジェクトのもう1つの優れた機能は、プロジェクトビューからファイルを除外することがはるかに簡単になることです。 Webサイトプロジェクトで、除外する各ファイルは、ファイル名の除外キーワードで名前が変更されます。 Webアプリケーションプロジェクトでは、プロジェクトは名前を変更せずにどのファイルをプロジェクトビューに含めるか除外するかを追跡するだけなので、作業がかなり面倒になります。
記事{ASP.NET 2.0 - Webサイトと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サーバーに展開するものです。ほんの一群のファイルとフォルダー。 WebサイトにVisual Studioを結び付けるものは何もありません（プロジェクトファイルはありません）。 Webページ（.aspx、.ascx、.masterなど）のコード生成とコンパイルは 実行時に動的に で行われ、これらのファイルへの変更はフレームワークによって検出され、自動的に再コンパイルされます。特別なApp_Codeフォルダーに ページ間で共有 にするコードを配置するか、プリコンパイルしてアセンブリをBinフォルダーに配置できます。
Webアプリケーションは、特別なVisual Studioプロジェクトです。 Webサイトとの主な違いは、プロジェクトをビルドすると、すべてのコードファイルが1つのアセンブリにコンパイルされ、binディレクトリに配置されることです。コードファイルをウェブサーバーにデプロイしません。共有コードファイル用の特別なフォルダーを用意する代わりに、クラスライブラリで行うように、どこにでも配置できます。 Webアプリケーションには、プロジェクトファイルやコードファイルなど、デプロイすることを意図していないファイルが含まれているため、Visual Studioには、指定した場所にWebサイトを出力する Publish コマンドがあります。
App_Code vs Bin
共有コードファイルを展開することは一般的に悪い考えですが、だからと言ってWebアプリケーションを選択する必要はありません。 Webサイトのすべてのコードを保持するクラスライブラリプロジェクトを参照するWebサイトを作成できます。 Webアプリケーションは、それを行う便利な方法です。
CodeBehind
このトピックは、.aspxおよび.ascxファイルに固有です。このトピックは、コードビハインドファイルを使用しないASP.NET MVCやASP.NET Webページなどの新しいアプリケーションフレームワークに関連性が低下しています。
codebehind .aspxページと.ascxコントロールのファイルを含むすべてのコードファイルを単一のアセンブリにコンパイルすることにより、Webアプリケーションで小さな変更ごとに再構築する必要があり、ライブ変更を行うことができません。 。 Webサイトでは変更がランタイムによって検出され、ページ/コントロールが自動的に再コンパイルされますが、変更を確認するには再構築を続ける必要があるため、これは開発中の本当の苦痛になります。
ページ/コントロールに一意の名前を付けたり、異なる名前空間に整理したりすることを心配する必要がないため、コードビハインドアセンブリをランタイムで管理する方が手間がかかりません。
コードファイルの展開は常に良いアイデアだとは言いませんが（特に共有コードファイルの場合はそうではありません）、分離コードファイルにはUI固有のタスク、ワイヤーアップイベントハンドラーなどを実行するコードのみを含める必要があります。重要なコードが常にBinフォルダーに配置されるように階層化されます。その場合、分離コードファイルを展開することは有害とは見なされません。
Webアプリケーションのもう1つの制限は、プロジェクトの言語しか使用できないことです。 Webサイトでは、いくつかのページをC＃、VBなどで使用できます。特別なVisual Studioサポートは不要です。それがビルドプロバイダーの拡張性の美しさです。
また、Webアプリケーションでは、コンパイラーはコードビハインドクラスのみをコンパイルし、マークアップコード（MVCではMvcBuildViewsオプションを使用してこれを修正できます）は実行時にコンパイルされるため、ページ/コントロールでエラー検出を取得しません。
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 Package RestoreはWebサイトでは機能しません。packages.configにリストされているパッケージを手動でインストールする必要があります パッケージの復元がWebサイトで動作するようになりました NuGet 2.7以降
Webサイト = Webサイトがグラフィックデザイナーによって作成され、プログラマーが1ページまたは2ページしか編集しない場合に使用します
Webアプリケーション =アプリケーションがプログラマによって作成され、グラフィックデザイナが1つまたは2つのページングされたイメージのみを編集する場合に使用します。
プロジェクトファイルを更新する必要がないため、Webサイトは開発者スタジオを必要とせずに任意のHTMLツールを使用して作業できます。
（一部のコーディングエラーはコンパイル時にWebアプリケーションに見られ、実行時までWebサイトには見られません。）
警告： 私は何年も前にこの回答を書き、それ以来Asp.netを使っていない。物事は今進んでいると思います。
動的にコンパイルされたプロジェクトが特に必要でない限り、 ウェブサイトのプロジェクト を使わないでください。
どうして？あなたのプロジェクトを変更したり理解しようとすると、Webサイトプロジェクトがあなたを壁に駆り立てます。 Visual Studioの静的型付け検索機能（使用目的の検索、リファクタリングなど）はすべて、適度なサイズのプロジェクトに永久に適用されます。詳細については、スタックオーバーフローの質問Visual Studioの "すべての参照の検索"を参照してください。
痛みを伴う、健全性を損なう、生産性が高いWebサイトのプロジェクトタイプのために、Visual Studio 2005にWebアプリケーションがドロップされた理由は、私には本当にわかりません。
これは少し自明のように思えるかもしれませんが、Visual Studio 2005は元々Webサイトに付属していただけなので、誤解されていると思います。あなたのプロジェクトが、かなり限られていて、論理的または物理的な分離がそれほど多くない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プロジェクト間に依存関係を確立できます。
- デプロイ前にアプリケーションをコンパイルする必要があるため、他のページがコンパイルされない場合はページをテストできません。
- ソースコードをサーバーに保存する必要はありません。
- あなたはアセンブリ名とバージョンを制御することができます。
- 展開後に個々のファイルを再コンパイルせずに編集することはできません。
Compilationまずコンパイルに違いがあります。 Webサイトはサーバー上でプリコンパイルされているのではなく、ファイル上でコンパイルされています。 Webサイト内の何かを変更したい場合は、サーバーから特定のファイルをダウンロードして変更し、このファイルをサーバーにアップロードするだけで問題なく動作するため、利点があるかもしれません。 Webアプリケーションでは、これを行うことはできません。everthingは事前にコンパイルされており、最終的に1つのDLLしか作成されないためです。プロジェクトの1つのファイルで何かを変更した場合は、もう一度すべてを再コンパイルする必要があります。あなたがサーバーのWebサイト上のいくつかのファイルを変更する可能性を持ちたいのであればあなたのためのより良い解決策です。それはまた多くの開発者が1つのWebサイトで作業することを可能にします。反対に、コードをサーバー上で利用可能にしたくない場合は、Webアプリケーションを選択する必要があります。 Webサイトの公開後にDLLファイルが1つ作成されるため、このオプションは単体テストにも適しています。
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サイトでは動作しません。ASP.NETMVCIを使用してWebアプリケーションを開発する場合
ASP.NET MVC（モデルビューコントローラ）の最良かつデフォルトのオプションはWebアプリケーションです。 WebサイトでMVCを使用することは可能ですがお勧めできません。
概要 - ASP.NET WebアプリケーションとWebサイトの最も重要な違いはコンパイルです。したがって、少数の人が変更できるもっと大きなプロジェクトで作業する場合は、Webサイトを使用することをお勧めします。しかし、もっと小さなプロジェクトをやっているのであれば、Webアプリケーションも使うことができます。
それはあなたが開発しているものによって異なります。
コンテンツ志向のWebサイトは頻繁にその内容が変わるでしょう、そしてWebサイトはそれに向いています。
アプリケーションはデータをデータベースに格納し、ページとコードを変更することはめったにありません。この場合は、アセンブリの展開がはるかに制御され、単体テストのサポートが強化されているWebアプリケーションを使用することをお勧めします。
主な違いの1つは、Webサイトが動的にコンパイルされ、その場でアセンブリを作成することです。 Webアプリケーションは1つの大きなアセンブリにまとめられます。
この2つの違いは、Visual Studio 2008ではなくなりました。
Webアプリケーションは私たちに自由を与えてくれるので、WebアプリケーションはWebサイトよりはるかに優れています。
複数のプロジェクトを1つの傘の下に置き、その間にプロジェクトの依存関係を確立する。例えば。 PCSの場合は、Webアプリケーション内で次のようにすることができます。
- Webポータル
- 通知コントローラ（Eメール送信用）
- ビジネス層
- データアクセス層
- 例外マネージャ
- サーバーユーティリティ
- WCFサービス（すべてのプラットフォームに共通）
- リスト項目
ASP.NETページに関連付けられているクラスファイル内のコードで単体テストを実行するには
- スタンドアロンクラスのページおよびユーザーコントロールに関連付けられているクラスを参照する
- サイト全体に対して単一のアセンブリを作成するには
- サイト用に生成されたアセンブリ名とバージョン番号を制御します。
- 本番サーバーにソースコードを配置しないようにする。 （IISサーバーへのソースコードの展開を避けることができます。共有ホスティング環境など、シナリオによっては、IISサーバー上のソースコードへの不正アクセスを懸念する可能性があります（Webサイトの場合）。プロジェクトでは、開発用コンピュータでプリコンパイルし、ソースコードの代わりに生成されたアセンブリをデプロイすることでこのリスクを回避できますが、その場合は簡単なサイト更新の利点が失われます。）
- Webサイトのパフォーマンスの問題（Webサイトへの最初のリクエストでは、サイトのコンパイルが必要になる場合があり、その結果、遅延が発生する可能性があります。また、Webサイトがメモリ不足のIISサーバーで実行されている場合1つのアセンブリ内のサイト全体で、複数のアセンブリに必要とされるよりも多くのメモリを使用する可能性があります。）
Webサイトがapp_codeディレクトリを利用する場合、アプリケーションは通常デプロイ前にコンパイルされます。アプリのコードフォルダーに何か変更があると、サーバーはコードを再コンパイルします。これはあなたがその場でウェブサイトでコードを追加/変更できることを意味します。
アプリの利点は、再コンパイルが行われないため、初期起動時間が短縮されることです。
ASP.NET WebサイトでWebアプリケーションプロジェクトとWeb配置プロジェクトのビデオを見ることをお勧めします。これは違いを詳しく説明しているので、非常に役に立ちました。
ちなみに、タイトルに混乱しないでください。ビデオの大部分は、WebサイトプロジェクトとWebアプリケーションプロジェクトの違い、およびMicrosoftがVisual Studio 2005でWebアプリケーションプロジェクトを再導入した理由を説明しています。当初はWebサイトプロジェクトのみが同梱されていましたが、SP1ではWebアプリケーションプロジェクトが追加されました。違いを知りたい人には、すごくおすすめのビデオです。
「Webサイト」のコードは特別なApp_Codeディレクトリにあり、実行時にいくつかのDLL（アセンブリ）にコンパイルされます。 「Webアプリケーション」は1つのDLLにプリコンパイルされています。
それは常にあなたのクライアントの要求次第です。 ASP.NETには、ユーザーがセキュリティとアプリケーションの簡単なメンテナンスに必要な柔軟な機能が含まれています。
Webアプリケーション は、ASP.NETフレームワーク内で実行されるバイナリファイルと考えることができます。そして Webサイト あなたはソースコードをレビューして簡単にデプロイできる静的なWebページとして。
しかし、これら2つのASP.NETテクノロジの長所と短所は良いことです。
WebサイトとProject >> Webサイトは、ビジュアルスタジオを使用してASP.NETアプリケーションを作成する2つの異なる方法です。ひとつはプロジェクトレス、もうひとつはプロジェクト環境です。違いは
- ソリューションファイルは、プロジェクト環境のルートディレクトリと同じディレクトリに格納されています。
- プロジェクト環境にデプロイする前に、ソリューションファイルとプロジェクトファイルを削除する必要があります。
- 完全なルートディレクトリがプロジェクトレス環境に配置されている。
どちらの方法を使用しても、基本的な違いはそれほどありません。しかし、もっと時間がかかる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アプリケーション - ソリューションファイルが作成されます。 Webアプリケーションを作成したい場合は、ビジュアルスタジオが必要です。 binフォルダに単一の.dllファイルが作成されます。
おそらく単一のアセンブリにコンパイルする以外に選択肢がないため、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アプリケーションで、単一のDLLファイルで、管理も簡単です。しかし、Webサイトはより柔軟です。あなたは外出先でaspxファイルを編集することができます。
Webサイト： app_codeフォルダーを自動的に生成します。それをサーバーに公開した場合、その後、特定のファイルまたはページに何らかの変更を加えた場合は、すべてのファイルをコンパイルする必要はありません。
ウェブアプリケーション それはあなたがその変更を反映するために完全なプロジェクトをコンパイルする必要があるよりあなたが1つのファイルに変更するならばどのウェブサイトが生成しないか自動的にソリューションファイルを生成する。
Webアプリケーションでは、プロジェクトの機能のレイヤを作成し、それを多数のプロジェクトに分割することによってそれらの間の相互依存関係を作成できますが、Webサイトでこれを実行することはできません。
Webアプリケーションプロジェクトでは、Visual Studioにページおよびユーザーコントロール用の追加の.designerファイルが必要です。 Webサイトプロジェクトはこのオーバーヘッドを必要としません。マークアップ自体はデザインとして解釈されます。
ここでWeb Supportive ApplicationはWebサイトの例です。 WebサイトとWebアプリケーションはどちらも要件に応じて動的/静的にすることができます。ここではWebサイトとWebアプリケーションの動作を理解するための例を示します。
上記の答えをいくつか要約すると、
柔軟性 、あなたはWebページに実際の変更を加えることができますか？
Webサイト：可能です。長所：短期的なメリット欠点：プロジェクトの混乱の長期的なリスク。
Web App：欠点：できません。ページを編集し、変更をソース管理にアーカイブしてから、サイト全体を構築してデプロイします。長所：質の高いプロジェクトを維持する。
開発課題
Webサイト：.csprojファイルのない単純なプロジェクト構造。2つの.aspxページが、競合することなく同じクラス名を持つことがあります。 .net frameworkが独自の生成ファイルと競合する理由 および .net frameworkが独自の生成ファイルと競合する理由 長所：単純（単純） Con：不規則です。
Web App：.csprojファイルを含む、WebFormsプロジェクトに似たプロジェクト構造。 ASPページのクラス名は一意である必要があります。 Pro：シンプル（スマート）短所：なし、Webアプリはまだシンプルです。