构建Office加载项时出现程序集绑定错误：“FindRibbons”任务意外失败
我们正在尝试设置一个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)Fusion日志条目WhereRefBind!Host=(LocalMachine)!FileName=(PresentationCore.dll)和ExplicitBind!FileName=(MyAddIn.dll)，显示绑定成功。 - 无论我是从命令行使用Visual Studio还是MSBuild来构建项目，都会在构建服务器上出现此错误。
- 我确保我的开发机器和构建服务器上的.NET / MSBuild / VS2012版本相同，但仍然会出现错误。 唯一的区别似乎是构建服务器运行的是Windows Server 2012（因为它是Azure，我们无法启动Windows 7映像）。
如果从以前版本的Visual Studio迁移项目，请确保从AssemblyInfo.cs文件中删除ExcelLocale1033和SecurityTransparent属性（在另一个问题中由Swati 回答 ）
如果项目仍然无法构建，可能是因为.csproj文件对msbuild以前版本的Visual Studio的任务有一些引用。 我建议您创建一个新的空Excel Excel项目，并使用新项目文件的msbuild结构作为项目的基础。
每次升级Visual Studio时这对我都有用 – 我不使用色带btw。
这适用于我的解决方案，但使用风险由您自行承担：
- 在xml编辑器中打开以下文件（首先进行备份）：
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets（v10.0）部分可能与您不同，例如它可能是v14.0） -
删除以下部分：
-
将所有出现的
"@(RibbonTypesCollection)"替换为“”4。保存文件并重新启动visual studio
我有这个问题。 这显然是因为我将引用“Microsoft.Office.Tools.Common.v4.0.Utilities”中的“复制本地”设置从True更改为False。 ISYN。 （我不是吗）
我已经将一个项目从VS2012升级到VS2013，并注意到该引用是唯一设置为“Copy Local = True”的引用。 所以我把它设置为假，因为它是不同的。 这导致了错误。 将它改回True可以解决它。
我有相同的错误消息，最后找到了一个修复程序。 问题源于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程序集引用冲突。
C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll True False C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll True False
对于那些需要同时引用DLL的新版本和旧版本的人，请注意理论上可以使用：
extern alias XmlDll1 using XmlDll1::System.Xml
有关详细信息，请参阅http://geekswithblogs.net/narent/archive/2008/11/11/126940.aspx 。
我有同样的错误，没有来自互联网的答案帮助我解决这个问题。 我之所以收到该错误，是因为我引用的是Console Application类型的Console Application 。 我将该程序集更改为ClassLibrary类型，我没有再得到该exception。
此外，我只会从inheritance自我的ConsoleApplication上的类时获得该exception。 我花了很长时间才弄明白。
可能有点晚了，但我刚刚为自己解决了这个问题 – 在遵循了许多建议（通过谷歌）后，所有这些都没有解决我的问题，我手动下线了。 结果我编译了一组库，其中包含一个具有较低版本（不是最新版本）的依赖程序集。 在我的主项目中，我也引用了这种依赖，但是它是通过nuget提取的，并且是最新版本。 出于某种原因，VS.NET无法解决这个问题，并且会完全跳出并丢弃您发布的错误。 一旦我将库集更新为最新版本的依赖项，所有工作都正常。
疯狂的部分是 – 它最初运作良好，然后突然出现问题。 希望这可以帮助一路上的人。
启用Fusion后，输出显示它正在msbuild /文件夹中查找程序集。
将无符号程序集的引用添加到已签名/强名称的加载项项目也可能导致此问题。 在我的情况下，我添加了RestSharp Nuget包，并在代码中引用RestSharp后立即开始在构建时收到此错误。 经过一番挖掘后，我注意到RestSharp是项目引用中唯一的无符号程序集。 如果您有这个问题，有3种可能的解决方案：
- 在RestSharp的情况下，我发现Nuget上有一个签名版本 – 搜索“restsharp signed”并安装解决了这个问题。
- 如果您有权访问源代码，则可以将Visual Studio配置为在“项目属性”页面中构建程序集的签名版本。
- 如果您无权访问源代码，则可以按照这些说明使用自己的密钥对程序集进行签名。
我有同样的问题，即使在阅读了KKG的答案后，我也无法解决我的问题。
事实certificate这对我来说简单得多，但同样令人沮丧和耗时。 我在Win8.1 VM中工作，默认情况下不附带.net3.5。 我的.net4 VSTO4项目引用了一个需要3.5的程序集。 同一个项目编译在我的其他VM上查找，它是Server2008并启用了3.5。
在我的例子中，这个错误的原因是在程序集中只存在generics值类型的字段（而不是开玩笑），例如：
class Foo { ImmutableArray foo; }
解决方法（如果额外的间接在性能方面是可接受的）：
将值类型包装在引用类型中。 这通常可以用类似的东西来完成
public sealed class Box { public readonly T value; public Box(T value) { this.value = value; } }
那么foo可以是Box 。
我今天刚遇到同样的情况，有点困难，重新启动VS然后重启我的机器没有任何成功。 不止一个警告突然出现在我身上 – 我的一个依赖集会并没有强大的命名。 将该程序集设置为强名称解决了该问题。