Améliorations de Visual Studio 2005

par Microsoft

Visual Studio 2005 fournit aux développeurs d’applications web une longue liste d’améliorations et d’améliorations apportées aux projets web.

Visual Studio 2005 fournit aux développeurs d’applications web une longue liste d’améliorations et d’améliorations apportées aux projets web. Aussi puissant que Visual Studio .NET 2002 et 2003 sont, il y a eu de nombreuses plaintes dans la façon dont les projets web ont été gérés. Visual Studio 2005 ajoute un nombre important de nouvelles fonctionnalités afin de résoudre ces plaintes. Pour ceux qui préfèrent la façon dont Visual Studio .NET 2003 gère la compilation d’applications web, consultez Projets d’application web.

Dans ce module, couvrez bien les améliorations apportées à la création, à la gestion et au développement de projets web. Dans un module ultérieur, couvrez bien les améliorations apportées à la création de projets web et à leur déploiement.

Extensions serveur FrontPage

Visual Studio .NET 2002 et 2003 ont requis les extensions serveur FrontPage dans la zone pour créer ou générer des projets web. Les développeurs avaient le choix entre deux modes d’accès différents (extensions serveur FrontPage ou mode d’accès aux fichiers), les deux utilisaient les extensions serveur FrontPage pour effectuer des tâches telles que la définition de la racine de l’application dans IIS, etc.

Visual Studio 2005 supprime la dépendance à l’égard des extensions serveur FrontPage pour les projets locaux. Visual Studio 2005 accède désormais directement à la métabase IIS au lieu d’utiliser les extensions serveur FrontPage. Visual Studio 2005 ajoute également la prise en charge de FTP qui permet l’accès à distance aux projets sans nécessiter d’extensions serveur FrontPage.

Pour les développeurs qui souhaitent utiliser les extensions serveur FrontPage dans leurs projets, l’option est toujours disponible. Toutefois, d’après les commentaires forts de la communauté des développeurs ASP.NET, il ne s’agit pas d’une exigence.

Notes

Les extensions serveur FrontPage sont toujours requises pour la création de projets distants, l’ouverture, etc.

Vue d’ensemble du serveur de développement ASP.NET

Visual Studio 2005 est fourni avec un nouveau serveur web appelé ASP.NET Development Server. (Ce serveur web était précédemment appelé Cassini.)

Le serveur de développement ASP.NET présente plusieurs avantages.

• Il est désormais possible pour les non-administrateurs de développer et de déboguer sur un serveur web.
• Le serveur de développement ASP.NET mappe dynamiquement les répertoires virtuels à n’importe quel emplacement dans le système de fichiers, ce qui permet des emplacements de projet flexibles.
• Les utilisateurs de Windows XP Professionnel qui utilisent déjà IIS pourront désormais créer de nouvelles applications web qui n’affecteront pas la structure de fichiers ou de dossiers de leur site web par défaut dans IIS.

Aucune configuration spéciale n’est requise pour tirer parti du serveur de développement ASP.NET. Lorsqu’un projet web hébergé sur le système de fichiers est débogué ou parcouru, Visual Studio 2005 démarre automatiquement une instance du serveur de développement ASP.NET sur un port aléatoire pour traiter la demande.

Plus d’informations seront traitées sur le serveur de développement ASP.NET plus loin dans ce module.

Amélioration de la gestion des fichiers

