Why is Visual Studio 2015 adding stdole.dll and Microsoft.AnalysisServices.AdomdClient.dll to my project?

Question

These DLLs are not added to my project in prior versions of Visual Studio. My guess is that one of my references has a dependency to these DLLs. From what I've read, the highlighted Microsoft.Office.Interop.Excel might be the one. Can anyone confirm this? I should also note that VS 2015 always publishes these DLLs as well even if I exclude them from the the project. If I delete them, VS 2015 will remake them.

Edit: I have confirmed that the Excel and Office references are what's causing the inclusion of stdole.dll. See selected answer below to remove stdole.dll.

I've crossed out the custom references. Let me know if more information is needed. Here's my current references:

Answer 1

As others indicated, stdole.dll is a Primary Interop Assembly for a bunch of Office COM interop components. You can determine why it's getting included in your project by doing the following.

In Visual Studio, go to Tools > Options > Projects and Solutions > Build and Run. Change the "MSBuild project build output verbosity" setting to Detailed. Now clean and rebuild your project.

Open the Output window and search for stdole. You should find a section like this:

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".

You can see where Visual Studio searched for the assembly as well what requires it at the bottom. In my case it's a bunch of old Crystal Reports assemblies.

Sometimes you can embed the interop types via the dependencies as Tony suggests, but not always. For me, the Crystal Reports assemblies do not support this.

I fixed this problem (and the insidious one scottsanpedro mentioned) by copying the stdole.dll (32KB, digitally signed) from C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\ into a "Dependencies" folder inside my project. I added the file to my project and added an explicit reference to it (Add Reference > Browse). Finally I opened the new reference's properties and set Embed Interop Types to True.

This seems to be a better situation. I shouldn't need to worry about getting an unsigned version of the assembly.

Answer 2

If you have the option, use Embed Interop Types and leave stdole.dll out of it all together or you will run into the problem every time you move the application (new servers or dev machines) where stdole.dll isn't signed.

Problem: There is a reference that is requiring stdole.dll and stdole.dll is now being automatically pushed to the bin folder.

Solution:

• Find the reference requiring stdole.dll (more on how to do this below)
• Go to it's properties (Right click->properties)
• Change "Embed Interop Types" from false to true.

How to find the reference: When you click on the properties of your references, check to see if "Embed Interop Types" is set to false. To dig even further, Nick's answer has some great info.

References I've confirmed so far that use stdole.dll (probably more office programs as well)

• Office

• Excel

• Core

• Crystal Reports (Thanks Lithium. As Nick points out, you may not have the advantage of setting Embed Interop Types=true)

• NetOffice OfficeApi

If you find more, add them to this list or note them in the comments and I'll do it.

Hans Passant strongly discourages setting Embed Interop Types=false here: What's the difference setting Embed Interop Types true and false in Visual Studio?

Scott Hanselman also talks about what the "Embed Interop Types" does here: http://www.hanselman.com/blog/CLRAndDLRAndBCLOhMyWhirlwindTourAroundNET4AndVisualStudio2010Beta1.aspx

Answer 3

I have been dealing with this problem for ages.

Whenever I install anything from the web platform or any updates the stdole.dll gets replaced with a non signed version. I reported the bug to Microsoft a while back but fell on deaf ears.

I go to C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies and copy the signed version (22kb) from here and replace the version in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Visual Studio Tools for Office\PIA\Common (16kb) and that solves the problem.

Scott

Answer 4

In my situation I found that toggling the Copy Local property of the assembly that depends on stdole.dll, saving the project and then toggling the property back to its original value, and finally saving the project again solved the problem. This property may also be related to the Embed Interop Types property for other people with this problem.

What this does is explicitly saves the Copy Local property to the .xxproj file. Otherwise, the state of this property is not in the project file and a default is assumed. I have no explanation why this works as the presence of the property in the project file does not change the displayed value in Visual Studio nor does it cause a change in the assembly actually being published or not. I also did not cause a change in these properties from their originally displayed values after toggling them back and forth.

I do note that even before I found the cure I saw that cleaning the project and rebuilding it did not cause stdole.dll to be copied to bin. It was only after publishing that stdole.dll showed up.