Site Web ASP.NET ou application Web ASP.NET?


848

Lorsque je démarre un nouveau projet ASP.NET dans Visual Studio, je peux créer une application Web ASP.NET ou créer un site Web ASP.NET.

Quelle est la différence entre l'application Web ASP.NET et le site Web ASP.NET? Pourquoi en choisirais-je un plutôt qu'un autre?

La réponse est-elle différente selon la version de Visual Studio que j'utilise?


6
Une comparaison complète et plus récente (pour 4.5) et une explication se trouvent ici sur MSDN: Projets d'application Web par opposition à Projets de site Web dans Visual Studio
Gustav

Réponses:


556

Site Internet:

Le projet de site Web est compilé à la volée. Vous vous retrouvez avec beaucoup plus de fichiers DLL, ce qui peut être pénible. Cela pose également des problèmes lorsque vous avez des pages ou des contrôles dans un répertoire qui doivent référencer des pages et des contrôles dans un autre répertoire car l'autre répertoire peut ne pas encore être compilé dans le code. Un autre problème peut être lié à la publication.

Si Visual Studio n'est pas invité à réutiliser les mêmes noms en permanence, il trouvera constamment de nouveaux noms pour les fichiers DLL générés par les pages. Cela peut conduire à avoir plusieurs copies proches de fichiers DLL contenant le même nom de classe, ce qui générera de nombreuses erreurs. Le projet de site Web a été introduit avec Visual Studio 2005, mais il s'est avéré ne pas être populaire.

Application Web:

Le projet d' application Web a été créé en tant que complément et existe désormais dans le cadre du SP 1 pour Visual Studio 2005. Les principales différences sont que le projet d'application Web a été conçu pour fonctionner de manière similaire aux projets Web fournis avec Visual Studio 2003. Il compiler l'application dans un seul fichier DLL au moment de la génération. Pour mettre à jour le projet, il doit être recompilé et le fichier DLL publié pour que les modifications se produisent.

Une autre fonctionnalité intéressante du projet d'application Web est qu'il est beaucoup plus facile d'exclure des fichiers de la vue du projet. Dans le projet de site Web, chaque fichier que vous excluez est renommé avec un mot clé exclu dans le nom de fichier. Dans le projet d'application Web, le projet garde simplement la trace des fichiers à inclure / exclure de la vue du projet sans les renommer, ce qui rend les choses beaucoup plus ordonnées.

Référence

L'article ASP.NET 2.0 - Site Web vs projet d'application Web donne également des raisons pour lesquelles utiliser l'un et pas l'autre. En voici un extrait:

  • Vous devez migrer de grandes applications Visual Studio .NET 2003 vers VS 2005? utilisez le projet d'application Web.
  • Vous souhaitez ouvrir et modifier n'importe quel répertoire en tant que projet Web sans créer de fichier de projet? utiliser le projet de site Web.
  • Vous devez ajouter des étapes de pré-construction et de post-construction pendant la compilation? utiliser le projet d'application Web.
  • Vous devez créer une application Web à l'aide de plusieurs projets Web? utiliser le projet d'application Web.
  • Vous souhaitez générer un assembly pour chaque page? utiliser le projet de site Web.
  • Vous préférez la compilation dynamique et le travail sur les pages sans construire l'intégralité du site sur chaque page vue? utiliser le projet de site Web.
  • Vous préférez le modèle de code à page unique au modèle à code derrière? utiliser le projet de site Web.

Projets d'application Web et projets de site Web (MSDN) explique les différences entre le site Web et les projets d'application Web. Il explique également la configuration à effectuer dans Visual Studio.


5
Vous pouvez toujours compiler l'intégralité de votre site en une DLL avec le site Web basé sur des fichiers.
dtc

31
La façon dont j'ai tendance à y penser. Si vous programmez une application qui utilise HTML comme interface utilisateur, utilisez l'application Web. Si vous avez un site Web qui a besoin d'un peu d'Asp.net sur quelques-unes de ses pages, utilisez Web Site Project.
Ian Ringrose

