Partager via

Concevoir et créer des solutions Bureau

  • Article

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 personnalisations de code et d’interface utilisateur après avoir créé votre projet, consultez Développer des solutions Bureau.

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.

Remarque

Vous souhaitez développer des solutions qui étendent l’expérience de Bureau sur plusieurs plateformes ? Consultez le nouveau modèle de compléments Bureau. Bureau compléments ont une petite empreinte par rapport aux compléments et solutions VSTO, et vous pouvez les créer à l’aide de presque n’importe quelle technologie de programmation web, telle que HTML5, JavaScript, CSS3 et XML.

Créer des projets Bureau

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 Bureau inclus dans Visual Studio, consultez Bureau vue d’ensemble des modèles de projet. Pour plus d’informations sur la création de projets Bureau, consultez Guide pratique pour créer des projets Bureau 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 Bureau projets dans l’environnement Visual Studio.

Choisir une version du .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 de l’utilisateur final pour que votre solution s’exécute. Par exemple, si votre projet cible le .NET Framework 4, le .NET Framework 4 est requis sur les ordinateurs des utilisateurs finaux. Dans cet exemple, votre solution ne s’exécute pas si seul le .NET Framework 3.5 est installé sur les ordinateurs des utilisateurs finaux.

    Si vous migrez un projet de complément VSTO qui cible .NET Framework 3.5, Visual Studio modifie l’infrastructure cible de votre projet vers .NET Framework 4 ou version ultérieure en fonction de la version de Bureau que vous avez 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 du framework cible, consultez Guide pratique pour cibler une version du .NET Framework. Pour plus d’informations sur les modifications que vous devrez peut-être apporter dans votre projet, consultez Migrer Bureau solutions vers .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, veillez à sélectionner également la version correspondante du .NET Framework dans la boîte de dialogue Pré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 How to : Install prerequisites on end-user computers to run Bureau solutions.

Remarque

Vous ne pouvez pas cibler le .NET Framework 3.5 ou une version antérieure dans Bureau projets que vous créez à l’aide de Visual Studio 2013. Bureau projets que vous créez à l’aide de Visual Studio 2013 nécessitent des fonctionnalités qui ont été introduites pour la première fois dans le profil client .NET Framework 4

Comprendre quand les Bureau les adresses PERSONNELLEs sont requises sur les ordinateurs des utilisateurs finaux

Par défaut, Bureau assemblys PIA principaux n’ont pas besoin d’être installés sur les ordinateurs de l’utilisateur final si la propriété Embed Interop Types de chaque référence PIA Bureau 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 informations d’identification personnelle pour appeler le modèle objet COM de la application Office lication. Pour plus d’informations sur la façon dont les types provenant d’applications personnelles sont incorporés dans votre solution, consultez l’équivalence de type et les types d’interopérabilité incorporés.

Si la propriété Embed Interop Types de chaque référence PIA de chaque Bureau dans le projet a la valeur False, Bureau adresses IPA doivent être installées et inscrites dans le Global Assembly Cache sur chaque ordinateur 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 Bureau conditions préalables à la solution pour le déploiement.

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 le profil client .NET Framework.

Lorsque vous créez un projet Bureau qui cible .NET Framework 4, le profil client .NET Framework 4 est ciblé par défaut. Si vous souhaitez développer pour le .NET Framework 4 complet, vous devez définir cette option une fois le projet créé. 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 Bureau

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

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

Assemblys dans les solutions Bureau

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 de l’assembly peut également appeler le modèle objet pour automatiser et étendre l’application, et peut utiliser l’une des classes du .NET Framework. Pour plus d’informations, consultez Architecture des personnalisations au niveau du document et Architecture des compléments 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 les manifestes d’application et de déploiement dans les solutions Bureau.

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 Bureau 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 Bureau.

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 Bureau.

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.

Contenu connexe