Problème à signaler:


Télécharger Cours Visual Studio .NET 2003 et VBCommenter en pdf



★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :

Cours Visual Studio .NET 2003 et VBCommenter en pdf




Cours Visual Studio .NET et VBCommenter [Eng]

...

Chapitre 1: Principes de base

J'ai passé beaucoup de temps à préparer un livre sur l'extensibilité de Visual Studio, en me concentrant sur le développement de paquets Visual Studio. J'ai fait des propositions pour plusieurs éditeurs de livres, mais je n'ai pas réussi à obtenir un contrat, la plupart d'entre eux ont trouvé un tel livre n'est pas rentable. J'ai décidé de partager les quatre chapitres du livre que j'ai déjà écrit. Ce sont les suivants:

 ¢ â,¬Â ¢ Chapitre 1: Paquets Visual Studio

 ¢ â,¬Â ¢ Chapitre 2: Commandes, menus et barres d'outils

 ¢ â,¬Â ¢ Chapitre 3: Fenêtres de gestion et d'outils

 ¢ â,¬Â ¢ Chapitre 4: Services

J'espère que vous trouverez ces chapitres utiles.

La plupart des fonctions de Visual Studio que vous utilisez dans votre travail quotidien (tels que les langages de programmation, les éditeurs, les concepteurs et les débogueurs) sont fournies par Visual Studio Integration Packages, ou bientôt par des packages. Certains les appellent des paquets VSIP mais l'acronyme VSIP est surchargé: alors que les deux premières lettres signifient "Visual Studio", les deux dernières peuvent signifier soit "Package Intégration" ou "Industry Partner" et malheureusement les deux termes sont fréquemment utilisés. Pour éviter toute ambiguïté, vous rencontrerez le terme package ou VSPackage.

Le développement de packages signifie que vous pouvez étendre Visual Studio de la même manière que son équipe de développeurs chez Microsoft. L'ajout de nouvelles fonctions via les packages est en fait la programmation d'une nouvelle partie de Visual Studio, comme si vous étiez le membre de l'équipe. Vous pouvez utiliser la pleine puissance et intégrer toutes les fonctionnalités que vous manquez de l'IDE!

Dans ce chapitre, vous allez créer un package très simple appelé FirstLook pour avoir l'impression que les premières étapes sont faciles. Ensuite, vous apprendrez les concepts de base des paquets et vous plongerez dans la structure et le code source du projet FirstLook pour voir de plus près l'implémentation de ces concepts. A la fin de ce chapitre, vous serez familiarisé avec ce qui suit:

à ¢ â,¬Â ¢ Construire un paquet avec l'assistant VSPackage

à ¢ â,¬Â ¢ L'idée d'un paquet

 € ¢ Le mà © canisme de chargement de paquets sur demande et l'idà © e de l'emplacement des paquets

à ¢ â € ¢ Enregistrement des paquets et des informations stockées dans le registre

 € ¢ The Visual Studio Experimental Hive et l'utiliser pour déboguer des paquets

 € ¢ Le processus de construction du paquet

 € ¢ Déploiement de VSPackages

Ce chapitre ne vous apprendra pas à créer une fonctionnalité spécifique dans un package et ne couvre pas l'API utilisée pour développer des packages. L'accent est mis sur la compréhension des concepts, les considérations architecturales derrière VSPackages pour vous permettre de jeter un oeil dans les coulisses et se familiariser avec les mécanismes de package. Ces concepts seront très utiles lorsque vous proposerez de créer vos propres paquets.

Construire un paquet simple

Il y a quelques concepts importants à comprendre si vous voulez développer un paquet. Pour les traiter dans le bon contexte, vous construisez un package fonctionnel très simple pour toucher la surface de ces concepts et ensuite sauter dans les détails.

Un package Visual Studio est une bibliothèque de classes contenant les types responsables de l'infrastructure et des fonctionnalités du package. Pour que Visual Studio reconnaisse la bibliothèque de classes compilée en tant que package, les types encapsulés doivent avoir des informations de métadonnées spécifiques et certaines étapes supplémentaires sont requises après la compilation. Ainsi, même si vous pouviez commencer à créer un paquet à partir d'une bibliothèque de classes vide, il est beaucoup plus facile d'utiliser l'assistant VSPackage installé avec Visual Studio SDK.



