Question

我们正在尝试设置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任务，但挂钩并调试编译过程似乎有点极端......

以下是一些观察结果：

在我们的构建服务器的Fusion日志中，用于绑定MyAddIn程序集，看起来它正在查找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映像）。

Answer 1

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

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

Answer 2

我有这个问题。这显然是因为我改变了＃34;复制本地＆＃34;设置参考＆＃34; Microsoft.Office.Tools.Common.v4.0.Utilities＆＃34;从真到假。 ISYN。（我不喜欢）

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

Answer 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)"替换为＆＃34;＆＃34; 4.保存文件并重新启动visual studio

Answer 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。

Answer 5

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

此外，我只会在从我的ConsoleApplication上的类继承时获得该异常。我花了很长时间才弄明白。

Answer 6

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

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

Answer 7

这里可能有点晚了，但我刚刚解决了这个问题 - 在遵循了许多建议（通过谷歌）后，所有这些都没有解决我的问题，我手动排队。结果我编译了一组库，其中包含一个具有较低版本（不是最新版本）的依赖程序集。在我的主项目中，我也引用了这种依赖，但它是通过nuget引出的，并且是最新的＆amp;最好的版本。出于某种原因，VS.NET无法解决这个问题，并且会完全跳出并丢弃您发布的错误。一旦我将这组库更新到最新版本的依赖项，所有工作都正常。

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

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

Answer 8

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

事实证明这对我来说简单得多，但并不沮丧和耗时。我在Win8.1 VM中工作，默认情况下不附带.net3.5。我的.net4 VSTO4项目引用了一个需要3.5的程序集。同一项目编译在我的其他VM上查找，该服务器是Server2008并启用了3.5。

Answer 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>>。

Answer 10

我今天也遇到了同样的情况，摸索了一下，重新启动VS，然后重新启动计算机，但没有成功。突然有一个警告向我扑来-我的一个依存集会的名字不强。将该程序集设置为强名称即可解决问题。

Answer 11

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

对我来说，解决方案是在引用Embed Interop Types时将True设置为Office.dll。

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

Answer 12

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

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

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

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

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

12 个答案: