concevoir et créer des solutions Office

Visual Studio fournit des modèles de projet que vous pouvez utiliser pour créer différents types de solutions Office. Cette section de la documentation décrit les modèles de projet et apporte des conseils sur la création de projets Office. pour plus d’informations sur l’implémentation de code et de personnalisations d’interface utilisateur après avoir créé votre projet, consultez développer des solutions Office.

S’applique à : Les informations contenues dans cette rubrique s’appliquent aux - projets de niveau document et aux projets de compléments VSTO - . Consultez fonctionnalités disponibles par type d’application et de projet Office.

Notes

Vous souhaitez développer des solutions qui étendent l’expérience Office sur plusieurs plateformes ? Consultez le nouveau modèle des compléments Office. Les compléments Office ont un faible encombrement par rapport aux compléments et solutions VSTO, et vous pouvez les créer en utilisant presque toutes les technologies de programmation Web, telles que HTML5, JavaScript, CSS3 et XML.

créer des projets Office

Avant de commencer, vous devez déterminer vos besoins et choisir le type de solution qui convient le mieux. Par exemple, si votre solution Office doit s'exécuter chaque fois que l'application est utilisée, un complément VSTO correspond mieux à vos critères. Si le code est étroitement intégré à un document unique, créez une personnalisation au niveau du document. Ces types de projets sont disponibles sous forme de modèles de projet Visual Studio. pour plus d’informations sur les modèles de projet Office inclus avec Visual Studio, consultez Office vue d’ensemble des modèles de projet. pour plus d’informations sur la création de projets de Office, consultez comment : créer des projets de Office dans Visual Studio.

Certaines fonctionnalités et certains éléments des projets Office diffèrent des autres types de projets dans Visual Studio. Par exemple, quand vous créez un projet au niveau du document, le document ou le classeur de votre projet peut être ouvert et modifié depuis Visual Studio. pour plus d’informations, consultez Office des projets dans l’environnement Visual Studio.

choisir une version de .NET Framework

Après avoir sélectionné le type de projet qui répond le mieux à vos besoins, vous pouvez choisir la version du .NET Framework utiliser dans votre processus de développement. Vous pouvez cibler les versions du .NET Framework suivantes dans les projets Office :

  • .NET Framework 4

  • .NET Framework 4 Client Profile

  • .NET Framework 4.5

    la version de .NET Framework que vous choisissez pour votre projet est requise sur les ordinateurs des utilisateurs finaux pour que votre solution s’exécute. Par exemple, si votre projet cible le .NET Framework 4 , .NET Framework 4 est requis sur les ordinateurs des utilisateurs finaux. dans cet exemple, votre solution ne s’exécute pas si seule la .NET Framework 3,5 est installée sur les ordinateurs des utilisateurs finaux.

    Si vous migrez un projet de complément VSTO qui cible le .NET Framework 3.5, Visual Studio remplace la version cible du .NET Framework de votre projet par .NET Framework 4 ou ultérieur en fonction de la version d’Office installée.

    Toutefois, après le changement de la version cible du .NET Framework par Visual Studio, vous devrez peut-être modifier une partie du code de votre projet s'il utilise certaines fonctionnalités. Pour plus d’informations sur la modification de la version cible de .NET Framework, consultez Comment : cibler une version du .NET Framework. pour plus d’informations sur les modifications que vous devrez peut-être apporter dans votre projet, consultez migrer des solutions Office vers le .NET Framework 4 ou version ultérieure.

    si Visual Studio modifie le .NET Framework cible pour votre projet et que vous utilisez ClickOnce pour déployer votre solution, assurez-vous de sélectionner également la version correspondante du .NET Framework dans la boîte de dialogue composants requis . Cette sélection ne change pas automatiquement quand vous modifiez la version cible du .NET Framework pour votre projet. pour plus d’informations, consultez procédure : installer les composants requis sur les ordinateurs des utilisateurs finaux pour exécuter des solutions Office.

Notes

Vous ne pouvez pas cibler le .NET Framework 3.5 ou version antérieure dans les projets Office créés à l'aide de Visual Studio 2013. Les projets Office créés à l'aide de Visual Studio 2013 nécessitent les fonctionnalités introduites dans le .NET Framework 4 Client Profile.

comprendre quand les assemblys pia Office sont requis sur les ordinateurs des utilisateurs finaux

par défaut, Office assemblys pia (primary interop assemblies) n’ont pas besoin d’être installés sur les ordinateurs des utilisateurs finaux si la propriété incorporer les Types interop de chaque Office référence de l’assembly pia dans le projet a la valeur True, qui est la valeur par défaut. Dans ce scénario, les informations relatives aux types PIA utilisés par votre solution sont incorporées dans l'assembly de solution au moment de la génération du projet. Au moment de l'exécution, les informations de type incorporées sont utilisées au lieu des assemblys PIA pour exécuter un appel dans le modèle objet COM de l'application Office. Pour plus d’informations sur la façon dont les types des assemblys PIA sont incorporés dans votre solution, consultez équivalence de type et types Interop incorporés.

