ASP.NET WebサイトまたはASP.NET Webアプリケーション?


Visual Studioで新しいASP.NETプロジェクトを開始すると、ASP.NET Webアプリケーションを作成することも、ASP.NET Webサイトを作成することもできます。

ASP.NET WebアプリケーションとASP.NET Webサイトの違いは何ですか? なぜ私は他のものを選ぶだろうか?

回答は、使用しているVisual Studioのバージョンによって異なりますか?


Answers



ウェブサイト:

Webサイトプロジェクトは、オンザフライでコンパイルされます。 多くのDLLファイルが残ってしまいます。これは苦痛になりかねません。 あるディレクトリにページやコントロールを置いて、ページやコントロールを別のディレクトリで参照する必要がある場合には、別のディレクトリがまだコードにコンパイルされていない可能性があるため、問題が発生します。 出版には別の問題があります。

Visual Studioに同じ名前を常に再使用するように指示されていない場合は、常にページによって生成されたDLLファイルの新しい名前が生成されます。 これは、同じクラス名を含むDLLファイルのいくつかのクローズ・コピーを持つことにつながり、多くのエラーが発生します。 WebサイトプロジェクトはVisual Studio 2005で導入されましたが、非常に人気がないことが判明しました。

ウェブアプリケーション:

Web Application Projectはアドインとして作成され、現在はVisual Studio 2005のSP 1の一部として存在しています。主な違いは、Web Application ProjectはVisual Studio 2003に同梱されているWebプロジェクトと同様に動作するように設計されていることです。ビルド時にアプリケーションを単一のDLLファイルにコンパイルします。 プロジェクトを更新するには、再コンパイルして、変更が発行されるようにDLLファイルを発行する必要があります。

Webアプリケーションプロジェクトの別の優れた機能は、プロジェクトビューからファイルを除外する方がずっと簡単です。 Webサイトプロジェクトでは、除外する各ファイルのファイル名にexcludeキーワードを付けて名前を変更します。 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サイトとの主な違いは、プロジェクトをビルドするときに、すべてのコードファイルが単一のアセンブリにコンパイルされ、それが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サポートは必要ありません。 それは、ビルドプロバイダの拡張性の美しさです。

また、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に設定すると、マークアップコードがコンパイルされ、エラー検出が行われ、非常に便利です。 欠点は、ソリューションをビルドするたびに、完全なサイトを構築することです。サイトを編集していない場合は、時間がかかり、効率が悪くなる可能性があります。 私はMvcBuildViewsのオンとオフを切り替えることができます(プロジェクトのアンロードが必要です)。 一方、Webサイトでは、ソリューションの一部としてサイトを構築するかどうかを選択できます。 そうでない場合は、ソリューションを構築するのが非常に高速です。変更を加えたら、いつでもWebサイトノードをクリックして[ビルド]を選択することができます。

MVC Webアプリケーションプロジェクトでは、 'Add View'、 'Go To View'、 'Add Controller'などの一般的なタスクのための余分なコマンドとダイアログがあります。これらはMVC Webサイトでは利用できません。

IIS Expressを開発サーバーとして使用する場合は、Webサイトで仮想ディレクトリを追加できます。 このオプションはWebアプリケーションでは使用できません。

NuGetパッケージのリストアはWebサイトでは機能しません。packages.configにリストされているパッケージを手動でインストールする必要があります パッケージの復元は、 NuGet 2.7を起動するWebサイトでも動作するようになりました




ウェブサイト =ウェブサイトがグラフィックデザイナーによって作成され、プログラマーが1ページまたは2ページのみを編集するときに使用する

Web Application =プログラマによってアプリケーションが作成され、グラフィックデザイナが1つまたは2つのページ/イメージのみを編集するときに使用します。

開発者のスタジオを持たなくても、プロジェクトファイルを更新する必要がないため、WebサイトはあらゆるHTMLツールを使用して作業することができます。チームが主に開発スタジオを使用し、コードコンテンツが多い場合に最適です。

(一部のコーディングエラーは、コンパイル時にWebアプリケーションに表示されますが、実行時までWebサイトには表示されません)。

警告: 私はこの答えを何年も前に書き、Asp.netを使っていません。 私は物事が今に移動したことを期待しています。




