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

Lorsque je lance 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 devrais-je choisir l’un sur l’autre?

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

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 dans l’édition.

Si Visual Studio ne doit pas réutiliser constamment les mêmes noms, il trouvera de nouveaux noms pour les fichiers DLL générés par les pages tout le temps. 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é qu’il n’était pas extrêmement populaire.

Application Web:

Le projet d’ application Web a été créé en tant que complément et fait désormais partie du SP 1 pour Visual Studio 2005. Les principales différences sont que le projet d’application Web a été conçu pour fonctionner comme les projets Web fournis avec Visual Studio 2003. Il sera comstackr l’application dans un seul fichier DLL au moment de la construction. Pour mettre à jour le projet, il doit être recompilé et le fichier DLL publié pour que les modifications puissent avoir lieu.

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 ne fait que suivre les 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 – Projet Web vs Web Application Project explique également pourquoi utiliser l’un et non 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 éditer un répertoire en tant que projet Web sans créer de fichier de projet? utiliser le projet de site Web.
  • Vous devez append les étapes de pré-construction et de post-construction lors de la compilation? utiliser le projet d’application Web.
  • Vous devez créer une application Web en utilisant plusieurs projets Web? utiliser le projet d’application Web.
  • Vous souhaitez générer un assemblage pour chaque page? utiliser le projet de site Web.
  • Vous préférez la compilation dynamic et le travail sur les pages sans construire un site entier sur chaque page? utiliser le projet de site Web.
  • Vous préférez le modèle de code à page unique au modèle code-behind? utiliser le projet de site Web.

Les projets d’application Web et les projets de site Web (MSDN) expliquent les différences entre le site Web et les projets d’application Web. En outre, il traite de la configuration à effectuer dans Visual Studio.

Site Web est ce que vous déployez sur un serveur Web ASP.NET tel qu’IIS. Juste un tas de fichiers et de dossiers. Il n’y a rien dans un site Web qui vous lie à 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) se font dynamicment à l’exécution et les modifications apscopes à ces fichiers sont détectées par la structure et automatiquement recompilées. Vous pouvez mettre le code que vous souhaitez partager entre les pages du dossier spécial App_Code ou le pré-comstackr et placer l’assemblage dans le dossier Bin.

Application Web est un projet Visual Studio spécial. La principale différence avec les sites Web est que, lorsque vous créez le projet, tous les fichiers de code sont compilés en un seul ensemble, 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 codes partagés, vous pouvez les placer n’importe où, comme vous le feriez dans la bibliothèque de classes. Web Applications contenant 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 codes 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. Web Applications est juste un moyen pratique de le faire.

CodeBehind

Cette rubrique est spécifique aux fichiers .aspx et .ascx. Cette rubrique est de plus en plus pertinente dans les nouvelles structures d’application telles que ASP.NET MVC et les pages Web ASP.NET qui n’utilisent pas les fichiers codebehind.

En compilant tous les fichiers de code dans un seul assemblage, y compris les fichiers codebehind des pages .aspx et des contrôles .ascx, dans les applications Web, vous devez les 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 pour gérer les assemblys codebehind est moins un travail pour vous, car vous n’avez pas besoin de vous soucier de donner des noms uniques aux pages / contrôles ou de les organiser dans des espaces de noms différents.

Je ne dis pas que le déploiement de fichiers de code est toujours une bonne idée (surtout dans le cas des fichiers de code partagé), mais les fichiers codebehind ne doivent contenir que du code exécutant des tâches spécifiques à l’interface, des gestionnaires d’événements, etc. en couches de sorte que le code important se retrouve 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 support Visual Studio spécial. C’est la beauté de l’extensibilité du fournisseur de construction.

En outre, dans les applications Web, vous ne détectez pas les erreurs dans les pages / contrôles car le compilateur ne comstack que vos classes codebehind et non le code de balisage (dans MVC, vous pouvez corriger cela avec l’option MvcBuildViews).

Visual Studio

Les applications Web étant 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 diverses 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 . Ceci n’est pas non plus disponible dans les sites Web. Travaille maintenant 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, en particulier pour les grands sites. Cela est principalement dû au fait que les applications Web ne comstacknt pas le code de balisage. Dans MVC, si vous définissez MvcBuildViews sur true, il comstack le code de balisage et vous obtenez une détection des erreurs, ce qui est très utile. L’inconvénient est que chaque fois que vous construisez la solution, il construit le site complet, ce qui peut être lent et inefficace, surtout si vous ne modifiez pas le site. Je me trouve à 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 solution est très rapide et vous pouvez toujours cliquer sur le nœud du 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 dialog supplémentaires pour les tâches courantes, telles que «Ajouter une vue», «Accéder à la vue», «Ajouter un contrôleur», etc.

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

NuGet Package Restore ne fonctionne pas sur les sites Web, vous devez installer manuellement les packages répertoriés sur packages.config La restauration de paquets fonctionne désormais avec les sites Web démarrant NuGet 2.7

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

