Architecture des personnalisations au niveau du document

  • Article

Visual Studio 2013 inclut des projets de création de personnalisations au niveau du document pour Microsoft Bureau Word et Microsoft Bureau Excel. Cette rubrique décrit les aspects suivants des personnalisations au niveau du document :

Comprendre les personnalisations

Quand vous utilisez les Outils de développement Office dans Visual Studio pour générer une personnalisation au niveau du document, vous créez un assembly de code managé associé à un document spécifique. On dit d’un document ou classeur lié à un assembly qu’il a des extensions de code managé. Pour plus d’informations, consultez Conception et création de solutions Bureau.

Quand un utilisateur ouvre le document, l’assembly est chargé par l’application Microsoft Office. Une fois l’assembly chargé, la personnalisation peut répondre à des événements pendant que le document est ouvert. La personnalisation peut également appeler le modèle objet pour automatiser et étendre l’application pendant l’ouverture du document, et elle peut utiliser l’une des classes du .NET Framework.

L'assembly communique avec les composants COM de l'application à travers l'assembly PIA (Primary Interop Assembly) de celle-ci. Pour plus d’informations, consultez Bureau principaux assemblys d’interopérabilité et vue d’ensemble du développement de solutions Bureau (VSTO).

Si un utilisateur ouvre plusieurs personnalisations au niveau du document en même temps, chaque assembly est chargé dans un domaine d’application différent. Cela signifie qu’une solution dont le comportement est incorrect ne peut pas entraîner l’échec d’autres solutions. Les personnalisations au niveau du document sont conçues pour fonctionner avec un seul document dans un seul domaine d’application. Elles ne sont pas conçues pour la communication entre documents. Pour plus d’informations sur les domaines d’application, consultez Domaines d’application.

Remarque

Les personnalisations au niveau du document que vous créez à l’aide des Outils de développement Office dans Visual Studio sont conçues pour être utilisées seulement quand l’application est démarrée par un utilisateur final. Si elle est démarrée par programmation (par exemple à l’aide d’Automation), la personnalisation risque de ne pas fonctionner correctement.

Expériences au moment du design et de l’exécution

Pour comprendre l’architecture des personnalisations au niveau du document, il est utile de comprendre les expériences de conception et d’exécution d’une solution.

Au moment de la conception

L’expérience au moment du design comprend les étapes suivantes :

  1. Le développeur crée un projet au niveau du document dans Visual Studio. Le projet comprend le document et l’assembly qui s’exécute derrière le document. Le document peut déjà exister (créé par un concepteur) ou un nouveau document peut être créé avec le projet.

  2. Le concepteur (le développeur qui crée le projet ou une autre personne) crée l’apparence finale du document pour l’utilisateur final.

Runtime

L’expérience au moment de l’exécution comprend les étapes suivantes :

  1. L’utilisateur final ouvre un document ou un classeur qui a des extensions de code managé.

  2. Le document ou le classeur charge l’assembly compilé.

  3. L’assembly répond aux événements à mesure que l’utilisateur travaille dans le document ou le classeur.

Perspective des développeurs et des utilisateurs finaux comparées

Étant donné que le développeur fonctionne principalement dans Visual Studio et que l’utilisateur final fonctionne dans Word ou Excel, il existe deux façons de comprendre les personnalisations au niveau du document.

Perspective du développeur Perspective de l’utilisateur final
À l’aide de Visual Studio, le développeur écrit du code accessible à Word et Excel.

Bien qu’il puisse sembler que le développeur crée un fichier exécutable qui exécute Word ou Excel, c’est en fait le processus inverse qui se produit. Le document est associé à un assembly et contient un pointeur vers cet assembly. Quand le document s’ouvre, Word ou Excel recherche l’assembly et exécute le code en réponse à tous les événements gérés.		 Ceux qui utilisent la solution ouvrent simplement le document ou le classeur (ou créent un document à partir d’un modèle), comme ils le feraient pour n’importe quel autre fichier Microsoft Office.

L’assembly fournit des personnalisations dans le document ou le classeur, telles que le remplissage automatique avec des données à jour ou l’affichage d’une boîte de dialogue pour demander des informations.

Formats de document pris en charge pour les personnalisations au niveau du document

Quand vous créez un projet de personnalisation, vous pouvez choisir le format du document que vous souhaitez utiliser dans le projet. Pour plus d’informations, consultez Guide pratique pour créer des projets Bureau dans Visual Studio.

Le tableau suivant répertorie les formats de documents que vous pouvez utiliser dans les personnalisations au niveau du document pour Excel et Word.

Excel Word
Classeur Excel (.xlsx)

Classeur avec macro Excel (.xlsm)

Classeur binaire Excel (.xlsb)

Classeur Excel 97-2003 (.xls)

Modèle Excel (.xltx)

Modèle avec macro Excel (.xltm)

Modèle Excel 97-2003 (.xlt)		 Document Word (.docx)

Document avec macro Word (.docm)

Document Word 97-2003 (.doc)

Modèle Word (.dotx)

Modèle avec macro Word (.dotm)

Modèle Word 97-2003 (.dot)

Vous devez concevoir des extensions de code managé uniquement pour les documents dont le format est pris en charge. Sinon, certains événements risquent de ne pas être déclenchés lorsque le document s’ouvre dans l’application. Par exemple, l’événement Open n’est pas déclenché lorsque vous utilisez des extensions de code managé avec des classeurs enregistrés au format de feuille de calcul XML Excel ou dans la page web (.htm ; . format html).

Prise en charge des documents Word qui ont des extensions de nom de fichier .xml