Dans Visual Studio 2002 et 2003, un fichier projet (.vbproj pour VB.NET et .csproj pour C#) stockait des informations sur tous les fichiers de l’application web. L’affichage Explorateur de solutions est basé sur les informations du fichier dans le fichier projet. Pour cette raison, le Explorateur de solutions affichait souvent des informations inexactes dans les cas où des éditeurs externes étaient utilisés. Visual Studio 2002 et 2003 remplace souvent les modifications de fichier ou n’affiche pas la version la plus récente des fichiers.

Visual Studio 2005 ne contient plus le fichier projet. Au lieu de cela, il lit les informations de fichier et de dossier directement à partir du disque, ce qui entraîne un affichage précis des fichiers dans votre projet. Étant donné que le dossier References de Visual Studio 2002 et 2003 ne représente pas un dossier réel dans votre application web, Visual Studio 2005 supprime également le dossier References de Explorateur de solutions. Pour accéder aux références de votre projet dans Visual Studio 2005, vous devez utiliser les pages Propriétés du projet.

Création de projets web

Les développeurs web disposent de nombreuses nouvelles options pour la création de projets dans Visual Studio 2005. Les sites web peuvent désormais être créés n’importe où dans le système de fichiers et peuvent ensuite être débogués ou parcourus à l’aide du nouveau serveur de développement ASP.NET. Les développeurs peuvent également créer de nouveaux sites Web à l’aide de FTP.

Cliquez ici pour afficher une procédure vidéo pas à pas de la création de projets web dans Visual Studio 2005.

Ouvrir Full-Screen vidéo

Projets de système de fichiers

Comme vous l’avez vu dans la procédure pas à pas de la vidéo, vous pouvez choisir de créer des sites Web sur le système de fichiers sur l’ordinateur local ou sur un emplacement distant via un partage de fichiers. Les sites web créés sur le système de fichiers sont parcourus et débogués à l’aide du serveur de développement ASP.NET.

Notes

Le serveur de développement ASP.NET peut causer une certaine confusion pour les clients. Si un projet web est créé sur le système de fichiers dans la structure de répertoires IISs (c:/inetpub/wwwroot), le site web est toujours parcouru via le serveur de développement ASP.NET lors du lancement à partir de Visual Studio 2005. Par conséquent, toute configuration IIS (c’est-à-dire les méthodes d’authentification) n’est pas applicable.

Le projet web par défaut supprime également une grande partie de la surcharge en incluant uniquement une page Default.aspx, un fichier default.cs et un dossier App/_Data. Les web.config et les dossiers spéciaux (par exemple, app/_code) sont ajoutés en fonction des besoins. Votre projet web inclut uniquement les fichiers et dossiers dont vous avez besoin.

Projets HTTP

Les projets HTTP peuvent être des projets créés sur un site Web IIS local ou sur un site Web distant. L’emplacement du projet par défaut est http://localhost. Si vous cliquez sur le bouton Parcourir, il existe deux options HTTP : IIS local et Site distant. La main différence dans ces deux options est la méthode dans laquelle les informations de site web sont affichées dans la boîte de dialogue Choisir l’emplacement et dans la façon dont les fichiers sont copiés sur le serveur web.

L’option IIS local lit les informations du site à partir de la métabase sur l’ordinateur local et les fichiers sont copiés à l’aide du système de fichiers. L’option Site distant utilise les extensions serveur FrontPage et les informations et fichiers du site sont copiés à l’aide des appels RPC des extensions de serveur HTTP et FrontPage.

Notes

Le fichier vs###/_tmp.htm et get/_aspx/_ver.aspx ne sont plus utilisés pour déterminer les informations de version.

L’option HTTP par défaut est IIS local. Cette option lit la métabase IIS pour déterminer quels sites sont disponibles et l’emplacement dans lequel créer du contenu. Vous pouvez sélectionner un autre dossier ou répertoire virtuel en le sélectionnant dans l’arborescence. Vous pouvez également créer un répertoire virtuel, marquer des dossiers en tant qu’applications et supprimer des répertoires virtuels existants de cette boîte de dialogue.

Figure 1 : Boîte de dialogue Choisir l’emplacement

Contrairement aux versions antérieures de Visual Studio, si vous case activée la case Utiliser la couche de sockets sécurisés et que le certificat SSL ne correspond pas à l’URL que vous parcourez, une boîte de dialogue Alerte de sécurité vous demande si vous souhaitez continuer. À l’aide de Visual Studio .NET 2003, si le certificat n’était pas correspondant, la création du projet échouerait.

Figure 2 : Alerte de sécurité concernant le certificat SSL

Remarque sur les en-têtes d’hôte

Si vous créez une application web sur un site lié à une adresse IP spécifique, vous devez vous assurer qu’un en-tête d’hôte est configuré. Sinon, Visual Studio créera le site à l’emplacement http://localhost, mais l’adresse IP ne sera pas résolue correctement lorsque le site est parcouru ou débogué à partir de l’IDE.

Si vous sélectionnez l’option Site distant, la boîte de dialogue change pour vous permettre d’entrer l’URL de destination du nouveau site web. Cette URL doit se trouver sur un serveur sur lequel les extensions serveur FrontPage sont activées. Si vous souhaitez utiliser votre serveur web local à l’aide des extensions serveur FrontPage, vous pouvez utiliser l’option Site distant et spécifier une URL locale.

Figure 3 : Création d’un site web sur un serveur distant

Lors de la création d’une application sur un site distant via SSL, si le certificat SSL ne correspond pas, la boîte de dialogue de confirmation est légèrement différente de la boîte de dialogue affichée lors de l’utilisation de l’option IIS local.

Figure 4 : Alerte de sécurité des sites distants

FTP

Visual Studio 2005 introduit l’option permettant de créer des sites Web via FTP. Lorsque vous utilisez cette option, l’IDE crée les fichiers localement dans le dossier temporaire des utilisateurs, puis utilise FTP pour déplacer les fichiers vers l’emplacement FTP.

Notes

L’emplacement du dossier temp est c:/Documents and Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<application name>

Lorsque vous utilisez l’option FTP, une boîte de dialogue Choisir l’emplacement s’affiche. Vous entrez les informations de connexion FTP requises dans cette boîte de dialogue, comme indiqué ci-dessous.

Figure 5 : Boîte de dialogue Choisir l’emplacement pour FTP

Labo : Configurer le site FTP et créer un projet

Les étapes suivantes configurent le site FTP afin qu’un utilisateur dispose d’un emplacement vers lequel seul il peut charger via FTP.

Installer le service FTP

1. Ouvrez Ajouter des programmes de suppression, sélectionnez Ajouter/supprimer des composants Windows.
2. Sélectionnez Internet Information Services (serveur d’applications sur Windows 2003), puis cliquez sur Détails.
3. Vérifiez le service FTP (File Transfer Protocol) et cliquez sur OK.
4. Cliquez sur Suivant pour installer le service FTP.

Créer un dossier pour le contenu

1. Dans Windows Explorer, créez un dossier nommé User1 dans c:/inetpub/wwwroot.

Configurez les dossiers et les autorisations sur les dossiers.

1. Ouvrez le composant logiciel enfichable Internet Information Services à partir des Outils d’administration. Vous disposez maintenant d’un dossier Sites FTP sous le nœud nom de l’ordinateur.
2. Développez Sites FTP.
3. Cliquez avec le bouton droit sur site FTP par défaut, sélectionnez Nouveau, répertoire virtuel, puis cliquez sur Suivant.
4. Entrez User1 pour le nom du répertoire virtuel, puis cliquez sur Suivant.
5. Entrez c:/inetpub/wwwroot/User1 pour le chemin d’accès, puis cliquez sur Suivant.
6. Cliquez sur Suivant , puis sur Terminer pour terminer l’Assistant.
7. Cliquez avec le bouton droit sur le répertoire virtuel User1 sous Site FTP par défaut, puis sélectionnez Propriétés.
8. Cochez la case Écrire , puis cliquez sur OK pour fermer la boîte de dialogue.
9. Cliquez avec le bouton droit sur Site FTP par défaut , puis sélectionnez Propriétés.
10. Sous l’onglet Comptes de sécurité , décochez Autoriser les connexions anonymes.
11. Cliquez sur Oui dans la boîte de dialogue pour vous demander si vous souhaitez continuer.
12. Cliquez sur OK pour fermer la boîte de dialogue.
13. Développez le site web par défaut sous le nœud Sites Web .
14. Cliquez avec le bouton droit sur le répertoire User1 et sélectionnez Propriétés
15. Dans la section Paramètres de l’application , cliquez sur Créer pour marquer le dossier en tant qu’application.
16. Cliquez sur OK pour fermer la boîte de dialogue.
17. Fermez le composant logiciel enfichable Internet Information Services.

Créer un projet web

1. Ouvrez Visual Studio 2005.
2. Dans le menu Fichier , sélectionnez Nouveau site web.
3. Dans la liste déroulante Emplacement , sélectionnez FTP.
4. Cliquez sur Parcourir.
5. Entrez localhost dans la zone de texte Serveur .
6. Entrez User1 dans la zone de texte Répertoire.
7. Cliquez sur Ouvrir. L’emplacement FTP est entré dans la boîte de dialogue Nouveau site web.
8. Cliquez sur OK.
9. Décochez Connexion anonyme dans la boîte de dialogue Connexion FTP, entrez vos informations d’identification, puis cliquez sur OK.
10. Quelle est l’URL du projet ? (L’URL du projet s’affiche dans Explorateur de solutions.)
11. Dans le menu Générer , sélectionnez Générer un site web ou Générer une solution.
12. Cliquez avec le bouton droit sur Default.aspx dans Explorateur de solutions, puis sélectionnez Afficher dans le navigateur.
13. Dans la boîte de dialogue URL du site web obligatoire, entrez http://localhost/user1 comme URL, puis cliquez sur OK.

Notes

Si vous obtenez une erreur indiquant une incapacité à charger le type /_Default, assurez-vous que vous exécutez ASP.NET 2.0 sur votre site Web et non une version antérieure. Vous pouvez le faire à partir de l’onglet ASP.NET dans Internet Information Services.

Ouverture de projets web

L’ouverture de projets web est similaire à la création de projets. Les sections suivantes décrivent les zones à surveiller lors de l’utilisation de l’IDE. Il traite également de l’utilisation de projets web à l’aide de HTTP et FTP.

Pour ouvrir un projet Web, sélectionnez Ouvrir le site web dans le menu Fichier. Vous serez invité à utiliser la même boîte de dialogue Choisir l’emplacement abordée précédemment et vous disposez des quatre mêmes options : Système de fichiers, IIS local, FTP et Site distant.

Système de fichiers

Comme indiqué précédemment dans ce module, Visual Studio n’utilise plus de fichier projet. Par conséquent, si vous choisissez d’ouvrir un site Web à partir du système de fichiers, vous avez en fait la possibilité de choisir n’importe quel dossier de votre choix, même si le dossier que vous choisissez n’a pas été créé initialement en tant que projet Web dans Visual Studio. Par exemple, vous pouvez choisir d’ouvrir le dossier Mes documents en tant que site web et Visual Studio l’ouvre et affiche vos fichiers comme indiqué ci-dessous.

Figure 6 : Mes documents ouverts en tant que site web

Étant donné que Visual Studio crée uniquement des fichiers et dossiers supplémentaires si nécessaire, aucun fichier ou dossier supplémentaire n’est ajouté à l’emplacement que vous ouvrez. Un effet secondaire de cette architecture est qu’elle vous empêche d’imbriquer des sites Web sur le système de fichiers. Par exemple, considérez la structure de répertoires suivante.

Projet web sur C:/MyWebSite

Un autre projet web sur C:/MyWebSite/Nested

Lorsque vous ouvrez le site Web à l’adresse c:/MyWebSite, le dossier imbriqué apparaît sous la forme d’un sous-dossier de cette application.

HTTP

Lors de l’ouverture de sites Web via HTTP, les paramètres sont lus à partir de la métabase IIS (IIS local) ou à l’aide des extensions serveur FrontPage (site distant).) S’il existe des applications web imbriquées, celles-ci sont également affichées avec une icône les identifiant en tant qu’application. Si vous êtes familiarisé avec l’utilisation d’applications web dans FrontPage, le comportement dans Visual Studio 2005 est similaire.

