Ошибка привязки сборки при создании надстройки Office: задача "FindRibbons" неожиданно завершилась неудачей

Ответ 1

Если вы перенесли проект из предыдущей версии Visual Studio, обязательно удалите атрибуты ExcelLocale1033 и SecurityTransparent из файла AssemblyInfo.cs(как ответил Свати в этом другом вопросе )

Если проект по-прежнему не удается выполнить, это может быть связано с тем, что ваш файл .csproj имеет некоторые ссылки на задачи msbuild предыдущих версий Visual Studio. Я предлагаю вам создать новый пустой проект Add Add и использовать структуру msbuild нового файла проекта в качестве базы для вашего проекта.

Ответ 2

У меня была эта проблема. Это, по-видимому, было вызвано тем, что я изменил настройку "Копировать локальную" на ссылку "Microsoft.Office.Tools.Common.v4.0.Utilities" от True до False. ISYN. (Я не хочу тебя)

Я обновил проект от VS2012 до VS2013 и заметил, что эта ссылка была единственной, которая была установлена ​​в "Копировать локально = True". Поэтому я установил его в false, потому что он был другим. Это вызвало ошибку. Сменив его на True, он решил.

Ответ 3

Это работало для меня каждый раз, когда я обновляю Visual Studio - я не использую ленты btw.

Это сработало для моего решения, но используйте на свой страх и риск:

• Откройте следующий файл в редакторе xml (сначала сделайте резервную копию): C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets (часть v10.0 может отличаться для вас, например, она может быть v14.0)

• Удалите следующий раздел:

  <FindRibbons AssemblyName="$(AbsolutePathToCustomization)" TargetFramework="$(TargetFrameworkVersion)">
      <Output TaskParameter="RibbonTypes" ItemName="RibbonTypesCollection"/>
  </FindRibbons> 
  

• Замените все вхождения "@(RibbonTypesCollection)" на "" 4. Сохраните файл и перезапустите визуальную студию

Ответ 4

У меня было то же сообщение об ошибке, и я наконец нашел исправление. Проблема возникла из-за того, что проект VSTO предназначен для .NET 4.0 (кажется, это минимум для VSTO4), а также ссылается на сборку, созданную для .NET 3.5. Настоящим виновником было то, что у меня был класс в проекте VSTO, производный от интерфейса, определенного в сборке .NET 3.5, который, в свою очередь, был получен из интерфейса библиотеки .NET 3.5. т.е.

   using System.Xml;
   class MyVSTOClass : IMy35AssembyInterface // This caused the error
   class MyVSTOClass : IXmlSerializable      // This compiled OK 

   using System.Xml;
   interface IMy35AssembyInterface : IXmlSerializable

Исправление заключалось в обновлении .csproj для явной ссылки на более старую версию System.Xml.dll и System.Data.dll, которая в противном случае по умолчанию была бы 4.0 и конфликтовала со ссылками на сборки 3.5.

  <Reference Include="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <!--<Aliases>Data2</Aliases>-->
      <HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll</HintPath>
      <SpecificVersion>True</SpecificVersion>
      <Private>False</Private>
    </Reference>

 <Reference Include="System.XML, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <!--<Aliases>Xml2</Aliases>-->
      <HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll</HintPath>
      <SpecificVersion>True</SpecificVersion>
      <Private>False</Private>
    </Reference>

Для тех, кому нужно одновременно ссылаться как на новую, так и на более старую версии DLL, обратите внимание, что теоретически это возможно с помощью:

extern alias XmlDll1
using XmlDll1::System.Xml

См. Http://geekswithblogs.net/narent/archive/2008/11/11/126940.aspx для получения дополнительной информации.

Ответ 5

У меня была такая же ошибка, и ни один из ответов из Интернета не помог мне решить эту проблему. Причина, по которой я получал эту ошибку, заключается в том, что я ссылался на сборку типа Console Application. Я изменил эту сборку типа ClassLibrary, и у меня не было этого исключения больше.