Démarrer un nouveau projet avec la commande Fichier | Nouveau | Projet. L'EDI affiche la boîte de dialogue Nouveau fichier pour sélectionner le type de projet souhaité. Vous pouvez trouver le type de projet Visual Studio Integration Package sous la catégorie Autres types de projets dans le dossier Extensibility comme illustré à la figure 1.

 Figure 1: La boîte de dialogue Nouveau projet avec les types de projet Extensibilité

Si vous ne trouvez pas ce type de projet ou de nombreux autres types de projets dans le dossier Extensibilité signifie que Visual Studio SDK n'est pas installé correctement sur votre machine. Installez-le en fonction des notes de configuration afin de continuer à construire le paquet.

Attribuez le nom FirstLook au package afin de pouvoir suivre les détails du code plus loin dans ce chapitre. Cliquez sur le bouton OK pour lancer l'assistant du package d'intégration Visual Studio (l'assistant VSPackage Wizard est désormais utilisé, il est plus court) qui vous accueille avec la boîte de dialogue de la figure 2.

Figure 2: La page d'accueil de l'assistant VSPackage

Cliquez sur le bouton Suivant pour continuer à spécifier les paramètres du paquet et vous arrivez à la page Sélectionner un langage de programmation de l'assistant comme le montre la figure 3.

Figure 3: Assistant VSPackage vous permet de sélectionner le langage de programmation

Comme mentionné précédemment, vous créez le code en C #. Les packages sont des assemblys fortement nommés, vous devez donc signer l'assembly de bibliothèque de classes avec une clé. Pour ce projet, l'assistant crée la clé de signature. Cliquez sur Next et vous arrivez à la page Basic VSPackage Information comme le montre la figure 4.

 Figure 4: L'assistant vous demande les informations de base du package

Les informations que vous fournissez ici seront utilisées dans le code source généré pour le package et seront affichées dans la boîte de dialogue À propos de Visual Studio. Le nom de la société sera utilisé dans l'espace de noms des types générés ainsi que dans le nom VSPackage qui nomme également la classe représentant le paquet dans le code. La version de VSPackage est une information supplémentaire permettant de distinguer les versions de paquetages distinctes.

Le texte tapé dans le champ Informations détaillées s'affiche dans la boîte de dialogue A propos de et peut fournir à l'utilisateur plus d'informations sur ce que fait le package.

Lorsque vous cliquez sur le bouton Suivant, l'assistant vous amène à la page Options VSPackage - comme le montre la figure 5 - pour définir quelques options supplémentaires de génération de code.

Figure 5: Vous pouvez sélectionner quelques options de génération de code

Dans cet exemple, vous allez créer uniquement une commande de menu qui affiche un message à l'écran, définissez l'option Commande de menu. Si vous sélectionnez les deux autres options, l'assistant VSPackage créera plus de code pour une fenêtre d'outil simple ou un éditeur de texte enrichi. S'il vous plaît, laissez ces options non cochées. Avec le bouton Suivant, l'assistant va à la page où nous pouvons spécifier quelques détails sur la commande de menu à créer. Cette page est illustrée à la figure 6.

 Figure 6: Les options de commande sont spécifiées ici

La commande sera ajoutée au menu Outils de Visual Studio, dans Nom de la commande, vous pouvez spécifier le texte à afficher pour l'élément de menu. Selon l'architecture de gestion des commandes internes, chaque commande a un identifiant. Le champ ID de commande fournit un nom pour cet identifiant et l'assistant VSPackage va générer une valeur d'ID derrière ce nom. En cliquant sur Suivant, l'assistant passe à la page Options du projet de test, comme illustré à la Figure 7.

 Figure 7: L'assistant VSPackage demande des options de projet de test

L'assistant peut créer un test unitaire pour le paquet qui vérifie si ses unités fonctionnelles fonctionnent correctement. L'assistant peut également créer pour vous un projet de test d'intégration dans lequel les packages sont testés dans le contexte d'une instance Visual Studio.



Par souci de simplicité ici, vous ne créez pas de tests, alors effacez les options par défaut, les deux sont vérifiés. Maintenant que vous avez défini tous les paramètres que l'assistant utilise pour générer le projet de package, cliquez sur le bouton Terminer.

En quelques secondes, l'assistant génère le projet de package prêt à être généré et exécuté. Goûtez le pudding que vous venez de cuisiner! Avec la fonction Build ƒ ° Rebuild Solution, vous pouvez compiler le package et effectuer toutes les autres étapes requises pour exécuter le package avec Visual Studio. Donc reconstruisez le projet et commencez par Ctrl + F5 (Debug | Start Without Debugging).

Vous pourriez être surpris comme une nouvelle instance de Visual Studio est démarré avec «Instance expérimentale» dans sa légende de la fenêtre.

Remarque: Si c'est la première fois que vous avez démarré l'instance expérimentale, la boîte de dialogue Choisir les paramètres d'environnement par défaut s'affiche exactement comme lorsque vous lancez Visual Studio après l'installation.

Il s'agit d'une instance de Visual Studio qui héberge le package FirstLook. Vous apprendrez plus tard le concept sous-jacent. La commande de menu implémentée par ce paquet fraîchement généré peut être vue dans le menu Outils comme le montre la figure 8.

Figure 8: L'élément de commande de menu apparaît dans le menu Outils

Lorsque vous cliquez sur la commande Message simple, il affiche une boîte de message vous indiquant qu'il a été affiché à partir du package FirstLook.

Le paquet a également enregistré des informations de marque qui peuvent être vues dans la boîte de dialogue Aide | À propos de, comme le montre la figure 9.

Figure 9: Informations de marque du package FirstLook

Rien d'appel en dit plus sur votre VSPackage que sur son code source. Mais avant de plonger dedans, nous allons traiter des concepts importants sur les paquets.

Concepts derrière les packages Visual Studio

Un VSPackage est l'unité architecturale principale de Visual Studio. Comme vous le savez déjà, Visual Studio IDE lui-même est le Shell hébergeant un ensemble de VSPackages travaillant ensemble et avec le Shell. La responsabilité de base d'un paquet est de fournir un conteneur commun pour les objets d'extensibilité. Ainsi, un VSPackage est un module logiciel qui est une unité non seulement du point de vue de l'architecture mais aussi des aspects de déploiement, de sécurité et de licence.

Les développeurs - y compris les développeurs de Visual Studio - créent des VSPackages pour fournir une extension à l'IDE VS et les regrouper en modules en fonction de leurs fonctionnalités. Ces extensions peuvent être:

 € ¢ Services. Ce sont des objets logiciels qui offrent des fonctionnalités pour d'autres objets dans le même paquet ou même pour d'autres paquets. Par exemple, le service de langage C # (comme son nom l'indique également) est un service.

 € ¢ Eléments d'interface utilisateur. Les menus, les barres d'outils et les fenêtres peuvent être utilisés par les développeurs pour initier des actions dans l'interface utilisateur, interagir avec, afficher des messages, des informations et des figures, etc.

à ¢ â,¬Â ¢ Éditeurs. Pendant le développement, vous écrivez et modifiez le texte du programme pour créer des applications. Cette tâche est la responsabilité d'un éditeur. Visual Studio 2010 possède son propre éditeur de texte principal et vous pouvez l'étendre ou même créer vos propres éditeurs.

 € ¢ Designers. La création d'applications n'est pas simplement une activité de saisie de texte. Il existe de nombreux outils visuels connus sous le nom de concepteurs qui permettent une représentation alternative et la conception de modules, de composants, de pièces ou même d'applications complètes. Des exemples bien connus sont le concepteur Windows Forms, le concepteur WPF Forms, le concepteur de page ASP.NET ou le concepteur de table de données.

 € ¢ Projets. Lors du développement d'applications, vous travaillez généralement avec un grand nombre de fichiers. Un projet est une organisation de fichiers source et de ressources. Un projet non seulement stocke simplement ces fichiers, mais définit également les opérations avec eux, permet de construire, de déboguer et de déployer les produits créés à partir de fichiers source.



Il est naturel dans .NET que vous puissiez diviser vos unités fonctionnelles en assemblages distincts où les assemblages de consommateurs référenceront d'autres assemblys de service. Le même principe fonctionne pour VSPackages: un assembly contenant un package peut faire référence à d'autres assemblys qui peuvent contenir non seulement des types d'assistance, mais même des types d'objets d'extensibilité.

Un assembly - la plus petite unité de déploiement physique dans .NET - peut contenir plus d'un VSPackage. Bien que généralement un seul package soit encapsulé dans un assembly, vous pouvez avoir plusieurs raisons de regrouper plus de packages dans un assembly, y compris des considérations de déploiement.

La clé de chargement du package

Les versions précédentes de Visual Studio vérifiaient le package avant de les charger dans l'espace de processus du Shell. Tout VSPackage aurait dû être "scellé" avec ce qu'on appelle une clé de chargement de paquet (PLK) et cette clé a été vérifiée pendant le chargement du paquet. PLK n'était pas une signature numérique ou un hachage complet, car il a été calculé à partir de quelques champs d'information dans le paquet. PLK a pu être demandé à Microsoft via une page Web: le développeur a spécifié quelques attributs bien définis du package et une logique a calculé la valeur PLK. Cette valeur a été incorporée en tant que ressource dans l'assembly représentant le package.

Chaque fois que le paquet a été chargé, l'interpréteur de commandes a vérifié le PLK par rapport aux attributs du paquet à partir desquels il avait été créé. Si cette vérification échouait, le Shell aurait refusé de charger le paquet. Ce mécanisme PLK ne signifiait pas qu'un développeur devait demander un nouveau PLK pour chaque modification de paquet. Bien qu'aucune information de base à partir de laquelle le PLK a été généré n'ait été modifiée, le paquet a continué à charger.

Bien que ce concept ait semblé utile, dans la vie réelle n'avait aucun avantage réel. Pour être honnête, dans la plupart des cas, c'était la cause première des problèmes de déploiement, dans de nombreux cas, cela posait plus de problèmes qu'il n'en résolvait.

Dans le nouveau Visual Studio 2010, le shell n'utilise pas la clé de chargement de package pour vérifier les packages avant de les charger dans la mémoire.

Chargement à la demande des colis

Vous pouvez imaginer que des paquets complexes comme les langages C #, VB, F # ou C ++ avec tous leurs "accessoires" peuvent consommer de nombreuses ressources système en termes de mémoire et de CPU. Si vous ne les utilisez pas, ils n'appuient pas sur le processeur, mais ils peuvent utiliser la mémoire s'ils se trouvent dans l'espace de processus Visual Studio. Si vous créez un projet en utilisant F #, vous n'avez pas besoin de services appartenant à d'autres langues, alors pourquoi les charger dans la mémoire?

Les architectes de Visual Studio ont implémenté le mécanisme de chargement de paquets de sorte que les paquets soient chargés dans la mémoire lors de la première ouverture d'un événement nécessitant la présence du paquet. Ces événements peuvent être l'un des suivants:

 € ¢ Activation de la commande. L'utilisateur (ou un code en cours d'exécution) active une commande de menu ou de barre d'outils (ou même une commande inaccessible depuis l'interface utilisateur) desservie par un paquet qui n'a pas encore été chargé. Peu importe si l'utilisateur a cliqué sur un élément de menu ou le code de fonctionnement l'a activé avec un «clic virtuel», le résultat est le même.

 € ¢ Objet ou demande de service. Le shell est sur le point d'utiliser un objet ou un service dans un paquet non encore chargé. Par exemple, une fenêtre d'outil doit être affichée ou une fonction de service est sur le point d'être exécutée.

  • Changement de contexte. Le shell peut entrer dans certains contextes d'interface utilisateur. Par exemple, lorsque vous démarrez le débogage d'un projet, le shell entre dans le contexte de débogage. Lorsqu'une solution avec un seul projet est chargée, l'environnement Shell entre dans le contexte SolutionHasSingleProject. Vous pouvez déclarer qu'un paquet doit être chargé lorsque le shell entre dans un certain contexte. Visual Studio possède quelques contextes prédéfinis, mais vous pouvez également définir les vôtres.

