Que fait stdole.dll?
Nous avons une grande application C # (.net 2.0) qui utilise notre propre composant COM C++ et une bibliothèque de scanneurs d'empreintes digitales tierces également accessible via COM. Nous avons rencontré un problème où, en production, certains événements de la bibliothèque d'empreintes digitales ne sont pas déclenchés dans l'application C #, bien que les événements de notre propre composant COM C++ aient été déclenchés et qu'ils aient été correctement reçus.
À l'aide de MSINFO32 pour comparer les modules chargés sur un système en fonctionnement à ceux d'un système défaillant, nous avons déterminé que cela était dû au fait que STDOLE.DLL n'était pas dans le GAC et n'était donc pas chargé dans le processus défectueux.
En faisant glisser ce fichier dans le GAC, les événements ont bien été renvoyés dans la bibliothèque d'empreintes digitales COM.
Alors, que fait stdole.dll? Il a une taille de 16k, il ne peut donc pas y en avoir beaucoup… est-ce une sorte de lien vers une autre bibliothèque comme STDOLE32? Comment se fait-il que son absence provoque un tel comportement étrange?
Comment distribuons-nous stdole.dll? Ceci est une application de déploiement XCOPY et nous n'utilisons pas le GAC. Devrions-nous le conditionner en tant que ressource et utiliser System.EnterpriseServices.Internal.Publish.GacInstall pour s’assurer qu’il se trouve dans le GAC?
Il semble que stdole.dll soit un assemblage primaire interop. Voir Assemblys d'interopérabilité primaires Office 2003 sur MSDN.
Ce problème est également abordé ici: Pourquoi Visual Studio 2015 ajoute-t-il stdole.dll et Microsoft.AnalysisServices.AdomdClient.dll à mon projet?
La mise à niveau d'un ancien projet vers VS 2015 est la raison pour laquelle stdole.dll a commencé à être inclus dans le projet dans ce cas.
Si le référencement de la bibliothèque a l'option "Incorporer les types d'interopérabilité" dans les correctifs, cette option est préférable et le fichier stdole.dll peut ne plus être nécessaire par la suite. Il suffit de définir Embed Interop Types=true dans les propriétés de la référence.
Les bibliothèques qui permettent cela incluent les bibliothèques MS Office telles que Office, Excel, Core. Crystal Reports est un exemple de cela.
Hans Passantdécourage fortement de définir Embed Interop Types=false ici: Quelle est la différence entre les types d'interopérabilité incorporés true et false dans Visual Studio?
J'ai eu le même problème. Je viens de supprimer la référence de l'application et recompilé. A couru tous les tests qui ont réussi. Puis redéployé sans la DLL et tout a fonctionné.
Je ne sais pas comment une référence à cela a été introduite dans le projet. C'est une application héritée, donc ça doit être il y a longtemps.
Simon
Dans notre projet IDispatch couses utilisant stdole.dll. Nous l'avons changé en object et supprimé IDispatch, puis nous avons supprimé stdole des références.
Dans mon cas, il s'agissait d'une ancienne référence inutilisée à Office Word Interop ... mais sa suppression était insuffisante: le profil de publication avait toujours une ligne pour copier stdole.dll!
<File Include="bin/stdole.dll"> ...
La suppression de cette ligne (trouvée à l'aide de 'Rechercher dans les fichiers') et la suppression de stdole.dll du dossier bin du serveur distant ont résolu mon problème.
J'espère que ceci aide quelqu'un d'autre.
Je devais également ajouter une référence à mon projet pour stdole. Même si je n’ai aucune référence à cela (c’est une simple application d’image), 2 de nos utilisateurs avaient des erreurs qui leur manquaient. Il se peut qu’ils n’exécutaient que .net 2.0 quand il s’agissait d’une application 3.5. J'ai compris pourquoi.
Je suis également allé publier sur l'onglet Propriétés du projet, et j'ai sélectionné Application Files, puis inclus le stdole à déployer. Espérons que cela fonctionnera.