Веб-сайт ASP.NET або веб-додаток ASP.NET?


848

Коли я запускаю новий проект ASP.NET в Visual Studio, я можу створити веб-додаток ASP.NET або я можу створити веб-сайт ASP.NET.

Чим відрізняється веб-додаток ASP.NET від веб-сайту ASP.NET? Чому я б обрала одну над іншою?

Чи відрізняється відповідь залежно від того, яку версію Visual Studio я використовую?


6
Повне та найновіше (для 4,5) порівняння та пояснення можна знайти тут на сторінці MSDN: Проекти веб-додатків проти проектів веб-сайтів у Visual Studio
Густав

Відповіді:


556

Веб-сайт:

Проект Веб-сайту складається з ходу. У вас з'являється набагато більше файлів DLL, що може бути болем. Це також створює проблеми, коли у вас в одному каталозі є сторінки або елементи керування, на які потрібно посилатись на сторінки та елементи керування в іншому каталозі, оскільки інший каталог ще не може бути скомпільований у код. Ще одна проблема може бути у видавництві.

Якщо Visual Studio не кажуть постійно використовувати ті самі імена, вони з’являться нові імена для файлів DLL, що генеруються сторінками постійно. Це може призвести до наявності декількох близьких копій файлів DLL, що містять однакове ім’я класу, що призведе до безлічі помилок. Проект веб-сайтів був представлений Visual Studio 2005, але він виявився не популярним.

Веб-додаток:

Проект веб-додатків був створений як надбудова, і тепер він є частиною SP 1 для Visual Studio 2005. Основні відмінності полягають у тому, що проект веб-додатків був розроблений так, як веб-проекти, що постачаються з Visual Studio 2003. Це буде компілювати додаток в один файл DLL під час збирання. Щоб оновити проект, його потрібно перекомпілювати та опублікувати файл DLL, щоб відбулися зміни.

Ще одна приємна особливість проекту веб-додатків - набагато простіше виключити файли з подання проекту. У проекті Веб-сайт кожен вилучений файл перейменовується на виключене ключове слово у назві файлу. У проекті веб-додатків проект просто відстежує, які файли потрібно включити / виключити з подання проекту, не перейменуючи їх, зробивши речі набагато охайнішими.

Довідково

У статті ASP.NET 2.0 - Проект Веб-сайт проти Веб-додатків також наведено причини того, як використовувати одне, а не друге. Ось уривок до нього:

  • Вам потрібно перенести великі програми Visual Studio .NET 2003 на VS 2005? використовувати проект веб-додатків.
  • Ви хочете відкрити та відредагувати будь-який каталог як веб-проект без створення файлу проекту? використовувати проект веб-сайту.
  • Вам потрібно додати етапи попереднього збирання та після збирання під час компіляції? використовувати проект веб-додатків.
  • Вам потрібно створити веб-додаток, використовуючи кілька веб-проектів? використовувати проект веб-додатків.
  • Ви хочете створити по одній збірці для кожної сторінки? використовувати проект веб-сайту.
  • Ви віддаєте перевагу динамічну компіляцію та роботу над сторінками, не будуючи весь сайт на кожному перегляді сторінки? використовувати проект веб-сайту.
  • Ви віддаєте перевагу односторінковій кодовій моделі перед кодовою моделлю? використовувати проект веб-сайту.

Проекти веб-додатків проти проектів веб-сайтів (MSDN) пояснюють відмінності між веб-сайтом та проектами веб-додатків. Крім того, в ньому обговорюється конфігурація, яку слід зробити в Visual Studio.


5
Ви все ще можете скласти весь свій сайт у dll з веб-сайтом на основі файлів.
dtc

31
Те, як я схильний це думати. Якщо ви програмуєте програму, яка, як правило, використовує HTML як інтерфейс користувача, використовуйте веб-додаток. Якщо у вас є веб-сайт, для якого потрібен трохи Asp.net на кількох його сторінках, використовуйте проект веб-сайту.
Іен Рінгроуз

