Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction automatique. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Projets d'application Web et projets de site Web dans Visual Studio

Dans Visual Studio vous pouvez créer des projets d'application Web ou des projets de site Web. Vous créez ou ouvrez un projet d'application Web en choisissant Nouveau projet ou Ouvrir un projet dans le menu de Visual Studio Fichier . Vous créez ou ouvrez un projet de site Web en choisissant Nouveau site Web ou Ouvrir un site Web dans le menu Fichier.

Chaque type de projet a des avantages et des inconvénients, et c'est utile de comprendre les différences entre eux pour pouvoir sélectionner le type de projet le mieux adapté à vos besoins. Vous devez sélectionner le type de projet approprié avant de créer un projet, car il n'est pas évident de convertir un type de projet en un autre type.

Remarque Remarque

Pour certains cas, vous n'avez pas un tableau. Par exemple, si vous souhaitez créer une application ASP.NET MVC, vous devez utiliser un projet d'application Web.

Cette rubrique contient les sections suivantes :

Les scénarios dans lesquels les projets d'application Web sont préférés incluent les suivants :

  • Vous voulez pouvoir utiliser la fonctionnalité d' Modifier & Continuer du débogueur Visual Studio.

  • Vous souhaitez exécuter des tests unitaires sur le code qui est dans les fichiers de classe associés aux pages ASP.NET.

  • Vous souhaitez faire référence aux classes associées aux pages et aux contrôles utilisateur de classes autonomes.

  • Vous souhaitez établir des dépendances de projet entre plusieurs projets Web.

  • Vous souhaitez que le compilateur crée un assembly unique pour le site entier.

  • Vous souhaitez contrôler le nom de l'assembly et le numéro de version généré pour le site.

  • Vous souhaitez utiliser MSBuild ou Team Build pour compiler le projet. Par exemple, vous pouvez ajouter des étapes de prebuild et de postbuild.

  • Vous souhaitez éviter de mettre le code source sur un serveur de production.

  • Vous souhaitez utiliser les outils de déploiement automatisés qui sont disponibles dans Visual Studio.

Les scénarios dans lesquels les projets de site Web sont préférés incluent les suivants :

  • Vous souhaitez inclure le code C# et Visual Basic dans un projet Web unique. (Par défaut, une application Web est compilée en fonction de les paramètres de langue dans le fichier projet. Des exceptions peuvent être faites, mais c'est relativement difficile.)

  • Vous souhaitez ouvrir le site de production dans Visual Studio et le mettre à jour en temps réel à l'aide de FTP.

  • Vous ne souhaitez pas avoir à compiler explicitement le projet afin de le déployer.

  • Si vous précompilez le site, vous souhaitez que le compilateur crée plusieurs assemblys pour le site, lequel peut inclure un seul assembly par page ou contrôle utilisateur, ou un ou plusieurs assemblys par dossier.

  • Vous souhaitez être en mesure de mettre à jour des fichiers individuels en production en copiant simplement les nouvelles versions sur le serveur de production, ou en modifiant directement les fichiers sur le serveur de production.

  • Si vous précompilez le site, vous souhaitez pouvoir mettre à jour des pages Web ASP.NET (fichiers .aspx) sans devoir recompiler le site entier.

  • Vous souhaitez garder votre code source sur le serveur de production, parce qu'il peut servir de copie de sauvegarde supplémentaire.

Le tableau suivant récapitule les principales différences :

Zone

Projets d'application Web

Projets de site Web

Structure des fichiers projet

Un fichier projet Visual Studio (.csproj ou .vbproj) stocke des informations sur le projet, telles que la liste des fichiers inclus dans le projet et toutes les références entre projets.

Il n'existe aucun fichier projet (.csproj ou .vbproj). Tous les fichiers inclus dans une structure de dossiers sont automatiquement inclus dans le site.