Même si Visual Studio affiche une icône pour les applications imbriquées sous l’application actuellement ouverte dans l’IDE, il ne vous permet pas de les développer pour voir leur contenu. Vous pouvez toutefois double-cliquer dessus pour les ouvrir. Dans ce cas, une boîte de dialogue vous invite à ouvrir l’application web (et à remplacer la solution actuellement ouverte) ou à ajouter l’application web à votre solution actuelle.

Figure 7 : Le double-clic sur une icône d’application imbriquée vous présente cette boîte de dialogue

Site FTP

Lorsque vous ouvrez un site via FTP, les fichiers sont tous copiés localement dans votre dossier temporaire. Le chemin d’accès complet de l’emplacement de stockage local s’affiche dans le volet Propriétés du projet et est créé au format suivant.

C:/Documents and Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<application name>

Lors de l’utilisation de FTP, Visual Studio doit spécifier l’URL de base de votre projet afin que vous puissiez le parcourir comme indiqué ci-dessous. Si vous ne spécifiez pas d’URL de base, Visual Studio vous en demandera la première fois que vous tentez de parcourir une page dans le site Web.

Figure 8 : Spécification d’une URL de base pour les sites FTP

Améliorations apportées à la compilation

L’utilisation d’applications web dans Visual Studio 2005 est sensiblement plus rapide que les versions précédentes. Cela est dû en partie aux modifications apportées à l’architecture de compilation.