35
En fait, les projets d'application Web étaient précisément le type de projet ASP.NET d'origine. Ils ne sont pas "similaires" aux projets que nous avions dans Visual Studio 2003. Ils n'ont pas été créés en tant que complément. Visual Studio 2005 SP1 a simplement restauré ce que Visual Studio 2005 RTM a supprimé par erreur.
John Saunders

1
Vous pouvez utiliser la sortie WebApplication dans un projet WebDeployment. Vous ne pouvez pas utiliser la sortie WebSite dans un projet WebDeployment. Si vous souhaitez créer un projet de déploiement, restez sur WebApplication. Mais pour le développement, WebSite est plus pratique. Cependant, la conversion n'est pas toujours sans problème, alors commencez immédiatement avec WebApplication.
Stefan Steiger

8
@xarzu: les "projets" du site Web n'ont pas de fichier .csproj ou .vbproj. Ce ne sont pas vraiment des projets - ce ne sont que des dossiers remplis de fichiers.
John Saunders

171

Le site Web est ce que vous déployez sur un serveur Web ASP.NET tel que IIS. Juste un tas de fichiers et de dossiers. Il n'y a rien dans un site Web qui vous relie à Visual Studio (il n'y a pas de fichier de projet). La génération de code et la compilation de pages Web (telles que .aspx, .ascx, .master) sont effectuées dynamiquement au moment de l'exécution , et les modifications apportées à ces fichiers sont détectées par le framework et recompilées automatiquement. Vous pouvez placer le code que vous souhaitez partager entre les pages dans le dossier spécial App_Code, ou vous pouvez le précompiler et placer l'assembly dans le dossier Bin.

L'application Web est un projet Visual Studio spécial. La principale différence avec les sites Web est que lorsque vous générez le projet, tous les fichiers de code sont compilés en un seul assembly, qui est placé dans le répertoire bin. Vous ne déployez pas de fichiers de code sur le serveur Web. Au lieu d'avoir un dossier spécial pour les fichiers de code partagés, vous pouvez les placer n'importe où, comme vous le feriez dans la bibliothèque de classes. Étant donné que les applications Web contiennent des fichiers qui ne sont pas destinés à être déployés, tels que des fichiers de projet et de code, il existe une commande Publier dans Visual Studio pour générer un site Web vers un emplacement spécifié.

App_Code vs Bin

Le déploiement de fichiers de code partagés est généralement une mauvaise idée, mais cela ne signifie pas que vous devez choisir une application Web. Vous pouvez avoir un site Web qui référence un projet de bibliothèque de classes qui contient tout le code du site Web. Les applications Web ne sont qu'un moyen pratique de le faire.

CodeBehind

Cette rubrique est spécifique aux fichiers .aspx et .ascx. Cette rubrique est de moins en moins pertinente dans les nouveaux cadres d'application tels que ASP.NET MVC et les pages Web ASP.NET qui n'utilisent pas de fichiers codebehind.

En ayant tous les fichiers de code compilés en un seul assembly, y compris les fichiers codebehind des pages .aspx et des contrôles .ascx, dans les applications Web, vous devez reconstruire pour chaque petite modification, et vous ne pouvez pas apporter de modifications en direct. Cela peut être très difficile pendant le développement, car vous devez continuer à reconstruire pour voir les modifications, tandis qu'avec les sites Web, les modifications sont détectées par le moteur d'exécution et les pages / contrôles sont automatiquement recompilés.

Avoir le runtime à gérer les assemblys codebehind est moins de travail pour vous, car vous n'avez pas à vous soucier de donner aux pages / contrôles des noms uniques, ou de les organiser en différents espaces de noms.

Je ne dis pas que le déploiement de fichiers de code est toujours une bonne idée (surtout pas dans le cas de fichiers de code partagés), mais les fichiers codebehind ne doivent contenir que du code qui effectue des tâches spécifiques à l'interface utilisateur, des gestionnaires d'événements câblés, etc. Votre application doit être en couches afin que le code important finisse toujours dans le dossier Bin. Si tel est le cas, le déploiement de fichiers codebehind ne doit pas être considéré comme dangereux.

Une autre limitation des applications Web est que vous ne pouvez utiliser que la langue du projet. Dans les sites Web, vous pouvez avoir certaines pages en C #, certaines en VB, etc. Pas besoin de prise en charge spéciale de Visual Studio. C'est la beauté de l'extensibilité du fournisseur de build.

