Interop Outlook - différence de version - plantage

**Jean-Philippe André** · 24/01/2018, 21h14

Bonjour,

j'ai développé un outil en C# qui pilote Outlook, Word et Excel.

Je suis dans un cas de figure assez particulier.

J'ai commencé mon développement il y a quelques semaines, et la version Interop.Outlook disponible dans mon dossier Assembly (C:\Windows) est 14.0.4760.1000 alors que la version courante d'Outlook sur le poste est 14.0.7173.5000.

Cette différence est certes minime, mais génère des erreurs d'exception et empêche par la suite le lancement multiple d'Outlook.

le bout de code en question :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
using Outlook = Microsoft.Office.Interop.Outlook;
...
Outlook.Application OlApp;
            if (Process.GetProcessesByName("OUTLOOK").Count() > 0)
            {
 
                // If so, use the GetActiveObject method to obtain the process and cast it to an Application object.
                OlApp = Marshal.GetActiveObject("Outlook.Application") as Outlook.Application;
            }
            else
            {
 
                // If not, create a new instance of Outlook and log on to the default profile.
                OlApp = new Outlook.Application();
            }

Quelqu'un aurait une solution pour corriger le problème de version ou pour recommander un gestion plus pragmatique sans avoir à passer par un try catch ?

Merci

**clementmarcotte** · 25/01/2018, 04h45

Bonjour,

Cela me surprend un peu. Si mes souvenirs sont exacts, et si Microsoft n'a pas changé d'idée, les Primary Interop Assemblies (PIA pour les intimes), les dll Interop ont eu des GUID différents d'Office 2002 à Office 2003, mais sont constants depuis Office 2003. En principe, encore que là tu soulèves une incertitude, VS, ou Office, vont utiliser le fichier le plus récent sur la machine, et tant que tu t'en tiens à ce qui est commun à toutes les versions, c'est supposé passer comme su beurre dans la poêle. Mais là la batterie se vide et le McDo ferme dans quelques minutes. Je vais quand même faire quelques vérifications et je vais essayer de de te revenir demain.

**Jean-Philippe André** · 25/01/2018, 15h20

Hello Clément,

à noter que depuis mon poste, la mise à jour des packages nuget n'est pas possible sur le site nuget.org. Je ne saurais te dire si c'est en lien direct avec ma problématique présente, mais sait-on jamais.

Merci

**clementmarcotte** · 25/01/2018, 22h00

Bonjour,

Je n'ai trouvé rien de mieux que ce que j'ai dit hier. J'ai trouvé bizarre que dans mes références de VS j'ai les bibliothèques Interop pour Office 2013 et Office 2016. Mais dans la GAC et dans le registre j'ai juste Office 2016.

Si ta version 14 est celle d'Office 2010, tu peux essayer de passer par là, sans trop savoir si les fichiers sont à jour:

https://www.microsoft.com/en-us/down...s.aspx?id=3508

Comment as-tu essayé ta mise à jour de package ?

Si c'est avec l'hôte PowerShell (menu outils de VS) et update-package, les messages d'horreur sont en rouge.

Sinon. tu peux les télécharger sur ton disque avec NugetPackageExplorer et essayer une mise à jour locale.

Ah, aussi, VS est croche avec NuGet. Regardes dans ta liste déroulante si tu as la source locale ou la source en-ligne. Il ne s'ajuste pas automatiquement.

Si tu ramasses une erreur OLE avec un numéro -2 et une longue liste de chiffres tu as un peu d'Informations sur cette vieille page, pas vraiment à jour. Mais, des fois, cela marche.

Un autre truc que j'utilise est de mettre le message d'erreur (entre guillemets) dans le moteur de recherche de MSDN Mais, cela peut être long longtemps quand vient le temps d'élaguer.

**Jean-Philippe André** · 25/01/2018, 22h10

Je suis bloqué pour les maj de package, donc pas moyen de faire de subtilité :/

Concernant l'erreur que j'obtiens sur la ligne de Marshal :

Opération non disponible (Exception de HRESULT : 0x800401E3 (MK_E_UNAVAILABLE))

**clementmarcotte** · 25/01/2018, 22h31

Bonjour,

Sur ma page, ils disent:

-2147221021 (800401E3) Opération non disponible.

Comme si tu ne pouvais plus (pas) avoir plus d'une instance d'Outlook ouverte. Mais là, je ne connais pas assez Outlook pour savoir

Mais, comme c'est une erreur OLE, et que OLE est une fonctionnalité de Windows; cela pourrait venir de Windows et non de ton programme lui-même. Es-tu sûr que ce sont deux versions identiques de Windows ?

**Jean-Philippe André** · 26/01/2018, 15h13

Justement, c'est lorsque Outlook est déjà ouvert (depuis mon menu démarrer) que se pose le problème, alors que
- si je ferme Outlook
- execute le code
=>Outlook est lancé et ne pose pas de problème sur le "reclic", vu que la version lancée est celle de l'interop

**wallace1** · 26/01/2018, 20h40

Bonsoir,

Je pense qu'il faut regarder du côté des droits et privilèges d'exécution d'une part du côté applicatif Outlook et d'autre part au niveau du projet !

1- Lance ton outlook en tant qu'administrateur pour simuler ton instance déjà ouverte avec une élévation.
2- paramètres le fichier Manifest de ton projet sur "RequireAdministrator".
3- compile et regénère ton binaire (release ou debug)
4- exécutes ton programme en tant qu'administrateur depuis (debug ou release).

PS : on pourrait envisager de faire la même chose avec le manifest paramétré en "AsInvoker" et exécuter la 1ère instance d'outlook en un simple clique....

A tester.

++

**Jean-Philippe André** · 26/01/2018, 21h08

Salut,

cela me semble être une bonne série de tests à effectuer dès lundi, merci !!

**Jean-Philippe André** · 30/01/2018, 15h36

Salut,

notre histoire de lancement en administrateur semble la bonne

Reste à configurer le lanceur (celui à partir duquel les utilisateurs lance mon application) pour que cela n'engendre plus des bugs.

Merci pour ces idées.

Je laisse le point ouvert pour poster ultérieurement la solution

**Jean-Philippe André** · 30/01/2018, 19h39

Re,

donc comme prévu, le code en lui-même est bon, mais c'est lors du lancement par le gestionnaire d'applications que l'on force le lancement sans les droits d'admin.

le code du lanceur est en VB.Net

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
processALancer.StartInfo.FileName = Path.Combine(Environment.GetEnvironmentVariable("windir"), "explorer.exe")
processALancer.StartInfo.Verb = ""                //important!
processALancer.StartInfo.Arguments = pathExecutable

**wallace1** · 30/01/2018, 22h49

de rien.

**clementmarcotte** · 31/01/2018, 02h45

Envoyé par Jean-Philippe André

Salut,

Reste à configurer le lanceur (celui à partir duquel les utilisateurs lance mon application) pour que cela n'engendre plus des bugs.

Je laisse le point ouvert pour poster ultérieurement la solution

ou bien tu demandes à ton programme de faire confirmer par Windows qu'il doit être lancé en qu'administrateur

Version VB

Version C#