构建 Office 加载项时的程序集绑定错误：“FindRibbons”任务意外失败答案

【问题标题】：Assembly binding error when building Office add-in: "FindRibbons" task failed unexpectedly构建 Office 加载项时的程序集绑定错误：“FindRibbons”任务意外失败
【发布时间】：2013-12-11 18:29:26
【问题描述】：

我们正在尝试设置 Jenkins（构建服务器）作业来构建基于 VSTO 的 Office 加载项。但是，在将 DLL 复制到项目的bin 目录后，我不断收到一个奇怪的错误，即构建过程失败：

Error 11 The "FindRibbons" task failed unexpectedly.
System.IO.FileNotFoundException:
  Could not load file or assembly 'MyAddIn, Version=1.0.0.0, Culture=neutral, 
  PublicKeyToken=null' or one of its dependencies.
  The system cannot find the file specified.
File name: 'MyAddIn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

所以问题是由 Office 加载项构建目标触发的“FindRibbons”任务已成功将 MyAddIn DLL 识别为 Office 加载项，但无法找到并加载它！

有什么想法吗？我希望能够直接调试 FindRibbons 任务，但挂钩和调试编译过程似乎有点极端......

以下是一些观察：

在我们用于绑定 MyAddIn 程序集的构建服务器的 Fusion 日志中，它看起来像是在 MSBuild.exe 所在的文件夹 (C:\Windows\Microsoft.NET\Framework\v4.0.30319\) 中查找，而在其他任何地方都没有。在我的开发机器上，MyAddIn 没有 Fusion 日志条目！但构建过程成功并且 Kivo 工作正常。
在我的开发和构建机器上，我还有 WhereRefBind!Host=(LocalMachine)!FileName=(PresentationCore.dll) 和 ExplicitBind!FileName=(MyAddIn.dll) 的 Fusion 日志条目，显示绑定成功。
无论我是使用 Visual Studio 还是命令行中的 MSBuild 来构建项目，构建服务器都会出现此错误。
我已确保 .NET/MSBuild/VS2012 版本在我的开发机器和构建服务器上是相同的，并且错误仍然存在。唯一的区别似乎是构建服务器运行的是 Windows Server 2012（因为它是 Azure，我们无法启动 Windows 7 映像）。

【问题讨论】：

试试这个 - 13.64.155.221/comments/574521/view.html

标签： c# .net visual-studio-2012 msbuild jenkins

【解决方案1】：

如果您从以前版本的 Visual Studio 迁移项目，请务必从 AssemblyInfo.cs 文件中删除 ExcelLocale1033 和 SecurityTransparent 属性（由 Swati 回答在这另一个question)

如果项目仍然无法构建，可能是因为您的 .csproj 文件中引用了以前版本的 Visual Studio 的 msbuild 任务。我建议你创建一个新的空 Excel AddIn 项目，并使用新项目文件的 msbuild 结构作为项目的基础。

【讨论】：

是的，我从 VS 2010 迁移到 VS 2012。删除“SecurityTransparent”有帮助，谢谢！
这也是我的问题。谢谢！！

【解决方案2】：

我遇到了这个问题。这显然是因为我将参考“Microsoft.Office.Tools.Common.v4.0.Utilities”上的“复制本地”设置从 True 更改为 False。同步。（我不骗你）

我已将一个项目从 VS2012 升级到 VS2013，并注意到该引用是唯一设置为“Copy Local = True”的引用。所以我把它设置为假，因为它是不同的。这导致了错误。将其改回 True 即可解决。

【讨论】：

对不起。这不是我写的文字。 WTF 有人在“编辑”我的评论？
几乎任何人都可以编辑帖子以使其更清晰或修复错误。历史记录被保留，如果恶意可以恢复。
我在设置 CopyLocal = False 时遇到了同样的问题。我不想拥有程序集的本地副本，我该怎么办？

【解决方案3】：

这对我每次升级 Visual Studio 时都有效 - 顺便说一句，我不使用功能区。

这适用于我的解决方案，但使用风险自负：

在 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. 保存文件并重新启动visual studio

【讨论】：

3 年后这似乎仍然是一个错误！
Microsoft.VisualStudio.Tools.Office.targets(349,5): 错误：添加自定义失败。

【解决方案4】：

我收到了同样的错误信息，终于找到了解决办法。问题源于针对 .NET 4.0 的 VSTO 项目（这似乎是 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】：

