Outlook 2010的插件建设时FindRibbons任务意外失败 [英] FindRibbons task failed unexpectedly when building addin for Outlook 2010

查看:1067
本文介绍了Outlook 2010的插件建设时FindRibbons任务意外失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在建设使用VS2013的Outlook 2010的插件,.NET4,微软异步和BCL便携性(从的NuGet)和建设遇到类似的这个问题并的这个论坛讨论遗憾的是这些资源(或网络的其余部分)都没有帮助解决我们的问题。



生成错误和Fusion日志处于底部。我的第一个问题:




怎样才能解决此FindRibbons建设任务吗?完全从VS目标文件中删除它允许构建完成,但无色带控制为代价的。




二症状我们已经是融合日志尝试下载部分。该DLL被我们的项目下建造的 bin\Debug 目录中,以便其他目录搜索是奇数。这引起了我的第二个问题:




是否有融合日志症状,我们正在俯瞰


<? /块引用>

最后一个症状是从详细的生成日志,我们看到mscorlib程序,System.Core程序和几个其他库之间的冲突。这些依赖关系通过BCL,等进来和4.0.0.0与2.0.5.0冲突似乎是,可以防止构建或生成一个FileNotFoundException异常。我们尝试了一些补救措施,以结合重定向等,但不能使这项工作。所以最后一个问题:




解决方案和故障排除提示此版本构建冲突?




在预先感谢。很抱歉的长度。



作为承诺的构建失败:

 错误1FindRibbons 任务意外失败。 
System.IO.FileNotFoundException:未能加载文件或程序集myDocketOutlookAddIn,版本= 1.0.0.0,文化=中性公钥= null或它的一个依赖。该系统找不到指定的文件。
档名:myDocketOutlookAddIn,版本= 1.0.0.0,文化=中立,公钥=空'

服务器堆栈跟踪:在System.Reflection.RuntimeAssembly._nLoad
(的AssemblyName文件名,字符串的代码库,证据assemblySecurity,RuntimeAssembly locationHint,StackCrawlMark&安培; stackMark,IntPtr的pPrivHostBinder,布尔throwOnFileNotFound,布尔forIntrospection,布尔suppressSecurityChecks)
在System.Reflection.RuntimeAssembly.nLoad(的AssemblyName文件名,字符串的代码库,证据assemblySecurity,RuntimeAssembly locationHint,StackCrawlMark&安培; stackMark,IntPtr的pPrivHostBinder,布尔throwOnFileNotFound,布尔forIntrospection,布尔suppressSecurityChecks)
在System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(的AssemblyName assemblyRef,证据assemblySecurity,RuntimeAssembly reqAssembly,StackCrawlMark&安培; stackMark,IntPtr的pPrivHostBinder,布尔throwOnFileNotFound,布尔forIntrospection,布尔suppressSecurityChecks)
在System.Reflection.RuntimeAssembly.InternalLoad(字符串assemblyString,证据assemblySecurity,StackCrawlMark&安培; stackMark,IntPtr的pPrivHostBinder,布尔forIntrospection)
在System.Reflection.RuntimeAssembly.InternalLoad(字符串assemblyString,证据assemblySecurity,StackCrawlMark&安培; stackMark,布尔forIntrospection)
在System.Reflection.Assembly.Load(字符串assemblyString)
在System.UnitySerializationHolder.GetRealObject(的StreamingContext上下文)
在System.Runtime.Serialization.ObjectManager.ResolveObjectReference(持有的ObjectHolder)
在System.Runtime.Serialization.ObjectManager.DoFixups()
在System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler处理器,__BinaryParser serParser,布尔FCHECK,布尔isCrossAppDomain,IMet​​hodCallMessage methodCallMessage)
在System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (流serializationStream,HeaderHandler处理器,布尔FCHECK,布尔isCrossAppDomain,IMet​​hodCallMessage methodCallMessage)
在System.Runtime.Remoting.Channels.CrossAppDomainSerializer.DeserializeObject(MemoryStream的STM)
在System.Runtime.Remoting.Messaging.SmuggledMethodReturnMessage在System.Runtime.Remoting
:.FixupForNewAppDomain()在System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage
(即时聊天reqMsg)

