Pourquoi Visual Studio 2015 ajoute stdole.dll et Microsoft.AnalysisServices.AdomdClient.dll sur mon projet?
ces DLLs ne sont pas ajoutés à mon projet dans les versions précédentes de Visual Studio. Je pense qu'une de mes références dépend de ces DLLs. D'après ce que j'ai lu, le surligné Microsoft.Office.Interop.Excel pourrait être le bon. Quelqu'un peut-il confirmer cela? Je dois aussi noter que VS 2015 publie toujours ces DLLs même si je les exclus du projet. Si je les supprime, VS 2015 les refera.
Modifier : j'ai confirmé que le Les références Excel et Office sont la cause de l'inclusion de stdole.DLL. Voir la réponse sélectionnée ci-dessous pour supprimer stdole.DLL.
j'ai rayé les références. Permettez-moi de savoir si plus d'information est nécessaire. Voici mes références actuelles:
4 réponses
comme d'autres l'ont indiqué, stdole.dll est un assemblage Interop primaire pour un ensemble de composants COM interop de bureau. Vous pouvez déterminer pourquoi il est inclus dans votre projet en faisant ce qui suit.
Dans Visual Studio, aller à Tools > Options > Projects and Solutions > Build and Run . Changer le paramètre" MSBuild project build output verbosity "à Detailed . Maintenant nettoyez et reconstruisez votre projet.
ouvrez la fenêtre de sortie et recherchez stdole . Vous devriez trouver un section comme ceci:
25> Dependency "stdole, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
25> Resolved file path is "D:\Program Files (x86)\Microsoft Visual Studio 12.0\Visual Studio Tools for Office\PIA\Common\stdole.dll".
25> Reference found at search path location "{Registry:Software\Microsoft\.NETFramework,v4.0,AssemblyFoldersEx}".
25> For SearchPath "D:\Git\FoobarServices\Dependencies\Dependencies".
25> Considered "D:\Git\FoobarServices\Dependencies\stdole.winmd", but it didn't exist.
25> Considered "D:\Git\FoobarServices\Dependencies\stdole.dll", but it didn't exist.
25> Considered "D:\Git\FoobarServices\Dependencies\stdole.exe", but it didn't exist.
25> For SearchPath "{CandidateAssemblyFiles}".
25> Considered "Dependencies\CrystalDecisions.CrystalReports.Engine.dll", but its name "CrystalDecisions.CrystalReports.Engine" didn't match.
25> Considered "Dependencies\CrystalDecisions.Enterprise.Framework.dll", but its name "CrystalDecisions.Enterprise.Framework" didn't match.
25> Considered "Dependencies\CrystalDecisions.Enterprise.InfoStore.dll", but its name "CrystalDecisions.Enterprise.InfoStore" didn't match.
25> Considered "Dependencies\CrystalDecisions.ReportSource.dll", but its name "CrystalDecisions.ReportSource" didn't match.
25> Considered "Dependencies\CrystalDecisions.Shared.dll", but its name "CrystalDecisions.Shared" didn't match.
25> Considered "Dependencies\CrystalDecisions.Web.dll", but its name "CrystalDecisions.Web" didn't match.
25> For SearchPath "{TargetFrameworkDirectory}".
25> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\stdole.winmd", but it didn't exist.
25> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\stdole.dll", but it didn't exist.
25> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\stdole.exe", but it didn't exist.
25> For SearchPath "{Registry:Software\Microsoft\.NETFramework,v4.0,AssemblyFoldersEx}".
25> Considered AssemblyFoldersEx locations.
25> Required by "CrystalDecisions.Web, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304, processorArchitecture=MSIL".
25> Required by "CrystalDecisions.ReportSource, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304, processorArchitecture=MSIL".
25> Required by "CrystalDecisions.CrystalReports.Engine, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304, processorArchitecture=MSIL".
25> Required by "CrystalDecisions.Enterprise.InfoStore, Version=11.5.3300.0, Culture=neutral, PublicKeyToken=692fbea5521e1304".
25> The ImageRuntimeVersion for this reference is "v1.0.3705".
vous pouvez voir où Visual Studio a cherché l'assemblage ainsi que ce qui l'exige en bas. Dans mon cas, c'est un tas de vieux assemblages de rapports en cristal.
parfois vous pouvez intégrer les types interop via les dépendances comme Tony le suggère, mais pas toujours. Pour moi, les assemblées de Crystal Reports ne soutiennent pas cela.
j'ai corrigé ce problème (et le insidieux scottsanpedro mentioned) en copiant le stdole.dll (32KB, digitally signed) de C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\ dans un dossier "Dependencies" à l'intérieur de mon projet. J'ai ajouté le fichier à mon projet et j'y ai ajouté une référence explicite (ajouter une référence > parcourir). Finalement j'ai ouvert les propriétés de la nouvelle référence et j'ai mis Embed Interop Types à True .
cela semble être une meilleure situation. Je ne devrais pas avoir à m'inquiéter d'avoir une version non signée de l'Assemblée.
si vous avez l'option, Utilisez les types Embed Interop et quittez stdole.dll tout ensemble ou vous tomberez dans le problème chaque fois que vous déplacez l'application (nouveaux serveurs ou machines dev) où stdole.la dll n'est pas signée.
problème: il y a une référence qui exige stdole.dll et stdole.dll est maintenant poussé automatiquement vers le dossier bin.
Solution:
- trouver la référence requérant stdole.dll (pour en savoir plus)
- allez à ses propriétés (clic droit->Propriétés)
- Changement "Incorporer les Types Interop" de false à true.
Comment trouver la référence: lorsque vous cliquez sur les propriétés de vos références, vérifiez si" Embed Interop Types " est défini à false. Pour creuser encore plus, Nick réponse a quelques grandes informations.
références j'ai confirmé jusqu'à présent que l'utilisation de stdole.dll (probablement plus de programmes de bureau aussi)
-
Bureau
-
Excel
-
de Base
-
Crystal Reports (Thanks Lithium. Comme Nick le souligne, vous n'avez peut-être pas le avantage du réglage
Embed Interop Types=true)
si vous en trouvez d'autres, ajoutez-les à cette liste ou notez-les dans les commentaires et je le ferai.
Hans Passant décourage fortement mise en scène Embed Interop Types=false ici: Quelle est la différence entre mettre les types Interop vrai et faux dans Visual Studio?
Scott Hanselman parle aussi de ce que "Embed Interop Types" does here: http://www.hanselman.com/blog/CLRAndDLRAndBCLOhMyWhirlwindTourAroundNET4AndVisualStudio2010Beta1.aspx
je fais face à ce problème depuis des lustres.
chaque fois que j'installe quelque chose de la plate-forme web ou des mises à jour le stdole.dll est remplacé par une version non signée. J'ai signalé le bogue à Microsoft il y a quelques temps mais je suis tombé sur des oreilles sourdes.
je vais à C:\Program fichiers (x86)\Microsoft.NET\Primary Interop Assemblies and copy the signed version (22kb) from here and replace the version in C:\Program fichiers (x86)\Microsoft Visual Studio 14.0\Visual Studio Tools pour Office\PIA\Common (16 ko) et qui permet de résoudre le problème.
Scott
dans ma situation j'ai trouvé que toggling la copie propriété locale de l'assemblée qui dépend de stdole.dll, sauver le projet, puis remettre la propriété à sa valeur initiale, et finalement sauver le projet à nouveau résolu le problème. Cette propriété peut également être liée à la propriété Embed Interop Types pour les autres personnes ayant ce problème.
ce que cela fait est de sauvegarder explicitement la propriété locale de la copie sur le .fichier xxproj. Sinon, l'état de ce la propriété n'est pas dans le dossier de projet et un défaut est supposé. Je n'ai pas d'explication pourquoi cela fonctionne puisque la présence de la propriété dans le dossier de projet ne change pas la valeur affichée dans Visual Studio et ne provoque pas un changement dans l'assemblage étant effectivement publié ou non. Je n'ai pas non plus causé de changement dans ces propriétés par rapport aux valeurs affichées à l'origine après les avoir déplacées.
je note que même avant de trouver le remède j'ai vu que le nettoyage le projet et sa reconstruction n'ont pas causé de dommages.dll à copier dans bin. Ce n'est qu'après la publication de ce stdole.la dll est arrivée.