Application Web = utiliser lorsque l’application est créée par des programmeurs et que les graphistes modifient uniquement une ou deux images paginées.

Les sites Web peuvent être utilisés avec n’importe quel outil HTML sans avoir à utiliser un studio de développement, car les fichiers de projet n’ont pas besoin d’être mis à jour, etc. Les applications Web sont les meilleures lorsque l’équipe utilise principalement un studio de développement.

(Certaines erreurs de codage sont détectées dans les applications Web lors de la compilation, mais pas dans les sites Web avant 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. Je pense que les choses ont maintenant évolué.

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

Pourquoi? Parce que le projet de site Web vous pousse à bout de arm lorsque vous essayez de modifier ou de comprendre votre projet. Les fonctionnalités de recherche de typage statique (par exemple, trouver des utilisations, refactor) dans Visual Studio prendront toutes une éternité sur tout projet de taille raisonnable. Pour plus d’informations, reportez-vous à la question sur le débordement de la stack “Rechercher toutes les références” dans Visual Studio .

Je ne vois vraiment pas pourquoi ils ont abandonné des applications Web dans Visual Studio 2005 pour le type de projet de site Web axé sur la productivité, le drainage et la perte de conscience.

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

Comparaison de projets de site Web et de projets d’application Web

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

  • Site Web vs Application Web ASP.Net dans Visual Studio note: a été supprimé, plus sur SO
  • site web ou application web dans.ASP.NET

Cela peut sembler un peu évident, mais je pense que c’est quelque chose qui est mal compris car Visual Studio 2005 est fourni uniquement avec le site Web. Si votre projet concerne un site Web relativement limité et peu séparé sur le plan logique ou physique, le site Web fonctionne bien. Cependant, s’il s’agit vraiment d’une application Web avec différents modules dans lesquels de nombreux utilisateurs ajoutent et mettent à jour des données, l’application Web est préférable.

Le plus gros avantage du modèle de site Web est que tout app_code dans la section app_code est compilé dynamicment. Vous pouvez effectuer des mises à jour de fichiers C # sans un redéploiement complet. Cependant, cela vient à un grand sacrifice. Beaucoup de choses se passent sous les couvertures difficiles à contrôler. Les espaces de noms sont difficiles à contrôler et une utilisation spécifique de la DLL sort par la fenêtre par défaut pour tout ce qui app_code car tout est compilé dynamicment.

Le modèle d’application Web n’a pas de compilation dynamic, mais vous contrôlez les éléments que j’ai mentionnés.

Si vous effectuez un développement multiniveau, je recommande fortement le modèle d’application Web. Si vous effectuez un site Web limité ou une implémentation rapide et sale, le modèle de site Web peut présenter des avantages.

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

  • Les projets d’application Web et les projets de déploiement Web sont ici
  • Site Web ou application Web?

Extrait du livre 70-515 de l’examen de formation auto-rythmé 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 comstackr l’application avant le déploiement, ce qui vous empêche de tester une page si une autre page ne sera pas compilée.
  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 recomstackr.

Compilation Tout d’abord, il y a une différence dans la compilation. Le site Web n’est pas pré-compilé sur le serveur, il est compilé dans un 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 ce fichier sur le serveur et tout fonctionnerait correctement. Dans Web Application, vous ne pouvez pas faire cela car tout est pré-compilé et vous obtenez une seule DLL. Lorsque vous modifiez quelque chose dans un fichier de votre projet, vous devez tout recomstackr. Donc, si vous souhaitez avoir la possibilité de modifier certains fichiers sur le serveur, le site Web est la meilleure solution pour vous. Cela 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. Cette option est également préférable pour les tests unitaires car un fichier DLL est créé après la publication de votre site Web.

Project structure diffère également. Dans l’application Web, vous avez un fichier de projet comme vous l’aviez dans une application normale. Dans 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 les parameters sont stockés dans le fichier web.config. @Page directive Il existe un atsortingbut différent dans la directive @Page pour le fichier qui contient la classe associée à cette page. Dans Web Application, il est standard “CodeBehind”, dans le site Web, vous utilisez “CodeFile”. Vous pouvez le voir dans les exemples ci-dessous:

 Web Application: <%@ 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 nom de l’application Web est simplement un nom du projet. Dans le site Web, il y a ASP par défaut pour les pages compilées dynamicment.

L’option Modifier et continuer l’application Web Modifier et continuer est disponible (pour l’activer, vous devez aller au menu Outils, cliquez sur Options, puis sur Modifier et continuer dans le débogage). Cette fonctionnalité ne fonctionne pas dans Web Site.ASP.NET MVCIf vous souhaitez développer des applications Web en utilisant

ASP.NET MVC (Model View Controller), la meilleure option par défaut est Web Application. Bien qu’il soit possible d’utiliser MVC dans le site Web, cela 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 vaste où quelques personnes peuvent le modifier, il est préférable d’utiliser le site Web. Mais si vous réalisez un projet plus petit, vous pouvez également utiliser l’application Web.

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 sera meilleur pour cela.

Une application a tendance à avoir ses données stockées dans une firebase database 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 assemblages est beaucoup plus contrôlé et offre une meilleure prise en charge des tests unitaires.

L’une des principales différences réside dans le fait que les sites Web comstacknt de manière dynamic et créent des assemblages à la volée. Les applications Web sont compilées dans un grand ensemble.

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

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

  1. Avoir plusieurs projets sous un même toit et établir des dépendances entre les projets. Par exemple, pour PCS, nous pouvons suivre les applications web-

    • Portails Web
    • Notification Controller (pour envoyer un courrier électronique)
    • Couche métier
    • Couche d’access aux données
    • Gestionnaire des exceptions
    • Utilitaire de serveur
    • Services WCF (Commun pour toutes les plates-formes)
    • Élément de la liste
  2. Pour exécuter des tests unitaires sur du code se trouvant dans les fichiers de classe associés aux pages ASP.NET

  3. Pour faire référence aux classes, celles-ci 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ôler le nom de l’assembly et le numéro de version généré pour le site
  6. Pour éviter de mettre 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é, l’access non autorisé au code source sur le serveur IIS peut vous inquiéter (pour un projet de site Web, vous pouvez éviter ce risque). la pré-compilation sur un ordinateur de développement et le déploiement des assemblys générés au lieu du code source, mais dans ce cas, vous perdez certains des avantages des mises à jour de site faciles.
  7. Problème de performances avec le site Web (la première demande sur le site Web peut nécessiter la compilation du site, ce qui peut entraîner un retard. Et si le site Web est exécuté sur un serveur IIS à court 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 assemblys.)

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 du code de l’application, le serveur recomstackra le code. Cela signifie que vous pouvez append / 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 que les temps de démarrage initiaux seront plus rapides.

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

Soit dit en passant, ne soyez pas confus par le titre, une grande partie de la vidéo explique la différence entre les projets de sites Web et les projets d’applications Web et pourquoi Microsoft a réintroduit des projets d’applications Web dans Visual studio 2005 (comme vous le savez probablement déjà) à l’origine livrés avec uniquement des projets de site Web, des projets d’application Web ont été ajoutés dans SP1). Une excellente vidéo que je recommande vivement à tous ceux qui veulent connaître la différence.