動的にコンパイルされたプロジェクトが必要な場合を除き、Webサイトプロジェクトを使用しないください

どうして? プロジェクトを変更または理解しようとすると、Webサイトプロジェクトが壁を駆け上がらせるためです。 Visual Studioのスタティックなタイプの検索機能(たとえば、使用法、リファクタの検索)は、すべての合理的なサイズのプロジェクトで永遠に使用されます。 詳細については、Visual Studioの「すべての参照を検索」の「スタックオーバーフローの問題」を参照してください。

Visual Studio 2005のWebアプリケーションを、痛みを誘発し、健全性を損なう、生産性の高いウェブサイトのプロジェクトタイプのためにドロップした理由は、実際には分かりません。







これは少しはっきりと聞こえるかもしれませんが、Visual Studio 2005は当初Webサイトにのみ付属していたので、間違っていると思います。 あなたのプロジェクトがかなり限定されており、論理的または物理的な分離がほとんどないウェブサイトを扱う場合、ウェブサイトは問題ありません。 しかし、多くのユーザーがデータを追加したり更新したりするモジュールが異なる本当のWebアプリケーションであれば、Webアプリケーションを使う方がよいでしょう。

Webサイトモデルの最大のapp_codeは、 app_codeセクションのapp_codeが動的にコンパイルされることです。 C#ファイルを完全に再デプロイせずに更新することができます。 しかし、これは大きな犠牲になります。 カバーの下では制御が難しい多くのことが起こります。 名前空間は制御が難しく、すべてが動的にコンパイルされるので、特定のDLLの使用がapp_code下ではデフォルトでウィンドウの外に出ます。

Webアプリケーションモデルには動的コンパイルはありませんが、あなたが言及したことを制御できます。

n層の開発を行っている場合は、Webアプリケーションモデルを強くお勧めします。 限られたWebサイトや迅速で汚れた実装を行っている場合、Webサイトモデルには利点があります。

より詳細な分析は、




MCTSの自己ペーストレーニングキット試験70-515本から:

Webアプリケーション(プロジェクト)では、

  1. MVCアプリケーションを作成できます。
  2. Visual Studioは、フォルダ構造に頼るのではなく、プロジェクトファイル(.csprojまたは.vbproj)にファイルのリストを格納します。
  3. Visual BasicとC#を混在させることはできません。
  4. デバッグセッションを停止せずにコードを編集することはできません。
  5. 複数のWebプロジェクト間で依存関係を確立できます。
  6. デプロイする前にアプリケーションをコンパイルする必要があります。これにより、別のページがコンパイルされない場合にページをテストできなくなります。
  7. ソースコードをサーバーに保存する必要はありません。
  8. アセンブリの名前とバージョンを制御できます。
  9. デプロイメント後、再コンパイルせずに個々のファイルを編集することはできません。



それはあなたが開発しているものによって異なります。

コンテンツ指向のウェブサイトは頻繁に変化するコンテンツを持ち、ウェブサイトはそれに適しています。

アプリケーションは、そのデータをデータベースに格納し、そのページとコードの変更はめったにありません。 この場合、アセンブリのデプロイメントがはるかに制御され、単体テストのサポートが強化されたWebアプリケーションを使用する方がよいでしょう。




Compilationまず、コンパイルの違いがあります。 Webサイトはサーバー上であらかじめコンパイルされていないため、ファイルにコンパイルされています。 Webサイトで何かを変更したいときは、サーバーから特定のファイルをダウンロードして変更し、このファイルをサーバーにアップロードすればすべてが正常に動作するため、利点があります。 Webアプリケーションでは、何もプレコンパイルされておらず、1つのdllだけで終わるので、これを行うことはできません。 プロジェクトの1つのファイルで何かを変更する場合は、すべてを再度コンパイルする必要があります。 サーバー上のいくつかのファイルを変更する可能性がある場合は、Webサイトがより良い解決策です。 また、多くの開発者が1つのWebサイトで作業することができます。 反対に、サーバーでコードを使用できないようにするには、Webアプリケーションを選択する必要があります。 このオプションは、Webサイトの公開後に1つのDLLファイルが作成されるため、単体テストの方が優れています。