35
Власне, Проекти веб-додатків були саме оригінальним типом проекту ASP.NET. Вони не "схожі" на проекти, які були у нас у Visual Studio 2003. Вони не були створені як доповнення. Visual Studio 2005 SP1 просто відновив те, що Visual Studio 2005 RTM помилково видалив.
Джон Сондерс

1
Ви можете використовувати вихід WebApplication у проекті WebDeployment. Ви не можете використовувати вихід WebSite у проекті WebDeployment. Якщо ви хочете створити проект розгортання, дотримуйтесь WebApplication. Але для розробки веб-сайт зручніший. Однак конверсія не завжди є проблемою, тому починайте відразу з WebApplication.
Стефан Штайгер

8
@xarzu: У "проектах" веб-сайту немає файлу .csproj або .vbproj. Вони насправді не проекти - вони просто папки, наповнені файлами.
Джон Сондерс

171

Веб-сайт - це те, що ви розгортаєте на веб-сервері ASP.NET, такому як IIS. Просто купа файлів і папок. На веб-сайті немає нічого, що пов’язує вас із Visual Studio (файлу проекту немає). Створення коду та компіляція веб-сторінок (таких як .aspx, .ascx, .master) робиться динамічно під час виконання , і зміни в цих файлах виявляються рамки і автоматично повторно скомпілювати. Ви можете помістити код, який ви хочете поділити між сторінками в спеціальній папці App_Code, або ви можете попередньо скласти його і помістити збірку в папку Bin.

Веб-додаток - це спеціальний проект Visual Studio.Основна відмінність веб-сайтів полягає в тому, що при складанні проекту всі кодові файли збираються в єдину збірку, яка розміщується в каталозі бін. Ви не розгортаєте файли коду на веб-сервері. Замість того, щоб мати спеціальну папку для спільних файлів коду, ви можете розмістити їх куди завгодно, як ви робите в бібліотеці класів. Оскільки веб-програми містять файли, які не призначені для розгортання, такі як файли проектів та коду, у Visual Studio є команда Publish для виведення веб-сайту у вказане місце.

App_Code vs Bin

Розгортання файлів спільного коду, як правило, погана ідея, але це не означає, що вам потрібно вибрати веб-додаток. Ви можете мати веб-сайт, на якому посилається проект бібліотеки класів, який містить весь код веб-сайту. Веб-додатки - це просто зручний спосіб зробити це.

CodeBehind

Ця тема специфічна для файлів .aspx та .ascx. Ця тема набуває все більшої актуальності в нових програмах, таких як ASP.NET MVC та ASP.NET Веб-сторінки, які не використовують файли коду.

Маючи всі файли коду, зібрані в одну збірку, включаючи код позаду файлів .aspx сторінок і .ascx управління, в веб - додатках , ви повинні заново будувати для кожного невеликого зміни, і ви не можете зробити живі зміни. Це може бути справжнім болем під час розробки, оскільки вам доведеться продовжувати перебудову, щоб побачити зміни, тоді як у веб-сайтах зміни виконуються під час виконання, а сторінки / елементи керування автоматично перекомпілюються.

Домогтися керування кодом виконання за збірками - це менше роботи для вас, оскільки вам не потрібно турбуватися про те, щоб дати сторінкам / елементам управління унікальні імена або впорядкувати їх у різні простори імен.

Я не кажу, що розгортання файлів коду - це завжди хороша ідея (особливо це не стосується спільних файлів коду), але кодові файли повинні містити лише код, який виконує конкретні завдання інтерфейсу, обробники подій, що проводяться, і т. Д. Ваша програма повинна бути шаруватий, щоб важливий код завжди опинявся в папці Bin. Якщо це так, розгортання файлів, що знаходяться за кодом, не слід вважати шкідливим.

