Introduction à l'objet BuildManager

L'objet BuildManager est utilisé par les développeurs tiers pour gérer les fichiers exécutables portables (PE). Les fichiers PE sont compilés à partir d'outils personnalisés qui indiquent au système de projet que leur sortie doit être compilée dans un PE temporaire.

L'objet BuildManager et les outils personnalisés sont utilisés dans le développement des concepteurs visuels. Dans Visual Studio, un concepteur fournit une interface utilisateur graphique pour un fichier. Afin de créer l'interface utilisateur, le concepteur doit être en mesure d'instancier les types décrits dans les fichiers d'élément de projet. Les fichiers exécutables portables (PE) temporaires issus d'outils personnalisés sont des fichiers d'assembly qui encapsulent les types décrits dans des éléments de projet produits par un outil personnalisé. Par conséquent, les concepteurs et les outils personnalisés opèrent souvent ensemble pour générer l'interface utilisateur au moment de la création. L'outil personnalisé qui génère des classes à partir d'un fichier XSD en est un bon exemple. Les concepteurs visuels doivent parfois instancier les classes générées pour découvrir ce qui est mis à disposition par le biais d'un jeu de données, afin de fournir une interface utilisateur pour autoriser la prise en charge au moment du design de fonctionnalités telles que la liaison de données.

Outils personnalisés

Un outil personnalisé utilise, comme données d'entrée, le contenu d'un fichier d'élément de projet et génère un nouveau fichier d'élément de projet qui peut, ou non, être compilé par la suite. Une séquence normale d'événements se déroule comme suit :

1. L'utilisateur ou un concepteur définit la propriété CustomTool d'un élément de projet.

2. L'outil personnalisé est exécuté avec le contenu de l'élément de projet comme données d'entrée. Si l'outil personnalisé ne reconnaît pas les données d'entrée, l'utilisateur est informé des erreurs déterminées par l'outil personnalisé. Pour plus d'informations, consultez RunCustomTool.

3. Le résultat de l'outil personnalisé est compilé avec les références de projet en un exécutable portable (PE temporaire).

   Notes

   Le résultat est compilé en PE temporaire uniquement si l'outil personnalisé est inscrit avec une valeur de Registre GeneratesDesignTimeOutput de 1.

4. Il est possible d'obtenir une description du PE temporaire en appelant la méthode BuildDesignTimeOutput de l'objet BuildManager.

   La sortie PE temporaire retournée par BuildDesignTimeOutput est la suivante :

   <root>
       <Application private_binpath="full output path to temporary PE,
   excluding the name"/>
       <Assembly
           codebase = "filename of the temporary PE, e.g., sample.dll""
           name = "name of the temporary PE == filename without the 
   extension, e.g., "sample""
           version = "always "0.0.0.0""
           snapshot_id = "unique ID number" 
           replaceable = "currently unused; always set to "True""
       />
   </root>
   

BuildManager, objet

L'objet BuildManager donne accès aux PE temporaires. La propriété DesignTimeOutputMonikers consiste en un tableau de tous les monikers (noms) PE du projet. Le système de projet assigne des monikers PE en se basant sur la hiérarchie du projet. Par exemple, s'il existe un fichier de concepteur XML SomeData.xsd dans Folder1 de Project1 et qu'il génère le résultat SomeData.cs, le moniker sera : Project1\Folder1\SomeData.cs. La méthode BuildDesignTimeOutput utilise un moniker comme paramètre et retourne une description du PE dans une chaîne XML.

La suppression, dans un projet, d'un élément de projet qui génère un PE déclenche l'événement DesignTimeOutputDeleted de l'objet BuildManagerEventsClass. L'événement DesignTimeOutputDirty est déclenché à chaque exécution d'un outil personnalisé (générateur de fichier unique) générant un PE temporaire. Tous les générateurs de fichier unique d'un projet sont exécutés dans les conditions suivantes :

• Un projet est ouvert immédiatement après une mise à niveau.

• L'espace de noms racine a changé.

Les générateurs de fichier unique sont exécutés individuellement dans les conditions suivantes :

• Le document qui accompagne un générateur de fichier unique est enregistré (par exemple, un groupe de données).

• Le document qui accompagne un générateur de fichier unique est ouvert et modifié, et l'utilisateur bascule vers un document différent dans Visual Studio.

• Un fichier dans le projet accompagnant un générateur de fichier unique est renommé ou déplacé.

• L'utilisateur a renommé symboliquement un type utilisé dans le fichier de sortie d'un générateur de fichier unique. Par exemple, si l'utilisateur appelle un changement de nom symbolique sur le type 'Type' et que l'ID de ce type est utilisé dans dataset1.vb (sortie d'un groupe de données), le générateur de fichier unique est appelé une fois le changement de nom terminé.

Cliquez sur le lien dans le tableau suivant pour voir comment programmer l'utilisation de l'objet BuildManager.

Fournisseurs tiers

Beaucoup des fonctionnalités de l'objet BuildManager sont également accessibles par le biais de l'interface ITypeResolutionService. Toutefois, les fournisseurs tiers qui souhaitent disposer d'un concepteur doté de toutes les fonctionnalités doivent utiliser la propriété DesignTimeOutputMonikers et la méthode BuildDesignTimeOutput. Pour plus d'informations, consultez Diversité de l'automation Visual Studio.