升级 NServiceBus 后“找不到程序集”答案

【问题标题】："Unable to find assembly" after upgrading NServiceBus升级 NServiceBus 后“找不到程序集”
【发布时间】：2012-08-11 05:01:15
【问题描述】：

对于我们即将发布的版本，我们已从 NServiceBus 3.0.3 升级到 3.2.7。我们在本地或 QA 测试期间没有遇到任何问题，但是在暂存环境中进行测试时，我们无法启动引用 NServiceBus 的 IIS 托管的 Web 服务。

登台机器使用与 QA 相同的软件； Windows 2008R2、IIS7.5

事件日志有两个错误。首先是事件 1026（.NET 运行时）

应用程序：w3wp.exe 框架版本：v4.0.30319 描述：由于未处理的异常，进程被终止。异常信息： NServiceBus.Unicast.Queuing.FailedToSendMessageException 堆栈：在 NServiceBus.Unicast.Queuing.Msmq.MsmqMessageSender.NServiceBus.Unicast.Queuing.ISendMessages.Send（NServiceBus.Unicast.Transport.TransportMessage， NServiceBus.Address）在 NServiceBus.Unicast.UnicastBus.SendSubscribeMessageWithRetries（NServiceBus.Address， NServiceBus.Unicast.Transport.TransportMessage，System.String，Int32）在 NServiceBus.Unicast.UnicastBus+c_DisplayClass8.b_7(System.Object) 在 System.Threading.ExecutionContext.runTryCode(System.Object) 在 System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup（TryCode， CleanupCode，System.Object）在 System.Threading.ExecutionContext.Run（System.Threading.ExecutionContext， System.Threading.ContextCallback，System.Object，布尔值）在 System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() 在 System.Threading.ThreadPoolWorkQueue.Dispatch() 在 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

随后是事件 1326 (ASP.NET 4.0.30319.0)

发生未处理的异常，进程终止。

应用程序 ID：默认域

进程 ID：10180

异常：System.Runtime.Serialization.SerializationException

消息：无法找到程序集 'NServiceBus.Core，版本 = 3.2.0.0，文化=中性，PublicKeyToken=9fc386479f8a226c'。

堆栈跟踪：在 System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly() 在 System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType（BinaryAssemblyInfo 装配信息，字符串名称）在 System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor（字符串 objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable) 在 System.Runtime.Serialization.Formatters.Binary._BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped 记录）在 System.Runtime.Serialization.Formatters.Binary._BinaryParser.Run()
在 System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize（HeaderHandler 处理程序，__BinaryParser serParser，布尔 fCheck，布尔 isCrossAppDomain, IMethodCallMessage methodCallMessage) 在 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize（流 serializationStream, HeaderHandler 处理程序, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) 在 System.AppDomain.Deserialize(Byte[] blob) 在 System.AppDomain.UnmarshalObject(Byte[] blob)

我检查了 bin 文件夹，它们确实包含正确版本的 NServiceBus.dll 和 NServiceBus.Core.dll（并且两者都是相同的版本，3.2.7）。

我感到很困惑，我想我已经检查了明显的事情。会不会是它正在尝试加载多个版本的 NServiceBus（即一些未更新的参考？）。但是，这应该是 QA 中已经存在的问题了？

【问题讨论】：

异常说“3.2.0.0”而你说“3.2.7”。您是否尝试设置程序集重新绑定，以便使用 3.2.7 解决对 3.2.0.0 的任何引用？
@WiktorZychla：我相信 Nservicebus 使用了一个版本控制方案，这样 3.2.* 必须相互兼容，因此在其二进制文件中仅使用 0 标记其余位置，semver.org。我们从 NuGet 获得的二进制文件在 nuget 中标记为 3.2.7，但在 Windows 中检查它们会显示版本 3.2.0.0
好的。另一个线索是捕获 appdomain 的 AssemblyResolve。如果他们的新版本依赖于另一个未找到的程序集，那么序列化程序可能会出现问题，但您看不到真正的原因。然后，Assemblyresolve 将触发以尝试加载丢失的程序集。还要检查内部异常。
您找到答案了吗？刚刚通过 Nuget 从 3.2.8 更新到 3.3.3，现在 IIS 抱怨 {"Could not load file or assembly 'NServiceBus, Version=3.2.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c' 或其依赖项之一。位于程序集的清单定义与程序集引用不匹配。（来自 HRESULT 的异常：0x80131040）":"NServiceBus, Version=3.2.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c"}
@mellodev：我记得，这是由于有人在 WCF 应用程序中添加了对 NServiceBus.Host 的引用，你检查过吗？不过已经有一段时间了，所以我可能会混淆这些愚蠢的错误……如果不是这样，我可以在两周后回去工作时看看。

标签： c# asp.net nservicebus

【解决方案1】：

虽然是一个老问题，但我遇到了这个问题并且我有一个解决方法。

首先enable fusion logging。确保进程可以写入日志文件夹。

接下来，检查进程正在寻找的位置。就我而言，它只是搜索file:///c:/windows/system32/inetsrv/，所以我在那里添加了dll NServiceBus.Core.DLL，现在我可以看到真正的问题了。

我的猜测是后台线程发生了未处理的异常（第一个错误），然后将其序列化并传递给主线程，主线程试图反序列化它，但找不到程序集（第二个错误）。第二个错误杀死了应用程序池，意味着我丢失了真正的错误。

此解决方法仅解决第二个错误，而不是原始问题。话虽如此，到目前为止，这足以让我让应用程序再次运行并找到对我来说真正的错误是 MSMQ 内存不足。所以我重新启动了 MSMQ，它已经开始工作了。然后我从新位置删除了NServiceBus.Core.DLL，该应用程序仍在运行。

日志输出：

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

=== Pre-bind state information ===
LOG: User = IIS APPPOOL\TenBagsFull
LOG: DisplayName = NServiceBus.Core
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: NServiceBus.Core | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///c:/windows/system32/inetsrv/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = w3wp.exe
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\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:/windows/system32/inetsrv/NServiceBus.Core.DLL.
LOG: Attempting download of new URL file:///c:/windows/system32/inetsrv/NServiceBus.Core/NServiceBus.Core.DLL.
LOG: Attempting download of new URL file:///c:/windows/system32/inetsrv/NServiceBus.Core.EXE.
LOG: Attempting download of new URL file:///c:/windows/system32/inetsrv/NServiceBus.Core/NServiceBus.Core.EXE.
LOG: All probing URLs attempted and failed.
Running under executable  c:\windows\system32\inetsrv\w3wp.exe
--- A detailed error log follows.

【讨论】：

在 System32\inetsrv 中有一个 bin 目录似乎很奇怪，你真的在那里部署你的应用程序吗？
这不是我正在做的。我将NServiceBus.Core.DLL 放入了那个文件夹，这很奇怪。
看起来像一个错误配置的应用程序域，那么？无论如何，我认为您的问题与我的问题略有不同。仍然融合测井不能推广太多次:)
我进行了更多调查并更新了我的答案。它开始变得更有意义了。

【解决方案2】：

我们今天遇到了这个错误，我们的融合日志输出与 Iain 上面发布的条目几乎相同。我们的解决方法是清除 MSMQ 的事务性死信消息队列并重新启动应用程序池。

转至计算机管理 > 服务和应用程序 > 消息队列 > 系统队列，然后选择事务性死信消息。
右键单击，选择“所有任务”，然后选择“清除”。
重新启动您的应用程序池。

【讨论】：