si la propriété incorporer les Types Interop de chaque Office référence de l’assembly pia dans le projet a la valeur false, Office assemblys pia doivent être installés et inscrits dans le Global Assembly Cache sur chaque ordinateur de l’utilisateur final qui exécute la solution. Dans la plupart des cas, les assemblys PIA sont installés par défaut avec Office, mais vous pouvez également inclure le composant redistribuable de l'assembly PIA comme composant requis pour votre solution. pour plus d’informations, consultez Office conditions préalables pour le déploiement de solutions.

Comprendre le profil client

Le .NET Framework Client Profile est un sous-ensemble du .NET Framework complet. Vous pouvez cibler le .NET Framework Client Profile si vous devez utiliser uniquement les fonctionnalités client du .NET Framework et souhaitez fournir le déploiement le plus rapide possible pour votre solution Office. pour plus d’informations, consultez .NET Framework client profile.

Quand vous créez un projet Office qui cible le .NET Framework 4, le .NET Framework 4 Client Profile est ciblé par défaut. Si vous souhaitez développer pour la complète .NET Framework 4 , vous devez définir cette option après la création du projet. Pour plus d’informations, consultez Guide pratique pour cibler une version du .NET Framework.

Créer des solutions pour l’édition 64 bits de Microsoft Office

Microsoft Office est disponibles dans les éditions 64 bits et 32 bits. pour créer Office solutions qui peuvent s’exécuter dans l’une ou l’autre édition, le paramètre de plateforme cible de votre projet doit être défini sur Any CPU. Il s'agit de la valeur par défaut pour les projets Office. pour plus d’informations, consultez générer des solutions Office.

Il existe des versions 64 bits et 32 bits distinctes de Visual Studio Tools pour Office Runtime qui sont utilisées par les éditions 64 bits et 32 bits de Microsoft Office. pour plus d’informations, consultez Visual Studio Tools pour Office vue d’ensemble du runtime.

assemblys dans les solutions Office

Quand vous créez un projet Office à l'aide des Outils de développement Office dans Visual Studio, le code que vous écrivez est en fin de compte compilé dans un assembly. L’assembly est déployé sur un serveur partagé ou dans un répertoire sur l’ordinateur client.

Les assemblys dans les solutions Office sont chargés par une application Office. Une fois l'assembly chargé, le code dans l'assembly peut répondre aux événements déclenchés dans l'application, par exemple quand un utilisateur clique sur un élément de menu. Le code dans l'assembly peut également exécuter un appel dans le modèle objet pour automatiser et étendre l'application, et il peut utiliser toutes les classes du .NET Framework. pour plus d’informations, consultez architecture des personnalisations au niveau du document et architecture des compléments de VSTO.

Les solutions Office utilisent des manifestes de déploiement et des manifestes d'application pour identifier l'assembly. Les manifestes contiennent des informations sur le nom, la version et l'emplacement de l'assembly pour que l'application puisse trouver l'assembly approprié, créer un lien vers celui-ci et l'exécuter. pour plus d’informations, consultez manifestes d’Application et de déploiement dans les solutions Office.

Les projets au niveau du document incluent un document en plus d'un assembly. Le document constitue la partie frontale de l'application et concentre l'ensemble des interactions avec l'utilisateur. Chaque document ne peut être associé qu'à un seul assembly de projet principal ; cependant, plusieurs documents peuvent pointer vers le même assembly.

Les assemblys des projets au niveau du document ne sont pas incorporés au document ; ils sont en fait stockés ailleurs et sont identifiés par le manifeste d'application du document.

Considérations relatives à la sécurité pour les assemblys

Pour qu'une solution Office s'exécute sur un ordinateur, les assemblys utilisés par la solution doivent être approuvés pour exécution. pour plus d’informations sur la sécurité, consultez solutions de Office sécurisées.

Par défaut, l’assembly de solution et tous les assemblys référencés qui figurent dans le dossier de sortie de votre projet sont approuvés pour exécution sur l’ordinateur de développement quand vous générez le projet. pour plus d’informations, consultez générer des solutions Office.

Pour des raisons de sécurité, il est préférable de créer les projets sur votre ordinateur local, au lieu d'effectuer le développement dans un emplacement partagé. pour plus d’informations, consultez développement collaboratif de solutions Office.

Assemblys référencés

L'assembly peut référencer d'autres assemblys répertoriés dans les références du projet. Toutefois, un assembly de projet au niveau du document ne peut pas en référencer un autre.

Voir aussi