Ще одне обмеження веб-додатків полягає в тому, що ви можете використовувати лише мову проекту. На веб-сайтах ви можете мати кілька сторінок у C #, деякі у VB тощо. Не потрібно спеціальної підтримки Visual Studio. Така краса розширюваності постачальника побудови.

Крім того, у веб-додатках ви не отримуєте виявлення помилок на сторінках / елементах керування, оскільки компілятор компілює лише ваш код за класами, а не код розмітки (у MVC ви можете це виправити за допомогою параметра MvcBuildViews), який компілюється під час виконання.

Візуальна студія

Оскільки веб-програми - це проекти Visual Studio, ви отримуєте деякі функції, недоступні на веб-сайтах. Наприклад, ви можете використовувати події побудови для виконання різноманітних завдань, наприклад мінімізувати та / або комбінувати файли Javascript.

Ще одна приємна особливість, запроваджена у Visual Studio 2010, - це перетворення Web.config .Це також недоступно на веб-сайтах. Зараз працює з веб-сайтами в VS 2013.

Створення веб-програми швидше, ніж створення веб-сайту, спеціально для великих сайтів. Це головним чином через те, що веб-програми не компілюють код розмітки. Якщо в MVC встановити MvcBuildViews істинним, він компілює код розмітки, і ви отримаєте виявлення помилок, що дуже корисно. Суть полягає в тому, що кожного разу, коли ви створюєте рішення, він створює повний сайт, який може бути повільним і неефективним, особливо якщо ви не редагуєте сайт. Я вважаю, що я включаю та вимикаю MvcBuildViews (що вимагає завантаження проекту). З іншого боку, за допомогою веб-сайтів ви можете вибрати, хочете ви створити сайт як частину рішення чи ні. Якщо ви вирішите не робити, то розробка рішення буде дуже швидкою, і ви завжди можете натиснути на вузол веб-сайту та вибрати Створити, якщо внесли зміни.

У проекті веб-додатків MVC у вас є додаткові команди та діалоги для поширених завдань, як-от "Додати перегляд", "Перейти до перегляду", "Додати контролер" тощо. Вони недоступні на веб-сайті MVC.

Якщо ви використовуєте IIS Express як сервер розробки, у веб-сайти ви можете додавати віртуальні каталоги. Ця опція недоступна у веб-додатках.

NuGet Package Restore не працює на веб-сайтах, вам потрібно вручну встановити пакунки, перелічені на пакети.configВідновлення пакунків тепер працює з веб-сайтами, починаючи з NuGet 2.7


43
Оскільки програмісти пишуть додаток, додаток потім будується. Тестова група тестує додаток у тестовій системі. Потім замовник встановлює додатки. ОСТАННІ думаєте, що ви хочете, щоб хто-небудь робив живі зміни!
Ян Рінроуз,

12
Мені вибір найкращий, на веб-сайтах ви завжди можете успадкувати попередньо складений базовий клас, якщо хочете. Є багато мов / фреймворків (наприклад, PHP), де люди звикли до ідеї розгортання вихідного коду. Це не означає, що це не "серйозні" програми.
Макс Торо

6
"Насправді ви не керуєте цими DLL, [...] ви навіть не повинні знати, що вони існують. Не проблема." - Доки фреймворк не заплутається, не очистить старі версії правильно та не почне викидати компіляційні винятки із суперечливими іменами по всьому сайту ... Ви можете додати виявлення помилок розмітки за допомогою проекту WebDeployment. Я також не впевнений у вашій останній точці: "з веб-сайтами ви можете використовувати IIS як сервер", ви можете це зробити і з веб-додатком - і у мене є такі проекти, коли проект є частиною більшого веб-додатку.
Джаф - Бен Дюгід

3
Розгортання веб-сайту не завжди має бути активним сервером. У ідеальному світі ітерації в розробці повинні бути перевірені на дзеркалі живого середовища. У зв'язку з неможливістю веб-додатків вносити швидкі зміни коду на веб-сайт, що працює на сервері Development IIS (тобто не працює з локальним екземпляром VS), це відчуває великі болі для тестування швидких невеликих рішень. Це відбувається постійно в системах, де ви не можете повторити ті самі умови на локальній машині.
NikoRoberts