Dans Visual Studio 2002 et 2003, les applications web ont été compilées dans un assembly principal résidant dans le dossier /bin. Dans Visual Studio 2005, un dossier App/_Code a été ajouté. Des classes et d’autres codes autres que l’interface utilisateur sont ajoutés au dossier App/_Code. Lorsque Visual Studio génère le projet, tous les fichiers du dossier App/_Code sont compilés en un seul fichier App/_Code.dll. Le résultat de cette modification est que les builds suivantes sont beaucoup plus rapides que dans les versions précédentes.

Notes

L’utilitaire de ligne de commande MSBuild peut également être utilisé pour générer ASP.NET applications web. Cet outil sera abordé dans le module 9.

Une autre amélioration de la compilation est la nouvelle option Page de build dans le menu Générer. Cette fonctionnalité permet à un développeur de reconstruire uniquement la page active (avec, bien sûr, et les dépendances) afin que les modifications puissent être compilées plus rapidement. Étant donné que C# n’offre pas de compilation en arrière-plan à des fins de mise à jour d’IntelliSense, etc., ils bénéficieront énormément de cette fonctionnalité, car elle permettra à IntelliSense d’être mis à jour rapidement en reconstruisant simplement une seule page.

Les propriétés de build d’un projet vous permettent de configurer le type de build qui se produit avant l’exécution de la page de démarrage. Les développeurs peuvent choisir de générer uniquement la page active afin que Visual Studio puisse commencer à déboguer les applications plus rapidement après les modifications du code.

