Écrire du code dans des solutions Bureau

Certains aspects de l'écriture de code dans les projets Office diffèrent des autres types de projets dans Visual Studio. La plupart de ces différences sont liées à la façon dont les modèles objet Office sont exposés au code managé. Les autres différences portent sur la conception des projets Office.

S’applique à : les informations contenues dans cette rubrique s’appliquent aux projets au niveau du document et aux projets de complément VSTO. Consultez les fonctionnalités disponibles par application Office lication et le type de projet.

Code managé et programmation Bureau

Automation est la technologie clé qui permet de créer une solution Microsoft Office intégrée. Elle fait partie de la technologie COM (Component Object Model). Automation rend possible l'utilisation de code pour créer et contrôler les objets logiciel qui sont exposés par une application, une DLL ou un contrôle ActiveX prenant en charge les interfaces de programmation appropriées.

Comprendre les assemblys d’interopérabilité principaux

Les applications Microsoft Office exposent une grande part de leurs fonctionnalités à Automation. Toutefois, vous ne pouvez pas utiliser du code managé (notamment Visual Basic ou C#) directement pour automatiser des applications Office. Pour automatiser des applications Office avec du code managé, vous devez utiliser les assemblys PIA (Primary Interop Assembly) d'Office. Ces assemblys permettent au code managé d'interagir avec le modèle objet COM des applications Office.

Chaque application Microsoft Office possède un assembly PIA. Quand vous créez un projet Office dans Visual Studio, une référence au PIA approprié est automatiquement ajoutée au projet. Pour automatiser les fonctionnalités d'autres applications Office à partir du projet, vous devez ajouter cette référence manuellement. Pour plus d’informations, consultez Guide pratique pour cibler des application Office lications via des assemblys d’interopérabilité principaux.

Utiliser des assemblys d’interopérabilité principaux au moment du design et au moment de l’exécution

Pour que vous puissiez effectuer la plupart des tâches de développement, les assemblys PIA d'Office doivent être installés et inscrits dans le Global Assembly Cache de votre ordinateur de développement. Pour plus d’informations, consultez Configurer un ordinateur pour développer des solutions Bureau.

Les Bureau les adresses PERSONNELLEs ne sont pas requises sur les ordinateurs des utilisateurs finaux pour exécuter des solutions Bureau qui ciblent le .NET Framework 4 ou une version ultérieure. Pour plus d’informations, consultez Conception et création de solutions Bureau.

Utiliser des types dans les assemblys d’interopérabilité principaux

Les assemblys PIA d'Office fournissent une combinaison de types qui exposent le modèle objet des applications Office et d'autres types d'infrastructure qui ne sont pas prévus pour être utilisés directement dans votre code. Pour obtenir une vue d’ensemble des types de l’Bureau des informations d’identification personnelle, consultez Vue d’ensemble des classes et des interfaces dans les assemblys d’interopérabilité principaux Bureau.

Étant donné que les types des assemblys PIA d'Office correspondent aux types des modèles objet COM, la façon dont vous utilisez ces types diffère souvent des autres types managés. Par exemple, le mode d'appel des méthodes possédant des paramètres optionnels dans un assembly PIA d'Office dépend du langage de programmation utilisé dans le projet. Pour plus d’informations, voir les rubriques suivantes :

Modèle de programme de projets Bureau

Tous les projets Office incluent une ou plusieurs classes générées qui fournissent le point d'entrée de votre code. Ces classes fournissent également l'accès au modèle objet de l'application hôte, ainsi qu'aux fonctionnalités telles que les volets Actions et les volets de tâches personnalisés.

Comprendre les classes générées

Dans les projets de niveau document pour Excel et Word, la classe générée ressemble à un objet de niveau supérieur du modèle objet de l'application. Par exemple, la classe ThisDocument générée d'un projet de document Word fournit les mêmes membres que la classe Document du modèle objet Word. Pour plus d’informations sur les classes générées dans les projets au niveau du document, consultez Les personnalisations au niveau du document du programme.

Les projets de complément VSTO fournissent une classe générée nommée ThisAddIn. Cette classe ne ressemble pas à une classe du modèle objet de l'application hôte. Au lieu de cela, cette classe représente le complément VSTO lui-même et fournit aux membres que vous pouvez utiliser pour accéder au modèle objet de l’application hôte et accéder à d’autres fonctionnalités disponibles pour les compléments VSTO. Pour plus d’informations, consultez Les compléments VSTO program.

Toutes les classes générées dans les projets Office incluent des gestionnaires d'événements Startup et Shutdown . Pour commencer à écrire du code, vous ajoutez généralement ce code à ces gestionnaires d'événements. Pour initialiser votre complément VSTO, vous pouvez ajouter du code au gestionnaire d’événements Startup . Pour nettoyer les ressources utilisées par votre complément VSTO, vous pouvez ajouter du code au gestionnaire d’événements Shutdown . Pour plus d’informations, consultez Événements dans Bureau projets.

Accéder aux classes générées au moment de l’exécution

Lorsqu’une solution Bureau est chargée, le runtime Visual Studio Tools pour Office instancie chacune des classes générées dans votre projet. Vous pouvez accéder à ces objets directement du code de votre projet à l'aide de la classe Globals . Par exemple, vous pouvez utiliser la classe pour appeler du Globals code dans la ThisAddIn classe à partir d’un gestionnaire d’événements d’un bouton Ruban dans un complément VSTO.

Pour plus d’informations, consultez Accès global aux objets dans Bureau projets.

Considérations relatives à l’espace de noms dans les solutions Bureau

Vous ne pouvez pas modifier l' espace de noms par défaut (ou l' espace de noms racine dans Visual Basic) dans un projet Office existant. L'espace de noms par défaut correspondra toujours au nom du projet que vous avez spécifié lors de sa création. Si vous renommez votre projet, l'espace de noms par défaut ne change pas. Pour plus d’informations sur l’espace de noms par défaut dans les projets, consultez Page Application, Concepteur de projets (C#) et Page Application, Concepteur de projets (Visual Basic).

Modifier l’espace de noms des classes d’éléments hôtes dans les projets C#

Les classes d'élément hôte (par exemple, ThisAddIn, ThisWorkbooket ThisDocument ) ont leurs propres espaces de noms dans les projets Office Visual C#. Par défaut, l'espace de noms des éléments hôtes dans votre projet correspond au nom de projet que vous avez spécifié lors de la création de ce dernier.

Pour modifier l'espace de noms des éléments hôtes dans un projet Office Visual C#, utilisez la propriété Espace de noms de l'élément hôte . Pour plus d’informations, consultez Propriétés dans Bureau projets.

Langages de programmation pris en charge dans les projets Bureau

Les modèles de projet Office dans Visual Studio prennent uniquement en charge les langages de programmation Visual Basic et Visual C#. Par conséquent, ces modèles de projet sont disponibles uniquement sous les nœuds Visual Basic et Visual C# de la boîte de dialogue Nouveau projet dans Visual Studio. Pour plus d’informations, consultez Guide pratique pour créer des projets Bureau dans Visual Studio.

Choix du langage et programmation Bureau

Microsoft Office et Visual Basic pour Applications (VBA) ont été développés pour fonctionner ensemble afin d'optimiser le workflow de la personnalisation d'application. Visual Basic a hérité certains de ces développements, comme la prise en charge des paramètres optionnels. L'utilisation de ces paramètres vous permet d'appeler certaines méthodes dans les assemblys PIA (Primary Interop Assembly) de Microsoft Office en ayant moins de code à écrire qu'avec Visual C#.

Program with Visual Basic vs. Visual C# in Bureau solutions

Vous pouvez créer des solutions Office à l'aide de Visual Basic ou Visual C#. Étant donné que les modèles objet de Microsoft Office ont été conçus pour être utilisés avec Microsoft Visual Basic pour Applications (VBA), les développeurs en Visual Basic peuvent facilement travailler avec les objets exposés par les applications Microsoft Office. Les développeurs en Visual C# peuvent utiliser la plupart des fonctionnalités disponibles pour les développeurs en Visual Basic, sauf dans certains cas où ils doivent écrire du code supplémentaire pour pouvoir utiliser les modèles objet d'Office. Il existe également quelques différences entre les fonctionnalités de programmation de base dans le développement Office et le code managé écrit en Visual Basic et Visual C#.

Principales différences entre Visual Basic et Visual C#

Le tableau suivant indique les principales différences entre Visual Basic et Visual C# dans le développement Office.

Fonctionnalité Description Prise en charge dans Visual Basic Prise en charge dans Visual C#
Paramètres facultatifs De nombreuses méthodes Microsoft Office possèdent des paramètres qui ne sont pas obligatoires quand vous les appelez. Si aucune valeur n'est passée comme paramètre, une valeur par défaut est utilisée. Visual Basic prend en charge les paramètres optionnels. Visual C# prend en charge les paramètres optionnels dans la plupart des cas. Pour plus d’informations, consultez Paramètres facultatifs dans Bureau solutions.
Passage de paramètres par référence Dans la plupart des assemblys PIA (Primary Interop Assembly) de Microsoft Office, les paramètres optionnels peuvent être passés par valeur. Toutefois, dans certains assemblys PIA, les paramètres optionnels qui acceptent les types référence doivent être passés par référence.

Pour plus d’informations sur les paramètres de type valeur et référence, consultez Les arguments Pass par valeur et par référence (Visual Basic) (pour Visual Basic) et Les paramètres Pass (Guide de programmation C#).
Le passage des paramètres par référence est possible sans codage supplémentaire. Le compilateur Visual Basic passe automatiquement les paramètres par référence nécessaires. Le plus souvent, le compilateur Visual C# passe automatiquement les paramètres par référence nécessaires. Pour plus d’informations, consultez Paramètres facultatifs dans Bureau solutions.
Propriétés paramétrables Certaines propriétés acceptent des paramètres et agissent comme des fonctions en lecture seule. Visual Basic prend en charge les propriétés qui acceptent des paramètres. Visual C# prend en charge les propriétés qui acceptent des paramètres.
Liaison tardive La liaison tardive implique de déterminer les propriétés d'objets au moment de l'exécution, au lieu d'effectuer un cast de variables en type d'objet au moment du design. Visual Basic effectue la liaison tardive quand Option Strict est désactivé. Si Option Strict est activé, vous devez convertir explicitement les objets et utiliser les types figurant dans l'espace de noms System.Reflection pour accéder aux membres à liaison tardive. Pour plus d’informations, consultez Liaison tardive dans les solutions Bureau. Visual C# effectue une liaison tardive dans les projets qui ciblent .NET Framework 4. Pour plus d’informations, consultez Liaison tardive dans les solutions Bureau.

Principales différences entre le développement Bureau et le code managé

Le tableau suivant indique les principales différences entre le développement Office et le code managé écrit en Visual Basic ou Visual C#.

Fonctionnalité Description Prise en charge dans Visual Basic et Visual C#
Index de tableau La limite de tableau inférieure de collections dans les applications Microsoft Office commencent par 1. Visual Basic et Visual C# utilisent des tableaux basés sur 0. Pour plus d’informations, consultez tableau (guide de programmation C#) et Tableaux en Visual Basic. Pour accéder au premier élément d'une collection dans le modèle objet d'une application Microsoft Office, utilisez l'index 1 au lieu de 0.