4
"Це може бути справжньою болем під час розвитку, оскільки вам доведеться продовжувати перебудову, щоб побачити зміни" ... майте на увазі, що це мав би бути МАСИВНИМ проектом або НАДАЛЬНО СТАРИМ комп'ютером. відбудова в ці дні.
Даррен

75

Веб-сайт = використовувати, коли веб-сайт створений графічними дизайнерами, а програмісти редагують лише одну або дві сторінки

Веб-додаток = використовувати, коли програму створюють програмісти, а графічні дизайнери редагують лише одне або два підказка / зображення.

Веб-сайти можна працювати з використанням будь-яких інструментів HTML, не маючи студії розробника, оскільки файли проектів не потрібно оновлювати і т. Д. Веб-додатки найкращі, коли команда в основному використовує студію розробників і вміст із високим кодом.

(Деякі помилки кодування знайдені у веб-додатках під час компіляції, які не знайдені у веб-сайтах до часу запуску.)

Попередження: цю відповідь я написав багато років тому і з тих пір не використовував Asp.net. Я очікую, що зараз справи просунулися.


40

Якщо у вас немає конкретної потреби в динамічно складеному проекті, не використовуйте проект веб-сайту .

Чому? Тому що проект веб-сайту підніме вас до стіни при спробі змінити чи зрозуміти ваш проект. Функції пошуку статичного набору тексту (наприклад, знайти звички, рефактор) у Visual Studio завжди візьмуться на будь-який проект розумного розміру. Для отримання додаткової інформації див. Питання про переповнення стека повільно "Знайти всі посилання" у Visual Studio .

Я дійсно не можу зрозуміти, чому вони відмовилися від веб-додатків у Visual Studio 2005 для типу проекту веб-сайту, що викликає біль, осуд, зменшення продуктивності.


30

У статті MSDN є стаття, в якій описані відмінності:

Порівняння проектів веб-сайтів та проектів веб-додатків

BTW: Є кілька подібних питань з цієї теми, наприклад:


Я здогадуюсь, відповідь про те, чи повинен я використовувати кодовий файл або codebehind у розмітці, піде з відповіддю, видаленим SO ...
frenchone

Тож для тих, хто цікавиться: веб-додаток = добре структуроване рішення = codebehind у розмітці VS веб-сайт = купа файлів = codefile у розмітці
frenchone

22

Це може здатися трохи очевидним, але я думаю, що це щось невірно зрозуміле, оскільки Visual Studio 2005 постачається з веб-сайтом спочатку. Якщо ваш проект стосується досить обмеженого веб-сайту, який не має логічного або фізичного розмежування, веб-сайт добре. Однак якщо це дійсно веб-додаток з різними модулями, куди багато користувачів додають та оновлюють дані, то вам краще погодитися з веб-додатком.

Найбільший фактор моделі веб-сайту полягає в тому, що все в app_codeрозділі динамічно збирається. Ви можете робити оновлення файлів C # без повного перерозподілу. Однак це приносить велику жертву. Дуже багато справ відбувається під прикриттями, які важко контролювати. Простори імен важко контролювати, а специфічне використання DLL виходить за вікном за замовчуванням для будь-чого, app_codeоскільки все динамічно збирається.

Модель веб-додатків не має динамічної компіляції, але ви отримуєте контроль над речами, про які я згадував.

Якщо ви займаєтесь розвитком n-ярусів, настійно рекомендую модель веб-додатків. Якщо ви працюєте з обмеженим веб-сайтом або швидкою та брудною реалізацією, модель веб-сайту може мати переваги.

Більш детальний аналіз можна знайти в:


3
> Найбільший фактор моделі веб-сайту полягає в тому, що все, що в розділі app_code, динамічно збирається. Це має і великий мінус. Мій веб-сайт розміщений з webhost4life, які дешеві, але багаті на функції. Недоліком є ​​те, що вони переробляють робочий процес дуже часто (15 хвилин?), А це означає, що наступний користувач має дуже повільну першу сторінку, коли додаток перекомпілюється.
Роб Ніколсон

19

З іспиту 70-515 книг для самостійного кроку MCTS:

За допомогою веб-програми (проекту),

  1. Ви можете створити програму MVC.
  2. Visual Studio зберігає список файлів у файлі проекту (.csproj або .vbproj), а не покладається на структуру папок.
  3. Ви не можете змішувати Visual Basic і C #.
  4. Ви не можете редагувати код, не зупиняючи сеанс налагодження.
  5. Ви можете встановити залежності між декількома веб-проектами.
  6. Ви повинні скласти програму перед розгортанням, що заважає вам протестувати сторінку, якщо інша сторінка не буде скомпільована.
  7. Не потрібно зберігати вихідний код на сервері.
  8. Ви можете керувати назвою та версією збірки.
  9. Ви не можете редагувати окремі файли після розгортання без перекомпіляції.

№4 неправильно. "Редагувати та продовжувати" можна ввімкнути, з деякими обмеженнями. Можливо, це було правдою в 2011 році. № 9 повинен сказати: "Ви не можете редагувати окремі файли вихідного коду без перекомпіляції". Ви можете редагувати .aspx, .js, .css тощо без перекомпіляції.
Джон Сондерс

№4 має інший кут. Якщо ви відкриєте веб-сайт за допомогою Файл> Відкрити> Веб-сайт і перейдіть до папки файлової системи для веб-сайту, замість того , щоб відкривати сайт шляхом вибору рішення у вікні запуску, ви можете редагувати модулі класу та код за ним (принаймні, на vb.net ) без зупинки налагодження. Зміни ви не побачите, поки не будете перебудовуватися, однак, часто корисно мати можливість переглядати поведінку сторінки під час зміни коду. Мінус полягає в тому, що ви втрачаєте все, що потрапляє у рішення: точки точки перерви, відкриті файли, закладки тощо. І вам доведеться іноді видаляти файли sln / sou.
мандрівник

16

Це залежить від того, що ти розвиваєш.

На веб-сайті, орієнтованому на вміст, буде постійно змінюватися вміст, а веб-сайт краще для цього.

У додатку, як правило, зберігаються його дані в базі даних, а його сторінки та код змінюються рідко. У цьому випадку краще мати веб-додаток, де розгортання збірок значно більш контрольоване і має кращу підтримку для тестування одиниць.


16

Compilation По-перше, є різниця у складанні. Веб-сайт заздалегідь не компілюється на сервері, він складається за файлом. Це може бути перевагою, оскільки коли ви хочете щось змінити на своєму веб-сайті, ви можете просто завантажити певний файл із сервера, змінити його і завантажити цей файл назад на сервер, і все буде добре. У веб-додатку ви не можете цього зробити, тому що все заздалегідь складено, і ви отримаєте лише один dll. Коли ви щось зміните в одному файлі свого проекту, вам доведеться знову скомпілювати все. Тож якщо ви хочете мати можливість змінити деякі файли на веб-сайті сервера, це краще рішення для вас. Це також дозволяє багатьом розробникам працювати на одному веб-сайті. З іншого боку, якщо ви не хочете, щоб ваш код був доступний на сервері, вам слід скористатися веб-програмою.

Project structure Існує також різниця в структурі проекту. У веб-додатку у вас є файл проекту так само, як у звичайному застосуванні. На веб-сайті немає традиційного файлу проекту, все, що ви маєте, це файл рішення. Всі посилання та налаштування зберігаються у файлі web.config. @Page directive У файлі, що містить клас, пов'язаний з цією сторінкою, в директиві @Page є інший атрибут. У веб-додатку це стандарт "CodeBehind", у веб-сайті ви використовуєте "CodeFile". Ви можете бачити це в прикладах нижче:

Веб-додаток:

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

Веб-сайт:

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

Простори імен - у наведеному вище прикладі ви також можете бачити ще одну різницю - як створюються простори імен. У просторі імен веб-додатків - це просто назва проекту. У веб-сайті є простір імен за замовчуванням ASP для динамічно складених сторінок.

Редагувати та продовжувати. У веб-додатку доступна опція "Редагувати та продовжувати" (щоб увімкнути її, потрібно перейти до меню "Інструменти", натисніть "Опції", а потім знайдіть "Редагувати та продовжувати" налагодження). Ця функція не працює у веб-сайті.ASP.NET MVC Якщо ви хочете розробляти веб-програми за допомогою

ASP.NET MVC (Model View Controller) найкращий і типовий варіант - веб-додаток. Хоча використовувати MVC на веб-сайті можливо, це не рекомендується.

Підсумок - Найважливішою відмінністю між веб-додатком ASP.NET та веб-сайтом є компіляція. Тож якщо ви працюєте над більшим проектом, де кілька людей можуть це змінити, краще скористатися веб-сайтом. Але якщо ви робите менший проект, ви можете використовувати і веб-додаток.


У великому проекті, де його змінюють більше однієї людини, ви використовуєте керування джерелами, тому це не привід використовувати веб-сайт "проекти".
Джон Сондерс

+1 для розрізнення коду за (webapp) та кодовим файлом (веб-сайтом) в директиві сторінки. Це точність, якої бракує обраної відповіді.
frenchone

11

