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