Un “site Web” a son code dans un répertoire spécial App_Code et est compilé en plusieurs DLL (assemblages) au moment de l’exécution. Une “application Web” est précompilée en une seule DLL.

Site Web et projet >> sont deux méthodes différentes pour créer une application ASP.NET en utilisant Visual Studio. L’un est sans projet et l’autre est l’environnement du projet. Les différences sont comme

  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 du 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 un environnement de projet.

Modèle de projet d’application Web

  • Fournit la même sémantique de projet Web que les projets Web Visual Studio .NET. Possède un fichier de projet (structure basée sur des fichiers de projet). Modèle de construction – tout le code du projet est compilé en un seul assemblage. Prend en charge à la fois 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, appartenance et connexion, navigation sur le site, thèmes, etc.). L’utilisation des extensions serveur FrontPage (FPSE) n’est plus une exigence.

Modèle de projet de site Web

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

Cela dépend toujours de l’exigence de votre client. ASP.NET inclut uniquement 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 binary qui s’exécute dans le framework ASP.NET. Et les sites Web en 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 sont ce qui est bien.

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 avons besoin du studio visuel. Il va créer un seul fichier .dll dans le dossier bin.

Dans les projets d’application Web, Visual Studio nécessite des 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 dessin.

Site Web: il génère automatiquement le dossier app_code et, si vous le publiez sur le serveur et si vous apportez des modifications à un fichier ou une page en particulier, vous n’avez pas besoin de comstackr tous les fichiers.

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

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

Certainement application web, fichier DLL unique et facile à entretenir. Mais un site Web est plus flexible. vous pouvez modifier le fichier aspx lors de vos déplacements.

Les applications Web nécessitent plus de mémoire, probablement parce que vous n’avez pas d’autre choix que de les comstackr en un seul assemblage. Je viens de convertir un grand site hérité en une application Web et j’ai des problèmes de mémoire, à la fois à 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 à 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 la conversion de sites plus volumineux sur du matériel hérité à contrainte de mémoire est de choisir l’option permettant de revenir au modèle de site Web. Même après un premier succès, le problème pourrait se manifester plus tard.

Ici, Web Supportive Application est un exemple de site Web.

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

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

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

Site Web : Possible. Pro: avantages à court terme. Con: risque à long terme du chaos du projet.

Application Web : Con: impossible. Modifiez une page, archivez les modifications apscopes au contrôle de code source, puis créez et déployez l’intégralité du site. Pro: maintenir un projet de qualité.

Problèmes de développement

Site Web : Structure de projet simple sans fichier .csproj. Les deux pages .aspx peuvent avoir le même nom de classe sans conflit. Nom de répertoire de projet aléatoire entraînant des erreurs de construction, par exemple pourquoi le framework .net est en conflit avec son propre fichier généré et pourquoi le framework .net est 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). Con: none, car une application web est encore simple.