异常的[0]重新抛出。 Proxies.RealProxy.HandleReturnMessage(即时聊天reqMsg,即时聊天retMsg)
在System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&安培; MSGDATA,的Int32型)美元,Microsoft.Build.Framework.ITask.Execute()
在Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
在B点$ B C::Microsoft.Build.BackEnd.TaskBuilder< ExecuteInstantiatedTask> d__20.MoveNext()

大会经理从加载\Windows\Microsoft.NET\Framework\v4.0.30319\ clr.dll
下可执行的C运行:\Program文件(x86)\MSBuild\12.0\bin\MSBuild.exe
---详细的错误日志如下。

===预绑定状态信息===
日志:显示名称= myDocketOutlookAddIn,版本= 1.0.0.0,文化=中立,公钥=空
(完全指定)
日志:应用平台=文件:/// C:/ Program Files文件(x86)的/MSBuild/12.0/bin/
日志:DEVPATH = C:\ProgramData\Red Gate\.NET Reflector\DevPath
日志:初始PrivatePath = NULL
调用汇编:(未知)。
===
日志:此绑定的默认加载上下文开始。
日志:使用应用程序配置文件:C:\Program文件(x86)\MSBuild\12.0\bin\MSBuild.exe.Config
日志:使用主机配置文件:
日志:从C使用计算机配置文件:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config。
日志:没有被应用政策在这个时候(私人,自定义,局部的,或基于位置的程序集绑定)来引用。
日志:/// C:/ Program Files文件(x86)的/MSBuild/12.0/bin/myDocketOutlookAddIn.DLL新的URL文件的尝试下载。
日志:/// C:/ Program Files文件(x86)的/MSBuild/12.0/bin/myDocketOutlookAddIn/myDocketOutlookAddIn.DLL新的URL文件的尝试下载。
日志:/// C:/ Program Files文件(x86)的/MSBuild/12.0/bin/myDocketOutlookAddIn.EXE新的URL文件的尝试下载。
日志:/// C:/ Program Files文件(x86)的/MSBuild/12.0/bin/myDocketOutlookAddIn/myDocketOutlookAddIn.EXE新的URL文件的尝试下载。

和内部版本冲突摘录:

 之间存在着冲突mscorlib程序,版本= 4.0.0.0,文化=中性公钥= b77a5c561934e089和mscorlib程序,版本= 2.0.5.0,文化=中性公钥= 7cec85d7bea7798e,重定目标=是。 (TASKID:7)
