Écriture de code dans les solutions Office

Article
03/22/2013

Certains aspects de l'écriture de code dans des projets Office diffèrent des autres types de projets dans Visual Studio.Une grande partie 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 sont liées la conception des projets Office.

S'applique à : Les informations contenues dans cette rubrique s'appliquent aux projets de niveau document et de niveau application pour Office 2013 et Office 2010. Pour en savoir plus, consultez Fonctionnalités disponibles par type d'application et de projet Office.

Code managé et programmation Office

La technologie clé qui permet de créer une solution Microsoft Office intégrée est Automation ; elle fait partie de la technologie COM (Component Object Model).L'automation vous permet d'utiliser du code pour créer et contrôler les objets logiciels exposés par une application, une DLL ou un contrôle ActiveX prenant en charge les interfaces de programmation appropriées.

Fonctionnement des assemblys PIA (Primary Interop Assembly)

Les applications Microsoft Office exposent une grande part de leurs fonctionnalités à Automation.Toutefois, vous ne pouvez pas utiliser de code managé (tel que Visual Basic ou C#) directement pour automatiser des applications Office.Pour automatiser des applications Office à l'aide de 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.Lorsque 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 une référence à l'assembly PIA approprié manuellement.Pour plus d'informations, consultez Comment : cibler les applications Office via les assemblys PIA (Primary Interop Assembly).

Utilisation d'assemblys PIA (Primary Interop Assembly) 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 Configuration d'un ordinateur pour développer des solutions Office.

Les assemblys PIA d'Office ne sont pas requis sur les ordinateurs des utilisateurs finaux pour l'exécution des solutions Office qui ciblent .NET Framework 4 ou .NET Framework 4.5.Pour plus d'informations, consultez Conception et création de solutions Office.

Utilisation de types dans les assemblys PIA (Primary Interop Assembly)

Les assemblys PIA Office contiennent 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 une vue d'ensemble des types des assemblys PIA Office, consultez Overview of Classes and Interfaces in the Office Primary Interop Assemblies.

É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, la façon dont vous appelez les méthodes possédant des paramètres optionnels dans un assembly PIA (Primary Interop Assembly) d'Office dépend du langage de programmation utilisé dans le projet.Pour plus d'informations, consultez les rubriques suivantes :

Modèle de programmation des projets Office

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.

Fonctionnement des 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 générée ThisDocument d'un projet de document Word fournit les mêmes membres que la classe Microsoft.Office.Interop.Word.Document du modèle objet Word.Pour plus d'informations sur les classes générées dans les projets de niveau document, consultez Programmation de personnalisations au niveau du document.

Les projets de niveau application fournissent une classe générée intitulée ThisAddIn.Cette classe ne ressemble pas à une classe du modèle objet de l'application hôte.Elle représente plutôt le complément lui-même et fournit des membres que vous pouvez utiliser pour accéder au modèle objet de l'application hôte et aux autres fonctionnalités disponibles aux compléments.Pour plus d'informations, consultez Programmation de compléments d'application.

Toutes les classes générées des 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, vous pouvez ajouter du code au gestionnaire d'événements Startup.Pour nettoyer les ressources utilisées par votre complément, vous pouvez ajouter du code au gestionnaire d'événements Shutdown.Pour plus d'informations, consultez Événements dans les projets Office.

Accès aux classes générées au moment de l'exécution

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

Pour plus d'informations, consultez Accès global aux objets dans les projets Office.

Considérations de l'espace de noms dans les solutions Office

Vous ne pouvez pas modifier l'espace de noms par défaut (ou espace de noms racine (en Visual Basic) d'un projet Office après sa création.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 changera pas.Pour plus d'informations sur l'espace de noms par défaut, consultez Page Application, Concepteur de projets (C#) et Application, page du Concepteur de projets (Visual Basic).

Modification de l'espace de noms des classes d'élément hôte dans les projets C#

Les classes d'élément hôte (par exemple ThisAddIn, ThisWorkbook ou 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 les projets Office.

Langages de programmation pris en charge dans les projets Office

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 ne sont disponibles que dans les nœuds Visual Basic et Visual C# de la boîte de dialogue Nouveau projet dans Visual Studio.Pour plus d'informations, consultez Comment : créer des projets Office dans Visual Studio.

Choix de langage et programmation Office

Microsoft Office et Visual Basic pour Applications (VBA) ont été développés pour travailler ensemble afin d'optimiser le workflow de personnalisation d'application.Visual Basic a hérité de certains de ces développementset prend en charge des paramètres optionnels, par exemple. Ainsi, lorsque vous appelez certaines méthodes dans les assemblys PIA (Primary Interop Assembly) de Microsoft Office, vous pouvez écrire moins de code que lorsque vous utilisez Visual C#.

Programmation avec Visual Basic VS. Visual C# dans les solutions Office

Vous pouvez créer des solutions Office à l'aide de Visual Basic ou Visual C#.Étant donné que les modèles objets Microsoft Office ont été conçus pour être utilisés avec Microsoft Visual Basic pour Applications (VBA), les développeurs Visual Basic peuvent facilement travailler avec les objets exposés par les applications Microsoft Office.Dans Visual Studio 2012, les développeurs Visual C# peuvent utiliser la plupart des fonctionnalités utilisées par les développeurs Visual Basic, mais dans certains cas, ils doivent écrire du code supplémentaire pour utiliser les modèles objet Office.Il existe également quelques différences entre les fonctionnalités de programmation de base du développement Office et celles du code managé écrit dans Visual Basic et 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 de Visual Basic	Prise en charge de Visual C#
Paramètres facultatifs	De nombreuses méthodes Microsoft Office ont des paramètres qui ne sont pas requis lorsque vous appelez la méthode.Si aucune valeur n'est transmise pour le paramètre, une valeur par défaut est utilisée.	Visual Basic prend en charge les paramètres facultatifs.	Visual C# prend en charge les paramètres optionnels dans la plupart des cas.Pour plus d'informations, consultez Paramètres optionnels dans les solutions Office.
Passage de paramètres par référence	Dans la plupart des assemblys PIA (Primary Interop Assembly) Microsoft Office, les paramètres facultatifs peuvent être passés par valeur.Toutefois, dans certains assemblys PIA, les paramètres facultatifs 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 Passage d'un argument par valeur et par référence (Visual Basic) (pour Visual Basic) et Passage de paramètres (Guide de programmation C#).	Aucun travail supplémentaire n'est nécessaire pour passer des paramètres par référence.Le compilateur Visual Basic passe automatiquement les paramètres par référence lorsque nécessaire.	Dans la plupart des cas, le compilateur Visual C# passe automatiquement les paramètres par référence lorsque cela est nécessaire.Pour plus d'informations, consultez Paramètres optionnels dans les solutions Office.
Propriétés paramétrées	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 exécute la liaison tardive lorsque Option Strictest désactivé.Lorsque 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 Office.	Visual C# exécute la liaison tardive dans les projets qui ciblent .NET Framework 4.Pour plus d'informations, consultez Liaison tardive dans les solutions Office.

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

Le tableau suivant affiche 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 de Visual Basic et Visual C#
Index de tableau	La limite inférieure du tableau de collections dans les applications Microsoft Office commence par 1.Visual Basic et Visual C# utilisent des tableaux basés sur 0.Pour plus d'informations, consultez Tableaux (guide de programmation C#) et Tableaux dans 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.