此问题也可能是由于将未签名程序集的引用添加到已签名/强命名的加载项项目中。就我而言，我添加了 RestSharp Nuget 包，并在我在代码中引用 RestSharp 后立即开始在构建时收到此错误。经过一番挖掘，我注意到 RestSharp 是项目引用中唯一未签名的程序集。如果您遇到此问题，有 3 种可能的解决方案：

就 RestSharp 而言，我发现 Nuget 上有可用的签名版本 - 搜索“restsharp signed”并安装解决了问题。
如果您有权访问源代码，则可以配置 Visual Studio 以在“项目属性”页面中构建程序集的签名版本。
如果您无权访问源代码，您可以按照these instructions 使用自己的密钥对程序集进行签名。

【讨论】：

【解决方案6】：

我遇到了同样的错误，互联网上的答案都没有帮助我解决这个问题。我收到该错误的原因是因为我引用了Console Application 类型的程序集。我将该程序集更改为 ClassLibrary 类型，并且不再遇到该异常。

此外，我只会在从位于我的 ConsoleApplication 上的类继承时得到该异常。我花了很长时间才弄清楚。

【讨论】：

【解决方案7】：

这里可能有点晚了，但我只是为自己解决了这个问题 - 在遵循了许多建议（通过谷歌）之后，所有这些都没有解决我的问题，我手动下线了。原来我已经编译了一组库，其中包含一个较低版本（不是最新版本）的依赖程序集。在我的主要项目中，我也引用了此依赖项，但它是通过 nuget 提取的，并且是最新和最好的版本。出于某种原因，VS.NET 无法解决这个问题，并且会完全跳出并删除您发布的错误。一旦我将一组库更新到最新版本的依赖项，一切都会正常工作。

疯狂的部分是 - 它最初运行良好，然后突然出现问题。希望这对一路上的人有所帮助。

启用 Fusion 后，输出显示它正在 msbuild/ 文件夹中查找程序集。

【讨论】：

是的，使用 nuget update-package 更新我的所有软件包为我解决了这个错误。谢谢:)

【解决方案8】：

我今天刚遇到同样的情况，折腾了一会儿，重新启动 VS，然后重新启动我的机器，但没有任何成功。不止一个警告出现在我身上——我的一个依赖程序集没有强命名。将该程序集设置为强名称解决了这个问题。

【讨论】：

在我的项目中检查了Sign Assembly 并得到了上述错误。找到没有强名称的 dll。得到源签名/编译/引用它。谢谢！

【解决方案9】：

我遇到了同样的问题，即使在阅读了 KKG 的回答后，我也无法解决我的问题。

结果对我来说要简单得多，但同样令人沮丧和耗时。我在默认情况下不附带 .net3.5 的 Win8.1 VM 中工作。我的 .net4 VSTO4 项目在某处引用了一个需要 3.5 的程序集。在我的另一个 VM 上编译的相同项目是 Server2008 并启用了 3.5。

【讨论】：

【解决方案10】：

在我的例子中，这个错误的原因仅仅是程序集中存在一个通用值类型的字段（不是开玩笑），例如：

  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>> 类型。

【讨论】：

【解决方案11】：

我在使用 Outlook 加载项时遇到了同样的问题。

我的解决方案是在我对Office.dll 的引用上将Embed Interop Types 设置为True。

但是，这会导致加载项在 Microsoft.Office.Interop.Outlook 上以 Access Denied 启动时崩溃。我通过在对Microsoft.Office.Interop.Outlook.dll 的所有引用上将Embed Interop Types 设置为True 来解决该问题。

【讨论】：

【解决方案12】：

此错误可能是由依赖版本冲突引起的。例如：

YourAddIn
  --  OtherLibrary v1.3
      --  BaseLibrary v1.0
  --  BaseLibrary v2.0

如果在您的项目中发布并更新了较新版本的BaseLibrary v2.0，但是此版本在您的其他依赖项OtherLibrary 中引入了重大更改，您将看到此异常，因为OtherLibrary 仍在尝试找到新程序集中不存在的旧方法。

使用最新软件包更新 OtherLibrary 将解决依赖版本的冲突。

【讨论】：

【解决方案13】：

如果Microsoft.Office.Tools.Outlook.v4.0.Utilities 引用设置为<Private>False</Private>，也会发生这种情况。

<Reference Include="Microsoft.Office.Tools.Outlook.v4.0.Utilities">
  <!-- Required for FindRibbons task -->
  <Private>True</Private>
</Reference>

【讨论】：