Donc, si vous n'avez pas besoin d'un paquet pendant toute la session IDE, il ne consomme pas du tout la mémoire. Si vous cliquez sur un élément de menu activant une commande dans un paquet qui n'a pas encore été chargé, l'EDI va immédiatement le charger et l'initialiser. Si vous demandez une fenêtre d'outil dans un paquet qui n'est pas encore dans la mémoire, l'EDI commencera à le charger.



Le chargement du package de liaison avec un changement de contexte est généralement requis lorsque votre package souhaite s'abonner à des événements déclenchés dans Visual Studio. Vous ne pouvez pas lier l'événement pour commander l'activation ou les demandes d'objet ou de service, car pour que votre package fonctionne, vous devez vous abonner aux événements. Le code pour créer des abonnements est généralement placé dans le code d'initialisation. Mais vous ne pouvez pas exécuter de code appartenant à un paquet tant qu'il n'est pas chargé dans la mémoire! Dans ce cas, vous déclarez le meilleur contexte (le dernier possible) pour charger le paquet. Si votre logique de package l'exige, vous pouvez spécifier le contexte NoSolutionExists. Visual Studio entre dans ce contexte immédiatement lorsque le shell est chargé et prêt à fonctionner, de sorte que les packages liés à ce contexte sont chargés au démarrage de Visual Studio.

