Résoudre l’erreur « Unable to cast COM object of type… to interface type…

par

Hello,

Récemment, j’ai dû me pencher sur une erreur dans l’application IBM Cognos Controller. Pour la petite histoire, ce logiciel nécessite, pour son bon fonctionnement, Internet Explorer 8 et Microsoft Office 2010. Or les PCs sur lesquels l’erreur survenait avaient été livrés avec Internet Explorer 10 et Microsoft Office 2013. Donc, un downgrade vers la version supportée a été effectué par un technicien. C’est sans doute lors de cette opération, pourtant effectuée selon les recommandations de Microsoft, qu’un composant propre à Office 2013 n’a pas été correctement désinstallé.

L’erreur dans IBM Cognos Controller survenait lors de la création de rapport type formulaire (Report / Form), censé ouvrir Microsoft Excel avec le résultat :

cognos

Ce message nous indique qu’une librairie utilisée pour la création du rapport n’a pas été enregistrée. Notons au passage l’ID de l’interface incriminée, ce qui nous permettra d’avancer dans le troubleshooting de ce problème.

Après quelques recherches, j’ai découvert grâce à Process Monitor que le logiciel Cognos allait lire une clé dans la base de registre, sous HKEY_CLASSES_ROOT\TypeLib\HKEY_CLASSES_ROOT\TypeLib\{000208D5-0000-0000-C000-000000000046}. Cette clé possède une sous-clé nommée ‘1.8‘, qui fait référence à Office 2013, pourtant désinstallé correctement.

Cognos2

Supprimer cette sous-clé a résolu mon problème avec IBM Cognos Controller. J’ai constaté que l’ID constituant le nom de la clé n’était pas identique sur tous les PC. Afin d’automatiser la détection et la suppression de cette clé, j’ai créé le script PowerShell suivant, qui va lister toutes les clés de registre sous HKCR:\TypeLib dont le nom contient ‘0000-0000-C000-000000000046’ (partie commune), et ayant une sous-clé nommé 1.8… et supprimer cette clé.

<#
.NAME
    CognosFormIssueResolver.ps1 
.SYNOPSIS 
    This script resolve the Cognos Controller Report/Form issue.
.DESCRIPTION 
    This script delete a registry key related to Office 2013, that prevent IBM Cognos Controller to use the Office 2010 links/libraries correctly.
.NOTES 
    Author     : Antoine DELRUE - antoine@delrue.me
#>

# [REQUIRED] If the HKCR (Classes Root) drive does not exists, create it.
$TestProvider = Test-Path hkcr:\
if (!$TestProvider)
{
     New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR
     Write-Verbose -Message "Created the HKCR PSDrive `r`n"
}

# [REQUIRED] Getting the incriminated registry key (related to Office 2013, then forcefully delete it). 
$Query = Get-ChildItem "HKCR:\TypeLib" -rec  | ?  {$_.Name -ilike  "*0000-0000-C000-000000000046*" } | ForEach-Object { Get-ItemProperty $_.pspath | ? {$_.PSChildName -ilike "*1.8*" }} 

if (!$Query)
{
    Write-Verbose -Message "Registry key not found, exiting script."
}

else
{
    $query | Remove-Item -Recurse -Force -Verbose
}

Pour information, voici la réponse du support IBM, après que je leur aie expliqué ma résolution :

Hi Antoine, Thanks for the interesting update. Controller should not be hard coded to look at reg keys on a specific Excel version. What can happen though is, un-installing the Excel Link/CCR Local Client can sometimes leave remnants. So for example if a previous install of the CCR client was linked with Excel 2003, and some old reg keys get left behind, then it can interfere with a later install that’s meant to point to Excel 2010. Should that happen, we recommend un-install the CCR client then search the Registry for any leftover Cognos Controller keys and delete them. Then re-install.
Les posts qui m'ont aidé dans la résolution de ce problème :

http://blogs.msdn.com/b/dau-blog/archive/2012/04/20/how-to-solve-unable-to-cast-com-object-of-type-microsoft-office-interop-excel-applicationclass-to-interface-type-microsoft-office-interop-excel-application.aspx

http://kb.palisade.com/index.php?pg=kb.page&id=528

J’espère que cela pourra vous être utile !