Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction automatique. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Conception et création de solutions Office

Visual Studio fournit des modèles de projet permettant de créer plusieurs 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 la création de votre projet, consultez Développement de solutions 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.

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 utilisation de l'application, un complément d'application 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 dans Visual Studio, consultez Vue d'ensemble des modèles de projet Office. Pour plus d'informations sur la création de projets Office, consultez Comment : créer des projets 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, lorsque 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 Projets Office dans l'environnement Visual Studio.

Après avoir sélectionné le type de projet qui répond le mieux à vos besoins, vous pouvez choisir quelle 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 ciblée par votre projet doit être installée sur les ordinateurs des utilisateurs finaux pour que votre solution puisse être exécutée. Par exemple, si votre projet cible .NET Framework 4, .NET Framework 4 doit être installé sur les ordinateurs des utilisateurs finaux. Dans cet exemple, votre solution ne fonctionnera pas si seul le .NET Framework 3.5 est installé sur les ordinateurs des utilisateurs finaux.

Si vous migrez un projet de complément d'application qui cible .NET Framework 3.5, Visual Studio modifie la version cible du. Net Framework de votre projet vers .NET Framework 4 ou.NET Framework 4.5 selon la version d'Office que vous avez installée.

Toutefois, après que Visual Studio modifie la version cible du. Net Framework, vous devrez peut-être modifier une partie du code s'il utilise certaines fonctionnalités. Pour plus d'informations sur la modification de la version cible du .NET Framework, consultez Comment : cibler une version du .NET Framework. Pour plus d'informations sur les modifications éventuellement nécessaires, consultez Migration de solutions Office vers .NET Framework 4 ou .NET Framework 4.5.

Si Visual Studio modifie le .NET Framework ciblée par votre projet et utilisez ClickOnce pour déployer votre solution, assurez-vous que vous sélectionnez également la version correspondante du .NET Framework dans la boîte de dialogue Configuration requise. Cette sélection ne change pas automatiquement lorsque vous modifiez la version cible de .NET Framework de votre projet. Pour plus d'informations, consultez Comment : installer les composants requis sur les ordinateurs des utilisateurs finaux pour exécuter des solutions Office.

Remarque Remarque

Vous ne pouvez pas cibler .NET Framework 3.5 ou version antérieure dans les projets Office créées à l'aide de Visual Studio 2013. Les projets Office créées à l'aide de Visual Studio 2013 requièrent les fonctionnalités qui sont apparues dans .NET Framework 4 Client Profile

3295w01c.collapse_all(fr-fr,VS.120).gifSavoir quand les assemblys PIA Office sont nécessaires sur les ordinateurs des utilisateurs finaux

Par défaut, les assemblys PIA (PIAs) Office n'ont pas besoin d'être installés sur les ordinateurs des utilisateurs finaux si la propriété Incorporer les types interop de chaque référence d'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 à 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 appeler le modèle objet COM de l'application Office. Pour plus d'informations sur la manière dont les types d'assemblys PIA sont incorporés à votre solution, consultez Équivalence de type et types interop incorporés.

Si la propriété Incorporer les types interop de chaque référence d'assembly PIA dans le projet a la valeur False, des assemblys PIA Office 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 l'assembly PIA redistribuable comme composant requis pour votre solution. Pour plus d'informations, consultez Composants requis pour les solutions Office en vue du déploiement.

3295w01c.collapse_all(fr-fr,VS.120).gifComprendre le .NET Framework Client Profile

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 le déploiement le plus rapide possible pour votre solution Office. Pour plus d'informations, consultez .NET Framework Client Profile.

Lorsque vous créez un projet Office qui cible .NET Framework 4, .NET Framework 4 Client Profile est ciblé par défaut. Si vous souhaitez développer version complète de .NET Framework 4, vous devez définir cette option après la création du projet. Pour plus d'informations, consultez Comment : cibler une version du .NET Framework.

Microsoft Office 2013 et Office 2010 sont disponibles dans les éditions 64 bits et 32 bits. Pour créer des solutions Office qui peuvent s'exécuter dans toutes les éditions, le paramètre de plateforme cible de votre projet doit avoir la valeur Any CPU. Valeur par défaut pour les projets Office. Pour plus d'informations, consultez Génération de solutions Office.

Il existe des versions 64 bits et 32 bits distincts d'Visual Studio Tools pour Office Runtime utilisées par les éditions 64 bits et 32 bits de Microsoft Office 2013 et d'Office 2010. Pour plus d'informations, consultez Vue d'ensemble de Visual Studio Tools pour Office Runtime.

Lorsque vous créez un projet Office à l'aide des outils de développement Office dans Visual Studio, le code que vous écrivez est finalement compilé dans un assembly. L'assembly est déployé habituellement vers un serveur partagé ou un répertoire sur l'ordinateur client.

Les assemblys des solutions Office sont chargés par une application Office. Une fois l'assembly chargé, le code dans l'assembly peut réagir aux événements déclenchés dans l'application, par exemple, lorsqu'un utilisateur clique sur un élément de menu. Le code de l'assembly peut également appeler le modèle objet pour automatiser et étendre l'application, et 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 d'application.

Les solutions Office utilisent des manifestes de déploiement et des manifestes d'application pour identifier l'assembly. Le manifeste contient 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 représente le frontal 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.

Pour qu'une solution Office s'exécute sur un ordinateur, les assemblys utilisés par la solution doivent être approuvés avant d'être exécutés. Pour plus d'informations sur la sécurité, consultez Sécurisation des solutions Office.

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 lorsque vous générez le projet. Pour plus d'informations, consultez Génération de 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 sur un emplacement partagé. Pour plus d'informations, consultez Développement collaboratif de solutions Office.

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 de même type.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft