Le Site Web est ce que vous déployez pour un ASP.NET serveur web (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 (tels que .aspx, .ascx, .maître) est fait dynamiquement à l'exécution, et les modifications apportées à ces fichiers sont détectés par le cadre et automatiquement re-compilé. Vous pouvez mettre le code que vous souhaitez partager entre les pages spéciales le dossier App_Code, ou vous pouvez pré-compiler et de mettre de l'assemblée dans le dossier Bin.
Une Application Web est un particulier de projet Visual Studio. La principale différence avec les Sites Web, c'est que lorsque vous générez le projet, tous les fichiers de code compilé dans une seule assemblée, qui est placée dans le répertoire bin. Vous n'avez pas de déployer le code des fichiers vers le serveur web. Au lieu d'avoir un dossier spécial pour le partage de fichiers de code, vous pouvez les mettre n'importe où, tout comme vous le feriez dans la bibliothèque de la classe. Parce que les Applications Web contient des fichiers qui ne sont pas destinés à être déployées, telles que le projet et les fichiers de code, il y a un Publier de commande de Visual Studio pour la sortie d'un Site Web à un emplacement spécifié.
App_Code vs Bin
Le déploiement de code partagé des fichiers est généralement une mauvaise idée, mais cela ne signifie pas que vous devez choisir l'Application Web. Vous pouvez avoir un Site Web qui fait référence à un projet de bibliothèque de classes qui contient tout le code pour le Site Web. Les Applications Web est juste un moyen pratique de le faire.
Le code-behind
Cette rubrique est spécifique .aspx et .fichiers ascx. Cette rubrique est de moins en moins pertinente dans les nouvelles structures d'application telles que ASP.NET MVC et ASP.NET les Pages Web qui n'utilisent pas le code-behind de fichiers.
En ayant tous les fichiers de code compilé dans une seule assemblée, y compris le code-behind de fichiers .pages aspx et .ascx des contrôles, dans les Applications Web que vous avez à re-construire pour chaque petit changement, et vous ne pouvez pas faire vivre des changements. Cela peut être une vraie douleur au cours du développement, depuis que vous avez à garder re-bâtiment pour voir les changements, tandis que les Sites Web des changements sont détectés par le moteur d'exécution et des pages/les contrôles sont automatiquement recompilés.
Avoir le moteur d'exécution de gérer le codebehind assemblées est moins de travail pour vous, puisque vous n'avez pas besoin de s'inquiéter à propos de donner pages/contrôles des noms uniques, ou en organisant 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 pas dans le cas de partage de fichiers de code), mais le code-behind fichiers ne doivent contenir du code que de l'INTERFACE utilisateur d'effectuer des tâches spécifiques, le fil des événements de gestionnaires, etc. Votre application doit être en couches de sorte que le code important finissent toujours dans le dossier Bin. Si c'est le cas, alors le déploiement de code-behind de fichiers ne devraient pas être considérées comme néfastes.
Une autre limitation des Applications Web est que vous pouvez utiliser uniquement la langue du projet. Dans les Sites Web vous pourrez avoir des pages en C#, certains en VB, etc. Pas de besoin particulier support Visual Studio. C'est la beauté de la construction fournisseur de l'extensibilité.
Aussi, dans les Applications Web, vous n'obtenez pas de détection d'erreur dans les pages/contrôles que le compilateur ne compile le code-behind de classes et non pas le code de balisage (MVC, vous pouvez résoudre ce problème à l'aide de la MvcBuildViews option), qui est établie au moment de l'exécution.
Visual Studio
Parce que les Applications Web sont des projets Visual Studio, vous obtenez quelques fonctionnalités ne sont pas disponibles dans les Sites Web. Par exemple, vous pouvez utiliser les événements de construction pour effectuer une variété de tâches, par exemple, minifier et/ou combiner des fichiers Javascript.
Une autre fonctionnalité intéressante introduite dans Visual Studio 2010 est Web.config de transformation. Ce n'est également pas disponible dans les Sites Web. Fonctionne maintenant avec les Sites Web de VS 2013.
Création d'une Application Web est plus rapide que la construction d'un Site Web, spécialement pour les grands sites. C'est principalement parce que les Applications Web ne sont pas compiler le code de balisage. Dans MVC si vous définissez MvcBuildViews est vraie, alors il compile le code de balisage et vous obtenez l'erreur de détection, 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, qui peut être lent et inefficace, spécialement si vous ne modifiez pas le site. l me retrouve à tourner MvcBuildViews sur et en dehors (ce qui nécessite un projet de déchargement). D'autre part, des Sites Web, vous pouvez choisir si vous voulez construire le site en tant que partie de la solution ou pas. Si vous choisissez de ne pas, puis de la création de la solution est très rapide, et vous pouvez toujours cliquer sur le nœud Site Web et sélectionnez " Build, si vous avez effectué des modifications.
Dans une Application Web MVC projet vous avez des commandes et boîtes de dialogue pour les tâches courantes, comme "Add View", "Aller À la Vue", "Ajouter un Contrôleur", etc. Ces ne sont pas disponibles dans un MVC Site Web.
Si vous utilisez IIS Express en tant que serveur de développement, dans les Sites Web que vous pouvez ajouter des répertoires virtuels. Cette option n'est pas disponible dans les Applications Web.
Package NuGet de Restauration ne fonctionne pas sur les Sites Web, vous devez installer manuellement les paquets indiqués sur les emballages.config Paquet de Restauration fonctionne maintenant avec les Sites Web de départ NuGet 2.7