Так, веб-додаток набагато краще, ніж веб-сайти, тому що веб-програми дають нам свободу:

  1. Мати кілька проектів під одним парасолькою та встановлювати залежність між проектами. Наприклад, для ПК, які ми можемо виконувати в рамках веб-додатків,

    • Веб-портали
    • Контролер сповіщень (для надсилання електронної пошти)
    • Бізнес шар
    • Рівень доступу до даних
    • Менеджер винятків
    • Серверна утиліта
    • Послуги WCF (спільно для всіх платформ)
    • Елемент списку
  2. Запускати одиничні тести на код, який знаходиться у файлах класу, пов'язаних зі сторінками ASP.NET

  3. Для позначення класів, які пов'язані зі сторінками та елементами керування користувачами в окремих автономних класах
  4. Створити єдину збірку для всього сайту
  5. Контроль за назвою збірки та номером версії, що створюється для сайту
  6. Щоб не ставити вихідний код на виробничий сервер. (Ви можете уникнути розгортання вихідного коду на сервері IIS. У деяких сценаріях, таких як середовище спільного хостингу, ви можете бути стурбовані несанкціонованим доступом до вихідного коду на сервері IIS. (Для проекту веб-сайту ви можете уникнути цього ризику, використовуючи попередня компіляція на комп'ютері розробки та розгортання створених збірок замість вихідного коду. Однак у цьому випадку ви втрачаєте деякі переваги простого оновлення сайту.)
  7. Випуск продуктивності веб-сайту (Перший запит на веб-сайт може вимагати складання сайту, що може призвести до затримки. А якщо веб-сайт працює на сервері IIS, у якого не вистачає пам'яті, включаючи весь сайт у одна збірка може використовувати більше пам'яті, ніж потрібно для декількох збірок.)

11

Однією з ключових відмінностей є те, що Веб-сайти динамічно компілюються та створюють поточні збірки. Веб-додатки складаються в одну велику збірку.

Відмінність між ними було усунуто у Visual Studio 2008.


4
"Відмінність між двома зроблено в порівнянні з vs2008" - не впевнений, що ви тут маєте на увазі - вони все ще є різними типами проектів у VS2008, поводяться по-різному і створюються через різні параметри меню - однак принаймні вони обидва доступні за замовчуванням у VS2008.
Джаф - Бен Дюгід

9

Програми зазвичай складаються перед розгортанням, коли веб-сайт використовує каталог app_code. Коли щось зміниться в папці коду програми, сервер повторно компілює код. Це означає, що ви можете додавати / змінювати код за допомогою веб-сайту на ходу.

Перевага програми полягає в тому, що повторного збирання не відбувається, тому початкові часи запуску будуть швидшими.


Це частково правда, ви можете попередньо скласти сторінки на веб-сайті, якщо хочете
Amr H. Abd Elmajeed

8

Я рекомендую вам переглянути відео Проекти веб-додатків та проекти веб-розгортання на веб-сайті ASP.NET, де дуже детально пояснюється різниця, мені це було дуже корисно.

До речі, не плутайте заголовок, значна частина відео пояснює різницю між проектами веб-сайтів та проектами веб-додатків і чому Microsoft знову представила проекти веб-додатків у Visual studio 2005 (як ви, напевно, вже знаєте, це спочатку постачався тільки з веб-сайтів, потім проекти із веб-додатками були додані в SP1). Чудове відео, яке я дуже рекомендую всім, хто хоче знати різницю.


Зараз це відео за посиланням: asp.net/web-forms/videos/vs-2005/…
Боб Рейнольдс

7

"Веб-сайт" має свій код у спеціальній каталозі App_Code, і він збирається в декілька DLL (збірок) під час виконання. "Веб-додаток" попередньо компілюється в одну DLL.


5

Веб-сайт та проект >> - це два різних способи створення програми ASP.NET за допомогою візуальної студії. Одне безпроектне, а інше - проектне середовище. Відмінності такі

  1. Файл рішення зберігається в тому ж каталозі, що і кореневий каталог у проектному середовищі.
  2. Потрібно видалити файли рішення та проекту перед тим, як розгорнути в середовищі проекту.
  3. Повний кореневий каталог розгорнуто в безпроектному середовищі.

немає жодної основної різниці у використанні будь-якого підходу. Але якщо ви створюєте веб-сайт, який займе більше часу, вибирайте проектне середовище.


1
Файл рішення не повинен знаходитися в одній папці. Також стандартний механізм публікації видаляє будь-які артефакти, яких не повинно бути на цільовому сайті, наприклад, файли, що знаходяться за кодом, не розгортаються.
Джон Сондерс

5

Модель проекту веб-додатків

  • Надає ту саму семантику веб-проектів, що і веб-проекти Visual Studio .NET. Має файл проекту (структура на основі файлів проекту). Модель складання - весь код у проекті зібраний в одну збірку. Підтримується як IIS, так і вбудований сервер розробки ASP.NET. Підтримує всі можливості Visual Studio 2005 (рефакторинг, генеричні дані тощо) та ASP.NET (головні сторінки, членство та вхід, навігація по сайту, теми тощо). Використання розширень для FrontPage Server (FPSE) більше не є необхідною.

Модель проекту веб-сайту

  • Немає файлу проекту (на основі файлової системи).
  • Нова модель компіляції.
  • Динамічна компіляція та робота над сторінками без створення всього сайту на кожному перегляді сторінки.
  • Підтримується як IIS, так і вбудований сервер розробки ASP.NET.
  • Кожна сторінка має власну збірку.
  • Інша модель коду.

5

Це завжди залежить від вимог вашого клієнта. ASP.NET включає в себе гнучкі функції, необхідні користувачеві для безпеки та легкого обслуговування вашого додатка.

Ви можете розглядати веб-додаток як двійковий файл, який працює в рамках ASP.NET. І веб-сайти як статична веб-сторінка, на яку можна переглянути та легко розгорнути вихідний код.

Але перевага та недоліки цих двох технологій ASP.NET полягають у тому, що добре.


4

Веб-сайти - файл рішення не буде створений. Якщо ми хочемо створити веб-сайти, немає необхідності у візуальній студії.

Веб-додаток - буде створено файл рішення. Якщо ми хочемо створити веб-додаток, то потрібна візуальна студія. Це створить єдиний .dllфайл у папці bin.


2
-1 У вас фактично є файл рішення, якщо ви створюєте проект веб-сайту через візуальну студію. У вас немає файлу проекту.
Даррен

+1, звичайно, ви можете створити файл рішення, але цей файл здебільшого порожній, тому це просто роздратування (VS запитує, де зберегти файл на виході), а не щось корисне
frenchone

3

У проектах веб-додатків Visual Studio потребує додаткових файлів .designer для сторінок та елементів керування користувачами. Проекти веб-сайтів не вимагають цього накладних витрат. Сама розмітка трактується як конструкція.


3

Веб-сайт: Він автоматично генерує папку app_code, і якщо ви опублікуєте її на сервері, а потім, якщо ви внесете якісь зміни в будь-який конкретний файл чи сторінку, ніж вам не доведеться компілювати всі файли.

Веб-додаток Він автоматично генерує файл рішень, який веб-сайт не генерує, і якщо ви змінюєте один файл, вам потрібно скласти повний проект, щоб відобразити його зміни.


"Складання повного проекту" не означає компілювати кожен файл у проекті. Файли вихідного коду, які не змінилися, не будуть перекомпільовані.
Джон Сондерс

3

У веб-додатку ви можете створювати шари функціональності вашого проекту та створювати взаємозалежності між ними, поділяючи їх на багато проектів, але цього ви ніколи не можете робити на веб-сайті.


3

Безумовно веб-додаток, один файл DLL та простий у обслуговуванні. Але веб-сайт є більш гнучким; ви можете редагувати файл aspx на ходу.


Ви також можете редагувати файл aspx у проекті веб-додатків.
Джон Сондерс

3

Веб-додаткам потрібно більше пам’яті, імовірно, тому що у вас немає іншого вибору, як зібратись в одну збірку. Щойно я перетворив великий застарілий веб-сайт у веб-додаток і виникли проблеми із втратою пам’яті, обидва під час компіляції із повідомленням про помилку, як показано нижче:

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()

Моя рекомендація щодо перетворення більших сайтів на обмежене пам'ять застаріле обладнання - вибрати варіант повернення до моделі веб-сайту. Навіть після початкового успіху проблема може повзати пізніше.


Це не є винятком часу компіляції.
Джон Сондерс

1

Тут Веб-підтримка є прикладом веб-сайту.

Тут Веб-підтримка є прикладом веб-сайту. Веб-сайт та веб-додаток можуть бути динамічними / статичними, це залежить від вимог, ось приклад для розуміння роботи веб-сайту та веб-додатків.


Це не стосується asp.net. Відмінність веб-сайтів / веб-додатків (в термінології asp.net) - це більше про те, як файли організовані (як добре організоване рішення або як купа файлів) та компілюються ("JIT" vs static). В обох випадках "програма" є переважно серверною.
frenchone

0

Щоб узагальнити деякі відповіді вище:

Гнучкість , чи можете ви змінити веб-сторінку в реальному часі?

Веб-сайт : Можливо. Про: короткострокові вигоди. Кон: довгостроковий ризик хаосу проекту.

Веб-додаток : Con: неможливо. Відредагуйте сторінку, архівуйте зміни в контролі джерела, а потім складіть і розгорніть весь сайт. Про: підтримуйте якісний проект.

Питання розвитку

Веб-сайт : Проста структура проекту без файлу .csproj.Дві сторінки .aspx можуть мати однакове ім’я класу без конфліктів. Випадкова назва каталогів проекту, що призводить до побудови помилок, наприклад, чому .net Framework конфліктує із власним генерованим файлом та чому .net Framework конфліктує із власним генерованим файлом . Pro: Простий (спрощений). Кон: хаотично.

Веб-додаток : структура проекту, схожа на проект WebForms, з файлом .csproj. Назви класів сторінок asp повинні бути унікальними. Про: Простий (розумний). Кон: ні, тому що веб-додаток все ще простий.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.