Кроме того, я получал бы это исключение только при наследовании от класса, который был расположен на моем ConsoleApplication. Мне потребовалось время, чтобы понять это.

Ответ 6

Эта проблема также может быть вызвана добавлением ссылки на неподписанную сборку на проект с надписью/сильным именем надстройки. В моем случае я добавил пакет RestSharp Nuget и начал получать эту ошибку при сборке, как только я ссылаюсь на RestSharp в коде. После некоторого рытья я заметил, что RestSharp был единственной беззнаковой сборкой в ​​ссылках на проект. Если у вас есть эта проблема, есть 3 возможных решения:

• В случае RestSharp я обнаружил, что в Nuget есть подписанная версия, которая искала "подписанный restsharp" и установила эту проблему.
• Если у вас есть доступ к исходному коду, вы можете настроить Visual Studio на создание подписанной версии сборки на странице "Свойства проекта".
• Если у вас нет доступа к исходному коду, вы можете подписать сборку своим ключом, следуя этим инструкциям.

Ответ 7

Может быть, немного поздно здесь, но я только решил это для себя - после нескольких многочисленных предложений (через google), все из которых не решили мою проблему, я вручную спустился вниз. Оказывается, я скомпилировал набор библиотек с зависимой сборкой с более низкой версией (не последней). В моем основном проекте у меня также была ссылка на эту зависимость, но она была вытащена через nuget и была последней и самой большой версией. По какой-то причине VS.NET не мог понять, что произойдет, и полностью исчезнет и выведет сообщение об ошибке. Как только я обновил набор библиотек до последней версии зависимости, все работало нормально.

Сумасшедшая часть - это сработало отлично, а затем из ниоткуда проблема возникла. Надеюсь, это поможет кому-то на этом пути.

После включения Fusion вывод показал, что он ищет сборку в папке msbuild/.

Ответ 8

У меня была такая же проблема, и даже после прочтения ответа KKG я не смог решить мою проблему.

Это оказалось намного проще для меня, но не менее разочаровывало и занимало много времени. Я работал в Win8.1 VM, который по умолчанию не отправляет с .net3.5. Мой проект .net4 VSTO4 ссылался на сборку, где где-то 3.5. Тот же проект скомпилировал find на моей другой виртуальной машине, которая была Server2008 и имела 3.5 включенных.

Ответ 9

В моем случае причиной этой ошибки было просто наличие в сборке поля типа универсального значения (не шутка), например:

  class Foo
  {
    ImmutableArray<int> foo;
  }

Обходной путь (если дополнительная косвенность приемлема с точки зрения производительности):

Оберните тип значения в ссылочный тип. Это может быть сделано в общем с чем-то вроде

  public sealed class Box<T>
  {
    public readonly T value;

    public Box(T value)
    {
      this.value = value;
    }
  }

тогда foo может иметь тип Box<ImmutableArray<int>>.

Ответ 10

Я только что столкнулся с такой же ситуацией сегодня, немного суетясь, перезагружая VS, а затем перезагружая мою машину без какого-либо успеха. После меня появилось одно предупреждение. Одно из моих зависимых собраний не имело сильного имени. Установка этой сборки на строгое имя решила проблему.

Ответ 11

В моем случае это происходило из-за того, что один из типов в проекте VSTO реализовывал интерфейс в другой сборке (где другие случаи использования этой же сборки в VSTO проходили нормально).

Ответ 12

У меня возникла такая же проблема с надстройкой для Outlook.

Решение для меня было установить Embed Interop Types в True на моей ссылкой на Office.dll.

Это, однако, привело к аварийному завершению работы надстройки при отказе в Access Denied в Microsoft.Office.Interop.Outlook. Я исправил эту проблему, установив для параметра " Embed Interop Types значение " True для всех ссылок на Microsoft.Office.Interop.Outlook.dll.