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

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工作正常.
• 在我的开发和构建机器上,我也有Fusion日志条目,WhereRefBind!Host=(LocalMachine)!FileName=(PresentationCore.dll)并ExplicitBind!FileName=(MyAddIn.dll)显示绑定成功.
• 无论我是从命令行使用Visual Studio还是MSBuild来构建项目,都会在构建服务器上出现此错误.
• 我确保我的开发机器和构建服务器上的.NET/MSBuild/VS2012版本完全相同,但仍然会出现错误.唯一的区别似乎是构建服务器运行的是Windows Server 2012(因为它是Azure,我们无法启动Windows 7映像).

Answer 1

如果从以前版本的Visual Studio迁移项目,请确保从AssemblyInfo.cs文件中删除ExcelLocale1033和SecurityTransparent属性(在另一个问题中由Swati 回答)

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

Answer 2

我有这个问题.这显然是因为我将引用"Microsoft.Office.Tools.Common.v4.0.Utilities"中的"复制本地"设置从True更改为False.ISYN.(我不是吗)

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

Answer 3

每次我升级Visual Studio时这都适用于我 - 我不使用色带顺便说一句.

这适用于我的解决方案,但使用风险由您自行承担:

1. 在xml编辑器中打开以下文件(首先进行备份):( C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetsv10.0部分可能与您不同,例如它可能是v14.0)

2. 删除以下部分:

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

3. "@(RibbonTypesCollection)"用"" 替换所有出现的内容.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

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

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

Answer 6

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

疯狂的是——一开始运行得很好，然后突然出现了问题。希望这对某人有所帮助。

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