Почему Visual Studio 2015 добавляет в проект проект stdole.dll и Microsoft.AnalysisServices.AdomdClient.dll?

Ответ 1

Если у вас есть этот параметр, используйте Embed Interop Types и оставите файл stdole.dll из него все вместе или вы столкнетесь с проблемой при каждом перемещении приложения (новые серверы или dev-машины), где stdole.dll не является подписан.

Проблема: Существует ссылка, которая требует, чтобы stdole.dll и stdole.dll теперь автоматически помещались в папку bin.

Решение:

• Найдите ссылку, требующую stdole.dll(подробнее о том, как это сделать ниже)
• Перейдите к свойствам (щелкните правой кнопкой мыши- > свойства)
• Измените "Вставить типы взаимодействия" с false на true.

Как найти ссылку:. Когда вы нажимаете на свойства своих ссылок, проверьте, установлено ли значение "Вставить типы прерываний" в значение "false". Чтобы копать еще больше, Ник ответ имеет отличную информацию.

Ссылки, которые я подтвердил до сих пор, которые используют stdole.dll (возможно, больше офисных программ)

• Офис

• Excel

• Core

• Crystal Reports (спасибо Lithium. Как указывает Nick, у вас может не быть преимущества установки Embed Interop Types=true)

Если вы найдете больше, добавьте их в этот список или заметьте в комментариях, и я сделаю это.

Hans Passant категорически не рекомендуется Embed Interop Types=false здесь: В чем разница. Вставить Interop Типы true и false в Visual Studio?

Ответ 2

Как указывалось другими словами, stdole.dll - это первичная сборка Interop для группы компонентов COM-взаимодействия Office COM. Вы можете определить, почему он входит в ваш проект, выполнив следующие действия.

В Visual Studio перейдите к Tools > Options > Projects and Solutions > Build and Run. Измените параметр "Объём вывода сборки проекта MSBuild" на Detailed. Теперь очистите и перестройте свой проект.

Откройте окно вывода и выполните поиск stdole. Вы должны найти такой раздел:

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

Вы можете увидеть, где Visual Studio искала сборку, а также то, что требует ее внизу. В моем случае это куча старых сборок Crystal Reports.

Иногда вы можете встраивать типы interop через зависимости, как предлагает Тони, но не всегда. Для меня сборки Crystal Reports не поддерживают это.

Я исправил эту проблему (и упоминал коварный один scottsanpedro), скопировав stdole.dll (32 КБ, с цифровой подписью) из C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\ в папку "Зависимости" внутри моего проекта. Я добавил файл в свой проект и добавил явную ссылку на него (Добавить ссылку > Обзор). Наконец, я открыл новые ссылочные свойства и установил Embed Interop Types в True.

Кажется, это лучшая ситуация. Мне не нужно беспокоиться о получении неподписанной версии сборки.

Ответ 3

Я занимаюсь этой проблемой целую вечность.

Всякий раз, когда я устанавливаю что-либо с веб-платформы или любых обновлений, stdole.dll заменяется не подписанной версией. Я сообщил об ошибке в Microsoft некоторое время назад, но упал на глухие уши.

Я перехожу к C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies и копирую подписанную версию (22kb) отсюда и заменяю версию в C:\Program Files (x86)\Microsoft Visual Studio 14.0\Visual Studio Tools for Office\PIA\Common (16kb), и это решает проблему.

Скотт

Ответ 4

В моей ситуации я обнаружил, что переключает свойство Copy Local сборки, которое зависит от stdole.dll, сохраняя проект, а затем переключая свойство обратно на его исходное значение, и, наконец, сохранение проекта снова решило проблему. Это свойство также может быть связано с свойством Embed Interop Types для других людей с этой проблемой.

Что это делает, явным образом сохраняет свойство Copy Local в файле .xxproj. В противном случае состояние этого свойства отсутствует в файле проекта и предполагается значение по умолчанию. У меня нет объяснений, почему это работает, поскольку наличие свойства в файле проекта не изменяет отображаемое значение в Visual Studio и не вызывает изменения в сборке, которая фактически публикуется или нет. Я также не вызывал изменения этих свойств из их первоначально отображаемых значений после переключения их туда и обратно.

Я замечаю, что еще до того, как я нашел лекарство, я увидел, что очистка проекта и его восстановление не привели к тому, что stdole.dll будет скопирован в корзину. Только после публикации появилось stdole.dll.