Project structureも違いがあります。 Webアプリケーションでは、通常のアプリケーションと同じようにプロジェクトファイルがあります。 Webサイトには伝統的なプロジェクトファイルがありません。あなたが持っているのはソリューションファイルだけです。 すべての参照と設定はweb.configファイルに保存されています。 @Page directiveには、このページに関連付けられたクラスを含むファイルとは異なる属性があります。 Webアプリケーションでは、標準的な "CodeBehind"で、Webサイトでは "CodeFile"を使用します。 以下の例でこれを見ることができます:

Web Application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

Webサイト:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

名前空間 - 上記の例では、名前空間がどのように作成されるかという別の違いも確認できます。 Webアプリケーションの名前空間は、単にプロジェクトの名前です。 Webサイトには、動的にコンパイルされたページ用のデフォルト名前空間ASPがあります。

編集と続行 - Web Application Edit and Continueオプションが有効になります(これを有効にするには、[ツール]メニューに移動し、[オプション]をクリックして[デバッグで編集して続行]を選択します)。 この機能はWebサイトでは機能していません.ASP.NET MVCIを使用してWebアプリケーションを開発したい

ASP.NET MVC(Model View Controller)は、Webアプリケーションです。 WebサイトでMVCを使用することは可能ですが、推奨されません。

まとめ - ASP.NET WebアプリケーションとWebサイトの最も重要な違いは、コンパイルです。 だから、もしあなたがそれを修正することができるより大きなプロジェクトに取り組んでいるのであれば、Webサイトを使うほうが良いでしょう。 しかし、より小さなプロジェクトをやっているなら、Webアプリケーションを使うこともできます。




重要な違いの1つは、Webサイトが動的にコンパイルされ、オンザフライのアセンブリを作成することです。 Webアプリケーションは、1つの大きなアセンブリにコンパイルされます。

この2つの違いは、Visual Studio 2008で取り除かれています。