Figure 9 : Action de démarrage de la page de génération

Une autre amélioration importante de Visual Studio et de l’architecture ASP.NET est dans le domaine de la modification et de la poursuite. Dans Visual Studio 2005, les développeurs peuvent commencer à déboguer un projet et apporter des modifications au code sur le projet sans détacher le débogueur. En fait, vous pouvez littéralement commencer à déboguer un projet, ajouter une nouvelle classe, ajouter du code à cette classe, ajouter du code à votre page qui crée une nouvelle instance de cette classe et exécuter une méthode de la classe, le tout sans détacher le débogueur. L’exécution du nouveau code est littéralement aussi simple que l’actualisation du navigateur !

Cliquez ici pour afficher une procédure pas à pas vidéo de la fonctionnalité modifier et continuer dans Visual Studio 2005.

Ouvrir Full-Screen vidéo

La fonctionnalité de modification et de poursuite robuste dans ASP.NET 2.0 et Visual Studio 2005 est due à un changement d’architecture pour ASP.NET applications. Dans ASP.NET 1.x, les applications créées dans Visual Studio 2002/2003 ont été compilées dans un assembly principal stocké dans le dossier /bin. Toutes les classes, pages, etc. pour l’application ont été compilés dans cette DLL. Ensuite, au moment de l’exécution, ASP.NET compile tous les contrôles, le balisage et ASP.NET code dans les pages et copiez ces DLL dans le dossier temporaire ASP.NET.