De plus, dans les applications Web, vous n'obtenez pas de détection d'erreur dans les pages / contrôles car le compilateur compile uniquement vos classes codebehind et non le code de balisage (dans MVC, vous pouvez résoudre ce problème en utilisant l'option MvcBuildViews), qui est compilé au moment de l'exécution.

Visual Studio

Étant donné que les applications Web sont des projets Visual Studio, certaines fonctionnalités ne sont pas disponibles dans les sites Web. Par exemple, vous pouvez utiliser des événements de génération pour effectuer une variété de tâches, par exemple réduire et / ou combiner des fichiers Javascript.

Une autre fonctionnalité intéressante introduite dans Visual Studio 2010 est la transformation Web.config .Ce n'est pas non plus disponible sur les sites Web. Fonctionne désormais avec les sites Web dans VS 2013.

La création d'une application Web est plus rapide que la création d'un site Web, spécialement pour les grands sites. Cela est principalement dû au fait que les applications Web ne compilent pas le code de balisage. Dans MVC, si vous définissez MvcBuildViews sur true, il compile le code de balisage et vous obtenez une détection d'erreur, ce qui est très utile. L'inconvénient est que chaque fois que vous créez la solution, il crée le site complet, ce qui peut être lent et inefficace, surtout si vous ne modifiez pas le site. Je me retrouve à activer et désactiver MvcBuildViews (ce qui nécessite un déchargement de projet). D'autre part, avec les sites Web, vous pouvez choisir si vous souhaitez créer le site dans le cadre de la solution ou non. Si vous choisissez de ne pas le faire, la création de la solution est très rapide et vous pouvez toujours cliquer sur le nœud Site Web et sélectionner Générer, si vous avez apporté des modifications.

Dans un projet d'application Web MVC, vous disposez de commandes et de boîtes de dialogue supplémentaires pour les tâches courantes, telles que «Ajouter une vue», «Aller à la vue», «Ajouter un contrôleur», etc. Elles ne sont pas disponibles sur un site Web MVC.

Si vous utilisez IIS Express comme serveur de développement, dans les sites Web, vous pouvez ajouter des répertoires virtuels. Cette option n'est pas disponible dans les applications Web.

La restauration de package NuGet ne fonctionne pas sur les sites Web, vous devez installer manuellement les packages répertoriés sur packages.configLa restauration de packages fonctionne désormais avec les sites Web à partir de NuGet 2.7


43
Étant donné que les programmeurs écrivent l'application, l'application est ensuite générée. L'équipe de test teste l'application sur le système de test. Ensuite, le client installe les applications. Ce DERNIER pense que vous voulez, c'est quelqu'un qui fait des changements en direct!
Ian Ringrose

12
Pour moi, le choix est le meilleur, sur les sites Web, vous pouvez toujours hériter d'une classe de base précompilée si vous le souhaitez. Il existe de nombreux langages / frameworks (par exemple PHP) où les gens sont habitués à l'idée de déployer du code source. Cela ne signifie pas que ce ne sont pas des applications «sérieuses».
Max Toro

6
"En fait, vous ne gérez pas ces DLL, [...] vous n'avez même pas besoin de savoir qu'elles existent. Ce n'est pas un problème." - Jusqu'à ce que le framework soit confus, ne nettoie pas correctement les anciennes versions et commence à lancer des exceptions de compilation avec des noms en conflit sur tout le site ... Vous pouvez ajouter une détection d'erreur du balisage via l'utilisation d'un projet WebDeployment. Je ne suis pas sûr non plus de votre dernier point "avec les sites Web, vous pouvez utiliser IIS comme serveur", vous pouvez également le faire avec une application Web - et j'ai des projets comme celui-ci où le projet fait partie d'une application Web plus grande.
Zhaph - Ben Duguid

3
Le déploiement d'un site Web ne doit pas toujours se faire sur un serveur en direct. Les itérations de développement devraient, dans un monde parfait, être testées sur un miroir de l'environnement vivant. L'incapacité de Web Apps à apporter des modifications de code rapides à un site s'exécutant sur un serveur Development IIS (c'est-à-dire ne s'exécutant pas à l'aide de l'instance VS locale) complique le test de petites solutions rapides. Cela se produit tout le temps dans les systèmes où vous ne pouvez pas reproduire les mêmes conditions sur votre machine locale.
NikoRoberts

4
"Cela peut être une vraie douleur pendant le développement, car vous devez continuer à reconstruire pour voir les changements" ... gardez à l'esprit que cela devrait être un projet MASSIVE ou un ordinateur VRAIMENT VIEUX pour que ce soit pénible à faire une reconstruction de nos jours.
Darren

75

Site Web = à utiliser lorsque le site Web est créé par des graphistes et que les programmeurs ne modifient qu'une ou deux pages

Application Web = à utiliser lorsque l'application est créée par des programmeurs et que les graphistes ne modifient qu'une ou deux images / pages paginées.

Les sites Web peuvent être utilisés à l'aide de n'importe quel outil HTML sans avoir à avoir Developer Studio, car les fichiers de projet n'ont pas besoin d'être mis à jour, etc. Les applications Web sont optimales lorsque l'équipe utilise principalement Developer Studio et que le contenu en code est élevé.

(Certaines erreurs de codage se trouvent dans les applications Web au moment de la compilation et ne sont trouvées dans les sites Web qu'au moment de l'exécution.)

Attention: j'ai écrit cette réponse il y a plusieurs années et je n'ai plus utilisé Asp.net depuis. J'espère que les choses ont évolué.


40

Sauf si vous avez un besoin spécifique pour un projet compilé dynamiquement, n'utilisez pas de projet de site Web .

Pourquoi? Parce que le projet de site Web vous fera monter dans le mur lorsque vous essayez de changer ou de comprendre votre projet. Les fonctionnalités de recherche de frappe statique (par exemple, trouver des utilisations, refactoriser) dans Visual Studio prendront une éternité sur tout projet de taille raisonnable. Pour plus d'informations, consultez la question Stack Overflow Slow «Rechercher toutes les références» dans Visual Studio .

Je ne vois vraiment pas pourquoi ils ont abandonné les applications Web dans Visual Studio 2005 pour le type de projet de site Web Carbuncle induisant la douleur, drainant la santé mentale et la productivité.


30

Il existe un article dans MSDN qui décrit les différences:

Comparaison de projets de sites Web et de projets d'applications Web

BTW: il y a des questions similaires à ce sujet, par exemple:


Je suppose que la réponse à propos de l'utilisation du fichier de code ou du codebehind dans le balisage a disparu avec la réponse qui a été supprimée par SO ...
frenchone

Donc pour ceux qui se demandent: application web = solution bien structurée = codebehind dans le balisage VS site web = tas de fichiers = codefile dans le balisage
frenchone

22

Cela peut sembler un peu évident, mais je pense que c'est quelque chose qui est mal compris car Visual Studio 2005 n'a été livré qu'avec le site Web à l'origine. Si votre projet concerne un site Web qui est assez limité et n'a pas beaucoup de séparation logique ou physique, le site Web est très bien. Cependant, s'il s'agit vraiment d'une application Web avec différents modules où de nombreux utilisateurs ajoutent et mettent à jour des données, il vaut mieux utiliser l'application Web.

Le plus grand avantage du modèle de site Web est que tout dans la app_codesection est compilé dynamiquement. Vous pouvez effectuer des mises à jour de fichiers C # sans redéploiement complet. Cependant, cela vient à un grand sacrifice. Beaucoup de choses se passent sous des couvertures difficiles à contrôler. Les espaces de noms sont difficiles à contrôler et l'utilisation spécifique de DLL disparaît par défaut pour tout ce qui se trouve sousapp_code ce qui se trouve puisque tout est compilé dynamiquement.

Le modèle d'application Web n'a pas de compilation dynamique, mais vous contrôlez les choses que j'ai mentionnées.

Si vous faites du développement à n niveaux, je recommande fortement le modèle d'application Web. Si vous faites un site Web limité ou une mise en œuvre rapide et sale, le modèle de site Web peut avoir des avantages.

Une analyse plus détaillée peut être trouvée dans:


3
> Le plus gros avantage du modèle de site Web est que tout ce qui se trouve dans la section app_code est compilé dynamiquement. Cela a aussi un gros inconvénient. Mon site Web est hébergé avec webhost4life qui sont bon marché mais riches en fonctionnalités. L'inconvénient est qu'ils recyclent le processus de travail très fréquemment (15 minutes?), Ce qui signifie que l'utilisateur suivant a une sortie de première page très lente lorsque l'application est recompilée.
Rob Nicholson

19

À partir du livre de l'examen 70-515 de la trousse de formation personnelle des SCTM:

Avec application web (projet),

  1. Vous pouvez créer une application MVC.
  2. Visual Studio stocke la liste des fichiers dans un fichier de projet (.csproj ou .vbproj), plutôt que de s'appuyer sur la structure de dossiers.
  3. Vous ne pouvez pas mélanger Visual Basic et C #.
  4. Vous ne pouvez pas modifier le code sans arrêter une session de débogage.
  5. Vous pouvez établir des dépendances entre plusieurs projets Web.
  6. Vous devez compiler l'application avant le déploiement, ce qui vous empêche de tester une page si une autre page ne se compile pas.
  7. Vous n'avez pas besoin de stocker le code source sur le serveur.
  8. Vous pouvez contrôler le nom et la version de l'assembly.
  9. Vous ne pouvez pas modifier des fichiers individuels après le déploiement sans recompiler.

# 4 est faux. "Modifier et continuer" peut être activé, avec certaines restrictions. Peut-être que c'était vrai en 2011. # 9 devrait dire "vous ne pouvez pas éditer des fichiers de code source individuels sans recompiler". Vous pouvez éditer .aspx, .js, .css, etc. sans recompiler.
John Saunders

# 4 a un autre angle. Si vous ouvrez un site Web à l'aide de Fichier> Ouvrir> Site Web et accédez au dossier du système de fichiers pour le site Web, au lieu d' ouvrir le site en sélectionnant la solution dans la fenêtre de démarrage, vous pouvez modifier les modules de classe et codebehind (au moins dans vb.net ) sans arrêter le débogage. Vous ne verrez pas les modifications tant que vous n'aurez pas reconstruit, cependant, il est souvent utile de pouvoir surveiller le comportement des pages pendant que vous modifiez le code. L'inconvénient est que vous perdez tout ce qui entre dans la solution: points d'arrêt, fichiers ouverts, signets, etc. Et vous devez parfois supprimer les fichiers sln / sou.
wayfarer

16

Cela dépend de ce que vous développez.

Un site Web axé sur le contenu verra son contenu changer fréquemment et un site Web est préférable pour cela.

Une application a tendance à avoir ses données stockées dans une base de données et ses pages et son code changent rarement. Dans ce cas, il est préférable d'avoir une application Web où le déploiement des assemblys est beaucoup plus contrôlé et prend mieux en charge les tests unitaires.


16

Compilation Premièrement, il y a une différence de compilation. Le site Web n'est pas précompilé sur le serveur, il est compilé sur fichier. Cela peut être un avantage, car lorsque vous souhaitez modifier quelque chose dans votre site Web, vous pouvez simplement télécharger un fichier spécifique à partir du serveur, le modifier et télécharger à nouveau ce fichier sur le serveur et tout fonctionnera correctement. Dans l'application Web, vous ne pouvez pas faire cela car tout est précompilé et vous vous retrouvez avec une seule DLL. Lorsque vous modifiez quelque chose dans un fichier de votre projet, vous devez tout recompiler à nouveau. Donc, si vous souhaitez avoir la possibilité de modifier certains fichiers sur le site Web du serveur, c'est une meilleure solution pour vous. Il permet également à de nombreux développeurs de travailler sur un seul site Web. D'un autre côté, si vous ne voulez pas que votre code soit disponible sur le serveur, vous devriez plutôt choisir Application Web.

Project structure Il existe également une différence dans la structure du projet. Dans l'application Web, vous avez un fichier de projet comme vous l'aviez dans une application normale. Dans le site Web, il n'y a pas de fichier de projet traditionnel, tout ce que vous avez est un fichier de solution. Toutes les références et paramètres sont stockés dans le fichier web.config. @Page directive Il existe un attribut différent dans la directive @Page pour le fichier qui contient la classe associée à cette page. Dans l'application Web, il est standard "CodeBehind", dans le site Web, vous utilisez "CodeFile". Vous pouvez le voir dans les exemples ci-dessous:

Application Web:

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

Site Internet:

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

Espaces de noms - Dans l'exemple ci-dessus, vous pouvez également voir une autre différence - comment les espaces de noms sont créés. Dans l'espace de noms d'application Web, il s'agit simplement du nom du projet. Dans le site Web, il existe un espace de noms ASP par défaut pour les pages compilées dynamiquement.

Modifier et continuer - Dans l'application Web, l'option Modifier et continuer est disponible (pour l'activer, vous devez aller dans le menu Outils, cliquer sur Options, puis trouver Modifier et continuer dans le débogage). Cette fonctionnalité ne fonctionne pas dans Web Site.ASP.NET MVCI si vous souhaitez développer des applications Web à l'aide

ASP.NET MVC (Model View Controller), la meilleure option par défaut est Application Web. Bien qu'il soit possible d'utiliser MVC dans le site Web, ce n'est pas recommandé.

Résumé - La différence la plus importante entre l'application Web ASP.NET et le site Web est la compilation. Donc, si vous travaillez sur un projet plus important où quelques personnes peuvent le modifier, il est préférable d'utiliser le site Web. Mais si vous faites un petit projet, vous pouvez également utiliser une application Web.


Sur un grand projet où plus d'une personne le modifie, vous utilisez le contrôle de code source, ce n'est donc pas une raison pour utiliser des "projets" de site Web.
John Saunders

+1 pour la distinction dans codebehind (webapp) vs codefile (website) dans la directive page. C'est une précision qui fait défaut dans la réponse choisie.
frenchone

11

Oui, l'application Web est bien meilleure que les sites Web, car les applications Web nous donnent la liberté:

  1. Pour avoir plusieurs projets sous un même parapluie et établir des dépendances entre les projets. Par exemple, pour PCS, nous pouvons avoir à la suite dans l'application Web-

    • Portails Web
    • Contrôleur de notification (pour l'envoi d'e-mails)
    • Couche métier
    • Couche d'accès aux données
    • Gestionnaire d'exceptions
    • Utilitaire de serveur
    • Services WCF (communs à toutes les plateformes)
    • Élément de liste
  2. Pour exécuter des tests unitaires sur le code qui se trouve dans les fichiers de classe associés aux pages ASP.NET

  3. Pour faire référence aux classes qui sont associées aux pages et aux contrôles utilisateur des classes autonomes
  4. Pour créer un assemblage unique pour l'ensemble du site
  5. Contrôle du nom de l'assembly et du numéro de version généré pour le site
  6. Pour éviter de placer du code source sur un serveur de production. (Vous pouvez éviter de déployer le code source sur le serveur IIS. Dans certains scénarios, tels que les environnements d'hébergement partagés, vous pourriez être préoccupé par l'accès non autorisé au code source sur le serveur IIS. (Pour un projet de site Web, vous pouvez éviter ce risque en: précompilation sur un ordinateur de développement et déploiement des assemblys générés au lieu du code source. Cependant, dans ce cas, vous perdez certains des avantages des mises à jour faciles du site.)
  7. Problème de performances avec le site Web (la première demande adressée au site Web peut nécessiter la compilation du site, ce qui peut entraîner un retard. Et si le site Web s'exécute sur un serveur IIS qui manque de mémoire, y compris le site entier dans un un seul assemblage peut utiliser plus de mémoire que ce qui serait nécessaire pour plusieurs assemblages.)

11

L'une des principales différences est que les sites Web compilent dynamiquement et créent des assemblages à la volée. Les applications Web se compilent en un seul grand assemblage.

La distinction entre les deux a été supprimée dans Visual Studio 2008.


4
"La distinction entre les 2 a été supprimée dans vs2008" - je ne sais pas trop ce que vous voulez dire - ils sont toujours des types de projets distincts dans VS2008, se comportent différemment et sont créés via différentes options de menu - mais au moins ils sont tous les deux disponibles par défaut dans VS2008.
Zhaph - Ben Duguid

9

Les applications sont généralement compilées avant le déploiement lorsque le site Web utilise le répertoire app_code. Lorsque quelque chose change dans le dossier de code de l'application, le serveur recompilera le code. Cela signifie que vous pouvez ajouter / modifier du code avec un site Web à la volée.

L'avantage d'une application est qu'il n'y a pas de recompilation et donc les temps de démarrage initiaux seront plus rapides.


C'est partiellement vrai, vous pouvez précompiler des pages du site Web si vous le souhaitez
Amr H. Abd Elmajeed

8

Je vous recommande de regarder la vidéo Projets d'application Web et projets de déploiement Web sur le site Web ASP.NET qui explique la différence en détail, cela m'a été très utile.

Soit dit en passant, ne vous laissez pas confondre par le titre, une grande partie de la vidéo explique la différence entre les projets de site Web et les projets d'application Web et pourquoi Microsoft a réintroduit des projets d'application Web dans Visual Studio 2005 (comme vous le savez probablement déjà, il initialement fourni avec uniquement des projets de site Web, puis des projets d'application Web ont été ajoutés dans SP1). Une excellente vidéo que je recommande vivement à tous ceux qui veulent faire la différence.


La vidéo est maintenant sur: asp.net/web-forms/videos/vs-2005/…
Bob Reynolds

7

Un "site Web" a son code dans un répertoire App_Code spécial et il est compilé en plusieurs DLL (assemblys) au moment de l'exécution. Une «application Web» est précompilée en une seule DLL.


5

Site Web et projet >> site Web sont deux méthodes différentes pour créer une application ASP.NET à l'aide de Visual Studio. L'un est sans projet et un autre est l'environnement du projet. Les différences sont aussi

  1. Le fichier de solution est stocké dans le même répertoire que le répertoire racine dans l'environnement du projet.
  2. Vous devez supprimer les fichiers de solution et de projet avant de les déployer dans l'environnement de projet.
  3. Le répertoire racine complet est déployé dans un environnement sans projet.

il n'y a pas beaucoup de différence fondamentale dans l'utilisation de l'une ou l'autre approche. Mais si vous créez un site Web qui prendra plus de temps, optez pour l'environnement du projet.


1
Le fichier de solution n'a pas besoin d'être dans le même dossier. De plus, le mécanisme de publication standard supprime tous les artefacts qui ne devraient pas se trouver sur le site cible, par exemple, les fichiers codebehind ne sont pas déployés.
John Saunders

5

Modèle de projet d'application Web

  • Fournit la même sémantique de projet Web que les projets Web Visual Studio .NET. A un fichier de projet (structure basée sur des fichiers de projet). Générer un modèle - tout le code du projet est compilé en un seul assembly. Prend en charge IIS et le serveur de développement ASP.NET intégré. Prend en charge toutes les fonctionnalités de Visual Studio 2005 (refactoring, génériques, etc.) et d'ASP.NET (pages maîtres, adhésion et connexion, navigation sur le site, thèmes, etc.). L'utilisation des extensions serveur FrontPage (FPSE) n'est plus obligatoire.

Modèle de projet de site Web

  • Aucun fichier de projet (basé sur le système de fichiers).
  • Nouveau modèle de compilation.
  • Compilation dynamique et travail sur les pages sans construire le site entier sur chaque vue de page.
  • Prend en charge IIS et le serveur de développement ASP.NET intégré.
  • Chaque page a son propre assemblage.
  • Modèle de code différent.

5

Cela dépend toujours de l'exigence de votre client. ASP.NET comprend simplement des fonctionnalités flexibles dont l'utilisateur a besoin pour la sécurité et la maintenance facile de votre application.

Vous pouvez considérer une application Web comme un fichier binaire qui s'exécute à l'intérieur du cadre ASP.NET. Et les sites Web tant que page Web statique sur laquelle vous pouvez consulter et déployer facilement le code source.

Mais les avantages et les inconvénients de ces deux technologies ASP.NET viennent en bien.


4

Sites Web - Aucun fichier de solution ne sera créé. Si nous voulons créer des sites Web, pas besoin de studio visuel.

Application Web - Un fichier de solution sera créé. Si nous voulons créer une application Web, nous devons avoir besoin du studio visuel. Il créera un seul .dllfichier dans le dossier bin.


2
-1 Vous disposez en fait d'un fichier de solution si vous créez un projet de site Web via Visual Studio. Vous n'avez pas de fichier de projet.
Darren

+1 bien sûr, vous pouvez créer un fichier de solution mais ce fichier est principalement vide donc c'est juste une gêne (VS demande où enregistrer le fichier à la sortie) et pas quelque chose d'utile
frenchone

3

Dans les projets d'application Web, Visual Studio a besoin de fichiers .designer supplémentaires pour les pages et les contrôles utilisateur. Les projets de site Web ne nécessitent pas cette surcharge. Le balisage lui-même est interprété comme le design.


3

WebSite: Il génère automatiquement le dossier app_code et si vous le publiez sur le serveur et ensuite si vous effectuez des modifications dans un fichier ou une page en particulier, vous n'avez pas à compiler tous les fichiers.

Application Web Il génère automatiquement un fichier de solutions que le site Web ne génère pas et si vous modifiez un fichier, vous devez compiler le projet complet pour refléter ses modifications.


"Compiler un projet complet" ne signifie pas compiler tous les fichiers du projet. Les fichiers de code source qui n'ont pas été modifiés ne seront pas recompilés.
John Saunders

3

Dans une application Web, vous pouvez créer les couches de la fonctionnalité de votre projet et créer des interdépendances entre elles en la divisant en plusieurs projets, mais vous ne pouvez jamais le faire sur un site Web.


3

Certainement une application Web, un fichier DLL unique et facile à entretenir. Mais un site Web est plus flexible; vous pouvez modifier le fichier aspx sur la route.


Vous pouvez également modifier le fichier aspx dans un projet d'application Web.
John Saunders

3

Les applications Web nécessitent plus de mémoire, probablement parce que vous n'avez pas d'autre choix que de compiler en un seul assembly. Je viens de convertir un grand site hérité en application Web et j'ai des problèmes de manque de mémoire, à la fois au moment de la compilation avec le message d'erreur ci-dessous:

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

erreur, et lors de l'exécution avec ce message d'erreur comme ci-dessous:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

Ma recommandation pour convertir des sites plus grands sur du matériel hérité à mémoire limitée est de choisir l'option pour revenir au modèle de site Web. Même après un premier succès, le problème pourrait remonter plus tard.


Cela ne semble pas être une exception au moment de la compilation.
John Saunders

1

Ici, l'application Web Supportive est un exemple de site Web.

Ici, l'application Web Supportive est un exemple de site Web. Le site Web et l'application Web peuvent tous deux être dynamiques / statiques, cela dépend des exigences, voici un exemple pour comprendre le fonctionnement du site Web et de l'application Web.


Cela ne s'applique pas dans asp.net. La distinction site Web / application Web (dans la terminologie asp.net) concerne davantage la façon dont les fichiers sont organisés (en tant que solution bien organisée ou en tant que groupe de fichiers) et compilés ("JIT" vs statique). Dans les deux cas, le "programme" est principalement côté serveur.
frenchone

0

Pour résumer certaines des réponses ci-dessus:

Flexibilité , pouvez-vous apporter des modifications en direct à une page Web?

Site Web : Possible. Pro: avantages à court terme. Inconvénient: risque à long terme de chaos du projet.

Web App : Con: pas possible. Modifiez une page, archivez les modifications apportées au contrôle de code source, puis créez et déployez l'ensemble du site. Pro: maintenir un projet de qualité.

Problèmes de développement

Site Web : structure de projet simple sans fichier .csproj. Deux pages .aspx peuvent avoir le même nom de classe sans conflits. Nom de répertoire de projet aléatoire menant à des erreurs de génération, comme pourquoi le framework .net entre en conflit avec son propre fichier généré et pourquoi le framework .net entre en conflit avec son propre fichier généré . Pro: Simple (simpliste). Con: erratique.

Web App : structure de projet similaire au projet WebForms, avec un fichier .csproj. Les noms de classe des pages asp doivent être uniques. Pro: Simple (intelligent). Inconvénient: aucun, car une application Web est toujours simple.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.