Les modèles de projets au niveau du document ne vous permettent pas de créer des projets basés sur les formats de fichiers suivants :

  • Document XML Word (*xml).

  • Document XML Word 2003 (*xml).

    Si vous souhaitez que vos utilisateurs finaux utilisent des personnalisations dans ces formats de fichiers, générez et déployez une personnalisation qui utilise l’un des formats de fichiers pris en charge spécifiés dans le tableau ci-dessus. Après avoir installé la personnalisation, les utilisateurs finaux peuvent enregistrer le document au format Document XML Word (*xml) ou au format Document XML Word 2003 (*xml), et la personnalisation continuera de fonctionner comme prévu.

Composants des personnalisations

Les principaux composants d’une personnalisation sont le document et l’assembly. Outre ces composants, il en existe plusieurs autres qui jouent un rôle important dans la manière dont les applications Microsoft Office découvrent et chargent les personnalisations.

Manifeste de déploiement et manifeste d’application

Les personnalisations utilisent des manifestes de déploiement et des manifestes d’application pour identifier et charger la version la plus récente de l’assembly de personnalisation. Le manifeste de déploiement pointe vers le manifeste d'application actuel. Le manifeste d’application pointe vers l’assembly de personnalisation et spécifie la ou les classes de point d’entrée à exécuter dans l’assembly. Pour plus d’informations, consultez les manifestes d’application et de déploiement dans les solutions Bureau.

Visual Studio Tools pour Office Runtime

Pour exécuter des personnalisations au niveau du document créées à l’aide des outils de développement Bureau dans Visual Studio, les ordinateurs de l’utilisateur final doivent avoir installé le runtime Visual Studio Tools pour Office. Le runtime Visual Studio Tools pour Office inclut des composants non managés qui chargent l’assembly de personnalisation, ainsi qu’un ensemble d’assemblys managés. Ces assemblys managés fournissent le modèle objet utilisé par votre code de personnalisation pour automatiser et étendre l’application hôte.

Pour plus d’informations, consultez Visual Studio Tools pour Bureau vue d’ensemble du runtime.

Fonctionnement des personnalisations avec les applications Microsoft Office

Quand un utilisateur ouvre un document qui fait partie d’une personnalisation Microsoft Office, l’application utilise le manifeste de déploiement lié au document pour rechercher et charger la version la plus récente de l’assembly de personnalisation. L’emplacement du manifeste de déploiement est stocké dans une propriété de document personnalisée nommée AssemblyLocation. La chaîne qui identifie cet emplacement est insérée dans la propriété lorsque vous générez la solution.

Le manifeste de déploiement pointe vers le manifeste d’application, qui pointe vers l’assembly le plus récent. Pour plus d’informations, consultez les manifestes d’application et de déploiement dans les solutions Bureau.

L’illustration suivante montre l’architecture de base d’une personnalisation au niveau du document.

2007 Office customization architecture

Remarque

Dans Bureau solutions qui ciblent .NET Framework 4, les solutions appellent le modèle objet de l’application hôte à l’aide d’informations de type PIA (Primary Interop Assembly) incorporées dans l’assembly de solution, au lieu d’appeler directement dans l’assembly pia. Pour plus d’informations, consultez Conception et création de solutions Bureau.

Processus de chargement

Les étapes suivantes se produisent lorsqu’un utilisateur ouvre un document qui fait partie d’une solution Microsoft Office.

  1. L’application Microsoft Office vérifie les propriétés de document personnalisées pour voir si des extensions de code managé sont associées au document. Pour plus d’informations, consultez vue d’ensemble des propriétés de document personnalisées.

  2. S’il existe des extensions de code managé, l’application charge VSTOEE.dll, qui charge VSTOLoader.dll. Il s’agit de DLL non managées qui sont les composants du chargeur pour Visual Studio 2010 Tools pour Bureau runtime. Pour plus d’informations, consultez Visual Studio Tools pour Office vue d’ensemble du runtime.

  3. VSTOLoader.dll charge le .NET Framework et démarre la partie managée du runtime Visual Studio Tools pour Office.

  4. Si le document est ouvert à partir d’un emplacement autre que l’ordinateur local, le runtime Visual Studio Tools pour Office vérifie que l’emplacement du document se trouve dans la liste Emplacements approuvés du Centre de gestion de la confidentialité Paramètres pour cette application Office lication particulière. Si l’emplacement du document n’est pas un emplacement approuvé, la personnalisation n’est pas approuvée et le processus de chargement est arrêté.

  5. Le runtime Visual Studio Tools pour Office installe la solution s’il n’a pas encore été installé, télécharge les manifestes d’application et de déploiement les plus récents et effectue une série de case activée de sécurité. Pour plus d’informations, consultez Solutions de Bureau sécurisées.

  6. Si la personnalisation est approuvée pour s’exécuter, le runtime Visual Studio Tools pour Office utilise le manifeste de déploiement et le manifeste d’application pour case activée pour les mises à jour d’assembly. Si une nouvelle version de l’assembly est disponible, le runtime télécharge la nouvelle version de l’assembly dans le cache ClickOnce sur l’ordinateur client. Pour plus d’informations, consultez Déployer une solution Bureau.

  7. Le runtime Visual Studio Tools pour Office crée un domaine d’application dans lequel charger l’assembly de personnalisation.

  8. Le runtime Visual Studio Tools pour Office charge l’assembly de personnalisation dans le domaine d’application.

  9. Le runtime Visual Studio Tools pour Office appelle le gestionnaire d’événements startup dans votre assembly de personnalisation. Pour plus d’informations, consultez Événements dans Bureau projets.

Contenu connexe