Remarque: Soyez frugal avec les ressources système si vous devez charger un package au démarrage de Visual Studio. N'allouez que les ressources indispensables pour effectuer l'initialisation requise au démarrage.

Emplacement de l'emballage

Lorsque vous développez un package, il s'agit d'un morceau de code indépendant. Quand il est chargé dans Visual Studio, il devient une partie organique de l'IDE:

Votre paquet peut accéder aux services et aux objets fournis par Shell et d'autres paquets.

  • Le Shell et les autres paquets peuvent accéder aux objets et aux services que vous leur proposez.

Le processus de création physique d'un package dans Shell est appelé implantation. Bien que le paquet ne soit pas situé, ses fonctions ne peuvent pas être utilisées de l'extérieur. Pour la même raison, le paquet ne peut être initialisé que partiellement, car il ne peut toucher aucun objet ou service via Shell. Dès que le paquet est localisé, il est prêt à terminer son initialisation et à être pleinement fonctionnel. L'emplacement se produit lorsque Visual Studio charge le package.

Le type d'objet représentant votre paquet doit implémenter une interface appelée IVsPackage (vous allez apprendre les détails plus loin dans ce chapitre) et doit avoir un constructeur par défaut.

Le chargement d'un paquet contient les étapes suivantes:

  • Le shell crée une instance du type d'objet représentant votre paquet en invoquant son constructeur par défaut.
  • Le Shell appelle la méthode SetSite de l'instance d'objet. IVsPackage définit cette méthode et transmet une instance de fournisseur de services qui peut être utilisée par le serveur. package pour interroger des objets afin d'accéder aux services implémentés par le Shell ou d'autres packages.
  • Le Shell permet à votre paquet de terminer son initialisation. Lors de la première étape de l'appel de construction, l'objet de service n'a eu aucun contact avec le Shell. Après le placement de toutes les étapes d'initialisation, l'appel des services Shell peut être effectué.