Webアプリケーションは私たちに自由を与えるので、WebアプリケーションはWebサイトよりはるかに優れています。

  1. 1つの傘の下に複数のプロジェクトを持ち、プロジェクトの依存関係を確立する。 たとえば、Webアプリケーション内で以下のようにすることができます。

    • Webポータル
    • 通知コントローラ(電子メール送信用)
    • ビジネス層
    • データアクセス層
    • 例外マネージャ
    • サーバーユーティリティ
    • WCFサービス(すべてのプラットフォーム共通)
    • リストアイテム
  2. ASP.NETページに関連付けられているクラスファイル内のコードに対して単体テストを実行するには

  3. スタンドアロンクラスのページやユーザーコントロールに関連付けられているクラスを参照する
  4. サイト全体に対して単一のアセンブリを作成するには
  5. サイトに対して生成されたアセンブリ名とバージョン番号の制御
  6. プロダクションサーバーにソースコードを置かないようにする。 (IISサーバーへのソースコードの配布は避けることができます。共有ホスティング環境などのいくつかのシナリオでは、IISサーバー上のソースコードへの不正アクセスが懸念される場合があります(Webサイトプロジェクトの場合、開発用コンピュータで事前にコンパイルし、ソースコードではなく生成されたアセンブリを展開することができますが、その場合は簡単にサイトを更新できるという利点があります。
  7. ウェブサイトのパフォーマンスに関する問題(ウェブサイトへの最初のリクエストでは、サイトがコンパイルされ、遅延が発生する可能性があります。また、ウェブサイトがメモリ不足のIISサーバー上で実行されている場合単一のアセンブリは、複数のアセンブリに必要とされるより多くのメモリを使用する可能性があります。)



アプリケーションは通常、配備前にコンパイルされます。ここでは、Webサイトでapp_codeディレクトリを使用します。 アプリコードフォルダ内の何かが変更されると、サーバはコードを再コンパイルします。 つまり、Webサイトでコードを追加/変更することができます。

アプリの利点は、再コンパイルがないため、最初の起動時間が短縮されることです。




ASP.NET WebサイトでビデオWebアプリケーションプロジェクトとWebデプロイメントプロジェクトを見てみることをお勧めします。違いについては詳しく説明してくれました。

ところで、タイトルで混乱しないでください。ビデオの大部分は、WebサイトプロジェクトとWebアプリケーションプロジェクトの違いについて説明しています。また、Visual Studio 2005でWebアプリケーションプロジェクトを再導入した理由についても説明しています。もともとはウェブサイトプロジェクトだけで出荷され、SP1ではWebアプリケーションプロジェクトが追加されました)。 違いを知りたいと思う人には、すばらしいビデオです。




「Webサイト」は特別なApp_Codeディレクトリにコードを持ち、実行時にいくつかのDLL(アセンブリ)にコンパイルされます。 「Webアプリケーション」は1つのDLLにプリコンパイルされています。




ウェブサイトとプロジェクト>>ウェブサイトは、Visual Studioを使用してASP.NETアプリケーションを作成する2つの異なる方法です。 1つはプロジェクトがなく、もう1つはプロジェクト環境です。 違いは

  1. ソリューションファイルはプロジェクト環境のルートディレクトリと同じディレクトリに保存されます。
  2. プロジェクト環境に展開する前にソリューションとプロジェクトファイルを削除する必要があります。
  3. 完全なルートディレクトリは、プロジェクトレス環境で展開されます。

いずれのアプローチを使用する場合も基本的な違いはありません。 しかし、より長い時間がかかるウェブサイトを作成している場合は、プロジェクト環境を選択してください。




Webアプリケーションプロジェクトモデル

  • Visual Studio .NET Webプロジェクトと同じWebプロジェクトセマンティクスを提供します。 プロジェクトファイル(プロジェクトファイルに基づいた構造)を持っています。 ビルドモデル - プロジェクト内のすべてのコードが単一のアセンブリにコンパイルされます。 IISと組み込みのASP.NET開発サーバーの両方をサポートします。 Visual Studio 2005のすべての機能(リファクタリング、ジェネリックスなど)とASP.NET(マスターページ、メンバーシップ、ログイン、サイトナビゲーション、テーマなど)をサポートします。 FrontPage Server Extensions(FPSE)を使用する必要はなくなりました。

Webサイトプロジェクトモデル

  • プロジェクトファイルがありません(ファイルシステムに基づいています)。
  • 新しいコンパイルモデル。
  • 各ページビューにサイト全体を構築せずに動的コンパイルとページ上での作業。
  • IISと組み込みのASP.NET開発サーバーの両方をサポートします。
  • 各ページには独自のアセンブリがあります。
  • デファレンシャルコードモデル。



それは常にあなたのクライアントの要件に依存しています。 ASP.NETには、セキュリティのために必要な柔軟な機能と、アプリケーションのメンテナンスが含まれています。

Webアプリケーションは、ASP.NETフレームワーク内で実行されるバイナリファイルと考えることができます。 また、 Webサイトを静的なWebページとしてレビューし、ソースコードを簡単に展開することができます。

しかし、これらの2つのASP.NETテクノロジの利点と欠点は、何が良いのかになります。




Webアプリケーションプロジェクトでは、Visual Studioにページとユーザーコントロール用の.designerファイルがさらに必要です。 Webサイトプロジェクトではこのオーバーヘッドは必要ありません。 マークアップ自体はデザインとして解釈されます。




WebSite: app_codeフォルダを自動的に生成し、それをサーバーに公開した後、特定のファイルやページで何らかの変更を加えた場合、すべてのファイルをコンパイルする必要はありません。

Web Applicationそれは自動的に解決策ファイルを生成します。どのWebサイトでも生成されません。変更を反映するためにプロジェクト全体をコンパイルする必要があります。




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アプリケーション、単一のDLLファイルと簡単に維持する。 しかし、ウェブサイトはより柔軟性があります。 あなたは外出先でaspxファイルを編集することができます。




ここでWeb Supportive ApplicationはWebサイトの一例です。 ウェブサイトとWebアプリケーションの両方がダイナミック/静的になることができます。要件に依存します。ここでは、ウェブサイトとWebアプリケーションの作業を理解するための例を示します。




ウェブサイト - ソリューションファイルは作成されません。 私たちは、Webサイトを作成したい場合は、Visual Studioの必要はありません。

Webアプリケーション - ソリューションファイルが作成されます。 Webアプリケーションを作成したい場合は、ビジュアルスタジオが必要です。 binフォルダー内に単一の.dllファイルが作成されます。