Dans Visual Studio 2005 à l’aide de ASP.NET 2.0, les deux modèles de compilation décrits ci-dessus (un pour Visual Studio et un pour ASP.NET au moment de l’exécution) ont été fusionnés dans un modèle de compilation commun. Cela signifie que tous les problèmes de compilation sont désormais détectés pendant la phase de développement plutôt qu’au moment de l’exécution. Il permet également de prendre en charge le concepteur et IntelliSense pour des fonctionnalités telles que les contrôles utilisateur et les pages master.

Cliquez ici pour voir une procédure vidéo pas à pas de la prise en charge du concepteur pour les contrôles utilisateur.

Ouvrir Full-Screen vidéo

Notes

Lorsqu’un contrôle utilisateur est supprimé d’une page, la @Register directive reste dans le balisage et doit être supprimée manuellement afin d’éviter les erreurs d’analyseur si le contrôle utilisateur est supprimé du site web.

Une autre amélioration du modèle de compilation Visual Studio est la fonctionnalité Publier un site web. Étant donné que la fonctionnalité Publier précompile le site web, les développeurs peuvent profiter des performances supplémentaires de ne pas avoir à compiler quoi que ce soit à la demande. Il précompile également tout le code source du dossier App/_Code dans une DLL afin qu’aucun code source ne soit déployé.

Figure 10 : boîte de dialogue Publier un site web

Notes

L’utilitaire aspnet/_compile.exe peut également être utilisé pour précompiler une application web ASP.NET. Cet outil sera abordé dans le module 9.

Lorsque vous publiez un site web, les fichiers précompilés sont stockés dans le dossier Temporary ASP.NET Files, comme indiqué ci-dessous. Les fichiers avec une extension de fichier .compiled sont des fichiers XML qui définissent des dépendances pour des DLL particulières. Tous les contrôles Webform ou utilisateur sont compilés dans des DLL aléatoires qui commencent par App/Web/.

Si vous laissez la case à cocher Autoriser ce site précompilé à être mis à jour , le balisage à l’intérieur de vos formulaires Web et contrôles utilisateur ne sera pas précompilé dans une DLL vous permettant d’apporter des modifications après le déploiement. Si vous préférez verrouiller le balisage afin que les modifications apportées au contenu déployé ne soient pas autorisées, décochez cette case.

La case à cocher Utiliser un nommage fixe et des assemblys monopage vous permet de désactiver la compilation par lots afin que chaque page soit compilée dans un assembly nommé fixe. Si cette case n’est pas cochée, vous pouvez tirer parti de la compilation par lots.

La case à cocher Activer le nommage fort sur les assemblys précompilés vous permet d’attribuer un nom fort à vos assemblys précompilés.

Notes

Dans ASP.NET 1.x, les assemblys aux noms forts devaient être installés dans le Global Assembly Cache (GAC). Dans ASP.NET 2.0, vous n’êtes pas obligé d’installer des assemblys à nom fort dans le GAC.

Figure 11 : Fichiers précompilés d’applications ASP.NET

Notes

Dans l’application ci-dessus, il n’y avait aucun fichier web.config. S’il y avait eu, il aurait été appelé PrecompiledApp.config après le processus publier le site web.

Améliorations apportées au déploiement

Comme avec Visual Studio 2002 et 2003, Visual Studio 2005 offre une fonctionnalité Copier un projet. Toutefois, la fonctionnalité a été renforcée dans Visual Studio 2005 et s’appelle désormais Copier le site web.