mscorlib程序,版本= 4.0.0.0,文化=中性公钥= b77a5c561934e089被选中,是因为它是初级和mscorlib程序,版本= 2.0.5.0,文化=中性公钥= 7cec85d7bea7798e,重定目标=是没有。 (TASKID:7)
引用依赖于mscorlib程序,版本= 4.0.0.0,文化=中性公钥= b77a5c561934e089[C:\Program文件(x86)\Reference Assemblies\Microsoft\Framework \.NETFramework\v4.0\mscorlib.dll。 (TASKID:7)
C:\Program文件(x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll(TASKID:7)
类项目文件项目包括引起参考C:\Program文件(x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll。 (TASKID:7)
System.Net.Http.Formatting,版本= 4.0.0.0,文化=中性公钥= 31bf3856ad364e35,的ProcessorArchitecture = MSIL(TASKID:7)
Microsoft.Office.Tools.Common .v4.0.Utilities,版本= 10.0.0.0,文化=中性公钥= b03f5f7f11d50a3a,的ProcessorArchitecture = MSIL(TASKID:7)



号这靠mscorlib程序,版本= 2.0.5.0,文化=中性公钥= 7cec85d7bea7798e,重定目标=是[]。 (TASKID:7)
C:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\lib\\\
et40\System.IO.dll(TASKID:7)
类项目文件项目包括引起参考C:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\lib\\\
et40\System.IO.dll。 (TASKID:7)
System.IO(TASKID:7)
C:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\lib\\\
et40\\ \\System.Threading.Tasks.dll(TASKID:7)
项目文件项目包括引起参考C:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\ lib\\\
et40\System.Threading.Tasks.dll。 (TASKID:7)
Microsoft.Threading.Tasks(TASKID:7)

这种模式,然后重复了System.Core程序,系统和System.Net


解决方案

您需要删除 SecurityTransparent 的AssemblyInfo.cs 文件末尾属性。


We're building an Outlook 2010 plugin using VS2013, .NET4, Microsoft Async and BCL Portability (from Nuget) and encountering build errors similar to this question and this forum discussion unfortunately neither of these resources (or the rest of the internet) have helped resolve our problem.

The build error and Fusion log are at bottom. My first question:

How does one troubleshoot this FindRibbons build task? Removing it entirely from the VS targets file allows the build to complete, but at the expense of no ribbon controls.

The second symptom we have is the Attempting download section of the Fusion log. The DLL gets built under our project bin\Debug directory so the other directory search is odd. Which raises my second question:

Are there symptoms in the Fusion log that we're overlooking?

The last symptom is from the detailed build log where we see conflicts between mscorlib, System.Core and a couple other libraries. These dependencies come in via the Bcl, etc. and the 4.0.0.0 vs. 2.0.5.0 conflict seems like that could prevent a build or generate a FileNotFoundException. We tried a number of remedies with binding redirection, etc. but couldn't make this work. So last question:

Solutions or troubleshooting tips for this version build conflict?

Many thanks in advance. Sorry for the length.

As promised the build failure:

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

Server stack trace: 
    at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
    at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
    at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
    at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
    at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
    at System.Reflection.Assembly.Load(String assemblyString)
    at System.UnitySerializationHolder.GetRealObject(StreamingContext context)
    at System.Runtime.Serialization.ObjectManager.ResolveObjectReference(ObjectHolder holder) 
    at System.Runtime.Serialization.ObjectManager.DoFixups()
    at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
    at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
    at System.Runtime.Remoting.Channels.CrossAppDomainSerializer.DeserializeObject(MemoryStream stm)
    at System.Runtime.Remoting.Messaging.SmuggledMethodReturnMessage.FixupForNewAppDomain()
    at System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage(IMessage reqMsg)

Exception rethrown at [0]: 
    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
    at Microsoft.Build.Framework.ITask.Execute()
    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = myDocketOutlookAddIn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
LOG: DEVPATH = C:\ProgramData\Red Gate\.NET Reflector\DevPath
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/myDocketOutlookAddIn.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/myDocketOutlookAddIn/myDocketOutlookAddIn.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/myDocketOutlookAddIn.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/myDocketOutlookAddIn/myDocketOutlookAddIn.EXE.

And the build version conflict excerpt:

There was a conflict between "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes". (TaskId:7)
      "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes" was not. (TaskId:7)
      References which depend on "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll]. (TaskId:7)
          C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll (TaskId:7)
            Project file item includes which caused reference "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll". (TaskId:7)
              System.Net.Http.Formatting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL (TaskId:7)
              Microsoft.Office.Tools.Common.v4.0.Utilities, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL (TaskId:7)

 ...

      References which depend on "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes" []. (TaskId:7)
          c:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\lib\net40\System.IO.dll (TaskId:7)
            Project file item includes which caused reference "c:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\lib\net40\System.IO.dll". (TaskId:7)
              System.IO (TaskId:7)
          c:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\lib\net40\System.Threading.Tasks.dll (TaskId:7)
            Project file item includes which caused reference "c:\code\Projects\myDocketForOutlook\packages\Microsoft.Bcl.1.1.9\lib\net40\System.Threading.Tasks.dll". (TaskId:7)
              Microsoft.Threading.Tasks (TaskId:7)

This pattern then repeats for System.Core, System, and System.Net

解决方案

You need to remove the SecurityTransparent attribute from the end of the AssemblyInfo.cs file.

这篇关于Outlook 2010的插件建设时FindRibbons任务意外失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