Compilation

  • Vous compilez explicitement le code source sur l'ordinateur utilisé pour le développement ou le contrôle de code source.

  • Par défaut, la compilation des fichiers de code (à l'exclusion des fichiers .aspx et .ascx) produit un assembly unique.

  • Le code source est en général compilé dynamiquement (automatiquement) par ASP.NET sur le serveur la première fois qu'une demande est reçue à l'issue de l'installation ou de la mise à jour du site.

    Vous pouvez précompiler le site (le compiler à l'avance sur un ordinateur de développement ou sur le serveur).

  • Par défaut, la compilation produit plusieurs assemblys.

Espaces de noms

Des espaces de noms explicites sont ajoutés par défaut aux pages, aux contrôles et aux classes.

Par défaut, aucun espace de noms explicite n'est ajouté aux pages, aux contrôles et aux classes, mais vous pouvez en ajouter manuellement.

Déploiement

  • Vous copiez l'assembly sur un serveur. L'assembly est produit en compilant l'application.

  • Visual Studio fournit des outils qui s'intègrent au Web sont déployés (l'outil de déploiement Web IIS) pour automatiser de nombreuses tâches de déploiement.

  • Vous copiez les fichiers sources d'application sur un ordinateur sur lequel IIS est installé.

  • Si vous précompilez le site sur un ordinateur de développement, vous copiez les assemblys produits par compilation sur le serveur IIS.

  • Visual Studio fournit des outils pour le déploiement, mais elles n'automatisent pas autant de tâches de déploiement comme outils disponibles pour les projets d'application Web.

Les projets d'application Web utilisent des fichiers projet Visual Studio (.csproj ou .vbproj) pour effectuer le suivi des informations relatives au projet. Cela permet de spécifier quels fichiers sont inclus dans ou exclus du projet, et par conséquent que les fichiers sont compilés pendant une génération.

Pour les projets de site Web, tous les fichiers dans une structure de dossiers sont automatiquement considérés pour être inclus dans le site Web. Si vous souhaitez exclure un élément de la compilation, vous devez supprimer le fichier du dossier du projet de site Web ou modifier son extension de nom de fichier par extension qui n'est pas compilée et n'est pas servie par IIS.

Un avantage de l'utilisation des fichiers projet dans des projets d'application Web :

  • Il est facile de supprimer temporairement des fichiers du site, tout en veillant quand même à ne pas en perdre la trace, parce qu'ils restent dans la structure de dossiers. Par exemple, si une page n'est pas prête à être déployée, vous pouvez l'exclure temporairement de la build sans la supprimer de la structure de dossiers. Vous pouvez déployer l'assembly compilé, puis inclure de nouveau le fichier dans le projet. Cela s'avère particulièrement important si vous travaillez avec un référentiel de contrôle de code source.

Voici un avantage de l'utilisation d'une structure de dossiers sans fichiers projet dans des projets de site Web :

  • Vous n'avez pas à gérer la structure du projet exclusivement dans Visual Studio. Par exemple, vous pouvez copier des fichiers dans le projet ou les supprimer du projet à l'aide de l'Explorateur de fichiers.

Pour les projets d'application Web, vous générez en général le projet dans Visual Studio ou à l'aide de compilation par lots ASP.NET sur un ordinateur qui n'est pas le serveur IIS de production. Tous les fichiers de classe code-behind et fichiers de classe autonomes dans le projet sont compilés dans un assembly unique, qui est ensuite mis dans le dossier Bin du projet d'application Web. (Les fichiers .aspx et .ascx sont dynamiquement d'une manière similaire compilé à ce qui est fait pour les projets de site Web.)

Pour les projets de site Web, vous ne devez pas manuellement compiler le projet. les projets de site Web sont en général compilés dynamiquement par ASP.NET (sur l'ordinateur de développement et le serveur IIS de production). Vous pouvez choisir entre le mode de compilation par lots, lequel produit en général un seul assembly par dossier, et le mode de compilation fixe, lequel produit en général un assembly pour chaque page ou contrôle utilisateur.

Les avantages du modèle de compilation pour les projets d'application Web sont les suivants :

  • Vous pouvez utiliser MSBuild pour créer un processus de compilation par lots personnalisé.

  • Il est facile de spécifier des attributs d'assembly tels que le nom et la version.

  • La compilation à l'avance permet de veiller à ce que les utilisateurs n'aient pas à attendre pendant la compilation du site sur le serveur de production. (Si le site est très volumineux, la compilation dynamique d'un projet de site Web peut prendre beaucoup de temps. Une compilation dynamique se produit lorsqu'une demande de ressource de site est reçue après une mise à jour du site, et cette demande qui déclenche la compilation peut être différée pendant que les ressources requises sont compilées. Si le délai est inacceptable, vous pouvez précompiler le site. Toutefois, certains des avantages liés à la compilation dynamique sont alors perdus.)

  • Vous contrôlez entièrement l'emplacement auquel vous placez les fichiers de code dans la structure de dossiers du projet, ainsi que la manière dont les classes se font référence dans le projet. (La compilation dynamique requiert que le code source de toutes les classes utilisées dans tout le site se trouve dans le dossier App_Code. Vous ne pouvez pas faire référence à une page ou à une classe de contrôle utilisateur à partir d'une classe dans App_Code.)

Les avantages du modèle de compilation pour les projets de site Web sont les suivants :

  • Vous pouvez tester des pages spécifiques indépendamment de l'état des autres pages. La raison est que l'exécution d'une page individuelle ne requiert pas une compilation correcte de tout le site, mais uniquement de la page et de tous les composants dont elle dépend, tels que le code dans le dossier App_Code ou le fichier Global.asax. (Dans un projet d'application Web, s'il y a des erreurs de compilation n'importe où dans le site, vous ne pouvez pas créer l'assembly et ne pouvez donc pas tester même les parties du site qui compilent.)

  • Il est facile de mettre à jour un site Web en production. Vous pouvez mettre à jour des fichiers de code source individuels sur le serveur de production sans devoir recompiler le site explicitement. Vous pouvez mettre à jour des fichiers individuels qui sont prêts pour le déploiement même si d'autres fichiers ne sont pas prêts en raison d'erreurs de compilation. Vous pouvez également ouvrir directement le site Web sur le serveur IIS de production dans Visual Studio et le mettre à jour en temps réel.

  • Une précompilation sur plusieurs assemblys peut représenter un avantage en termes de performances dans certains scénarios. Un site qui comporte de nombreuses pages contenant beaucoup de code en est un exemple typique. La plupart des pages sont rarement demandés et seules certaines d'entre elles sont fréquemment utilisées. Si vous compilez un site comme celui-ci dans plusieurs assemblys, le serveur de production peut charger uniquement les assemblys qui sont obligatoires pour les demandes actuelles. Si une page n'est pas demandée, son assembly correspondant n'est pas chargé.

Remarque Remarque

Il n'existe aucune différence de performances entre un projet de site Web et un projet d'application Web. Les seules exceptions significatives sont celles déjà notées, et en pratique elles s'appliquent uniquement aux sites très volumineux. La première demande au site Web peut nécessiter du site d'être compilée, qui peut provoquer un délai. Et si le site Web s'exécute sur un serveur IIS qui est court de mémoire, y compris le site entier dans un assembly unique peut utiliser plus de mémoire que sont requis pour plusieurs assemblys.

Pour déployer un projet d'application Web, vous copiez l'assembly créé lors de la compilation du projet sur un serveur IIS. En revanche, pour déployer un projet de site Web, vous copiez généralement des fichiers sources de projet sur un serveur IIS.

Les avantages de la stratégie de déploiement pour les projets d'application Web sont les suivants :

  • 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, l'accès non autorisé au code source sur le serveur IIS peut vous préoccuper. (Pour un projet de site Web, vous pouvez éviter ce risque en précompilation sur un ordinateur de développement et en déployant des assemblys générés au lieu de code source. Toutefois, vous perdez alors certains des avantages liés à la facilité des mises à jour du site.)

  • Le déploiement implique souvent d'autres tâches outre la copie des assemblys ou du code sur un serveur. Par exemple, des scripts de base de données doivent peut-être être exécutés en production, et les chaînes de connexion contenues dans le fichier Web.config doivent peut-être être modifiées pour un serveur de production. Visual Studio fournit des outils tels que la publication en un clic ce travail avec les projets d'application Web d'automatiser la plupart de ces tâches. Ces outils sont pas disponibles pour les projets de site Web.

Les avantages de la stratégie de déploiement pour les projets de site Web sont les suivants :

  • Si vous modifiez une petite modification un site Web, vous ne devez pas redéployer le site entier. À la place, vous pouvez copier simplement le ou les fichiers modifiés sur le serveur IIS de production. Vous pouvez également modifier directement des fichiers sur le serveur de production. (Comme les fichiers de code du projet d'application Web sont compilés dans un fichier d'assembly unique, vous devez déployer tout le site même pour les petites modifications, à moins que la seule modification soit dans un fichier .aspx ou .ascx.)

Ajouts de la communauté

Afficher:
© 2014 Microsoft