La boîte de dialogue Copier le site web est divisée en un cadre gauche et un cadre droit. Le cadre de gauche est appelé site web source et le cadre de droite est appelé Site web distant. Une chose qui peut confondre certains développeurs est que le site affiché dans le cadre approprié n’est pas nécessairement un site distant. Il peut s’agir d’un site sur le système de fichiers local ou sur le instance local d’IIS. En outre, le site affiché dans le cadre de gauche n’est pas nécessairement le site Web source, car la boîte de dialogue vous permet de publier à partir du site Web distant vers le site Web source.

Si vous copiez un projet sur un site Web distant, les extensions serveur FrontPage doivent être installées sur ce site. Si ce n’est pas le cas, vous devrez vous connecter à l’aide de FTP. En revanche, si vous copiez un projet dans le instance IIS local, les extensions serveur FrontPage ne sont pas nécessaires.

Notes

Si vous essayez de créer un site Web sur le instance IIS local et que les extensions serveur FrontPage 2002 sont installées, vous recevez un message d’erreur indiquant que la création de sites web n’est pas prise en charge sur un serveur SharePoint. Dans ce cas, vous avez la possibilité d’installer les extensions serveur FrontPage 2000 ou de supprimer les extensions serveur FrontPage.

Cliquez ici pour obtenir une vidéo pas à pas de la fonctionnalité Copier le site web.

Ouvrir Full-Screen vidéo

Améliorations apportées au débogage

Il existe quatre améliorations clés du débogage dans Visual Studio 2005.

• Le débogage local en tant que non-administrateur est possible dès le départ.
• L’attribut Debug de l’élément Compilation est désormais false par défaut.
• La configuration et la configuration du débogage à distance sont plus faciles qu’auparavant.
• Vous pouvez maintenant déboguer un site Web ouvert via un emplacement FTP.

Débogage en tant que non-administrateur

L’ajout du serveur de développement ASP.NET permet aux non-administrateurs de déboguer facilement ASP.NET applications dès le départ. Lorsqu’une application ASP.NET s’exécutant sur le système de fichiers local est déboguée, Visual Studio lance le serveur de développement ASP.NET dans le contexte de l’utilisateur connecté. Cet utilisateur peut ensuite déboguer cette application sans aucune configuration supplémentaire.

Déboguer a la valeur False par défaut

Dans ASP.NET 1.x, l’attribut de débogage dans l’élément de compilation du fichier web.config a été défini sur true par défaut. Il a toujours été recommandé aux développeurs de définir cet attribut sur false avant de déployer une application en production, mais comme la plupart des développeurs ne comprennent pas pleinement les conséquences de laisser l’attribut de débogage défini sur true, ils l’ont simplement laissé tel quel.

Le problème le plus grave lié à la définition de l’attribut de débogage sur true est qu’il désactive ASP. Modèle de compilation par lots NETs. Par conséquent, chaque page est compilée dans une DLL distincte. Si une application web se compose de milliers de pages (ce qui n’est pas du jamais vu), cela signifie que plusieurs milliers de petites DLL seront créées par cette application. Bien que ces DLL soient de petite taille, elles ne sont chargées dans aucun emplacement particulier dans la mémoire. Par conséquent, ils provoquent une fragmentation de la mémoire système et peuvent contribuer aux occurrences OutOfMemoryException.

Dans ASP.NET 2.0, l’attribut de débogage est défini sur false par défaut. Comme vous l’avez déjà vu, lorsqu’un développeur débogue une application ASP.NET dans Visual Studio 2005, il est invité à ajouter un fichier web.config avec le débogage activé. Cela entraîne les mêmes inconvénients que dans ASP.NET 1.x, mais le développeur est clairement averti que l’attribut doit être réinitialisé à false avant de déplacer l’application en production.

Configuration et configuration du débogage à distance

Dans Visual Studio 2002/2003, le débogage à distance s’appuyait sur le Gestionnaire de débogage de machine (mdm.exe) et le processus vs7jit.exe. Pour cette raison, la résolution des problèmes de débogage à distance était souvent une boîte noire pour les clients et ce n’était souvent pas beaucoup mieux pour PSS.