Bien que l'intégration physique de votre package dans Visual Studio soit fonctionnelle, l'intégration fonctionnelle peut nécessiter des étapes supplémentaires, parfois complexes, en fonction de l'objectif de votre package.

Enregistrement de paquet

Visual Studio doit garder une trace des paquets afin de les charger et de les utiliser. Bien sûr, le plus flexible serait une sorte de découverte où le Shell ne peut regarder que dans le système de fichiers pour deviner quelles entités représentent des paquets. Le framework .NET prend en charge et utilise intensivement les métadonnées (attributs) qui peuvent représenter les informations que vous pouvez utiliser à cette fin. Vous pouvez même charger un assemblage de sorte que seule la partie des métadonnées soit lue dans le système de fichiers et mise en mémoire. Bien que vous puissiez imaginer que ce mécanisme puisse fonctionner, il n'est pas utilisé par Shell de cette manière.

La raison en est que les racines de Visual Studio remontent à l'ère COM. Les packages sont des objets COM et peuvent être créés non seulement en code managé, mais aussi en code natif en utilisant l'API Win32 avec n'importe quel langage, y compris C ++, Delphi et autres. Donc, sans surprise, Visual Studio utilise le registre pour conserver des informations sur les paquets.



Bien que le registre soit utilisé pour stocker des informations de configuration sur les paramètres de Visual Studio, les développeurs et les utilisateurs de package ne sont pas dérangés par les problèmes d'enregistrement. Le nouveau mécanisme de déploiement (via les fichiers VSIX) implémenté dans Visual Studio 2010 supprime cette tâche. Lorsque Visual Studio est démarré, son mécanisme de découverte collecte les informations à entrer dans le Registre et effectue tout le processus d'enregistrement à la volée. Les développeurs perçoivent qu'ils ne font l'installation qu'en copiant des fichiers et cela ressemble au grand mécanisme que nous utilisons avec le .NET Framework.



361