Visual Studio 2005 supprime la dépendance envers les processus mdm.exe et vs7jit.exe. Au lieu de cela, il utilise désormais le service Remote Debug Monitor (msvsmon.exe.)

La configuration requise pour le débogage à distance dans Visual Studio 2005 est assez simple. Vous devez exécuter msvsmon.exe sur le serveur distant avant le débogage. Vous pouvez installer le Moniteur de débogage distant à partir du CD Visual Studio ou simplement exécuter msvsmon.exe à partir d’un partage sans installer quoi que ce soit du tout sur le serveur web.

Lorsque vous exécutez msvsmon.exe, il est probable qu’il se plaint que les ports sont bloqués pour le débogage à distance. Heureusement, vous pouvez facilement débloquer les ports directement dans la boîte de dialogue d’avertissement, comme indiqué ci-dessous.

Figure 12 : Notification indiquant que le Pare-feu Windows bloque le débogage à distance

Une fois que vous avez débloqué les ports nécessaires pour le débogage, le Moniteur de débogage à distance s’affiche, comme indiqué ci-dessous. À partir de cette interface, vous pouvez surveiller les connexions et modifier facilement les autorisations de débogage.

Figure 13 : Moniteur de débogage à distance

Il est également possible de déboguer à distance une application web ouverte via FTP. Les étapes sont les mêmes que celles décrites précédemment. Toutefois, vous devez spécifier une URL de base pour parcourir le projet FTP, comme indiqué précédemment dans ce module.

Labo 2

Débogage à distance avec Visual Studio 2005

Ce labo vous guide tout au long du débogage à distance avec Visual Studio 2005.

Cliquez ici pour obtenir une vidéo pas à pas de ce labo.

Ouvrir Full-Screen vidéo

Ce labo nécessite que vous disposiez de deux ordinateurs, l’un exécutant Visual Studio 2005 et l’autre exécutant IIS 5 ou version ultérieure.

1. Ouvrez Visual Studio 2005 et créez un site Web sur le serveur distant.

Notes

Vous pouvez créer le site web sur un instance IIS distant ou via FTP.

1. À partir du serveur Web distant, recherchez msvsmon.exe sur l’ordinateur de développement à l’aide d’un chemin UNC et exécutez-le.
   L’emplacement par défaut pour msvsmon.exe est //server/c$/Program Files/Microsoft Visual Studio 8/Common7/IDE/Remote Debugger/x86.
2. Si vous êtes invité à débloquer des ports pour le débogage à distance, faites-le.
3. À partir de l’ordinateur de développement, ouvrez le code-behind pour Default.aspx et définissez un point d’arrêt dans la méthode Page/_Load.
4. Démarrez le débogage à partir de l’ordinateur de développement.

Vous devez atteindre le point d’arrêt comme prévu.

Lancement du serveur de développement ASP.NET

Comme nous l’avons déjà vu, Visual Studio 2005 est fourni avec un serveur web appelé serveur de développement ASP.NET. (Le serveur de développement ASP.NET est parfois appelé Cassini.) Ce serveur web est un moyen pratique de parcourir et de déboguer des applications web s’exécutant sur le système de fichiers.

Le serveur de développement ASP.NET est un serveur web restreint. Il n’autorise pas les connexions à distance, il n’autorise pas les demandes d’un utilisateur autre que l’utilisateur qui a démarré le serveur Web. Il n’a pas non plus la capacité de servir des pages ASP. Seules les ressources ASP.NET et les ressources HTML (y compris les images, les fichiers CSS, etc.) sont traitées.

Le serveur de développement ASP.NET peut être lancé via la ligne de commande en exécutant le fichier WebDev.WebServer.exe situé à l’adresse c:/Windows/Microsoft.NET/Framework/v2.0./////*. La boîte de dialogue suivante affiche les paramètres disponibles.

Figure 14

Notes

Le serveur de développement ASP.NET n’est pas pris en charge lorsqu’il est lancé explicitement via la ligne de commande.