WCF服务中的Intermittent SerializationException查找不正确的DLL版本

时间:2017-10-11 19:58:10

标签: c# .net windows wcf iis

所以我间歇性地从WCF中发生了一些不好的事情,向我的服务器的事件日志写了一个异常。

此异常与“System.TimeoutException”同时发生,用于对客户端进行异步回调。我猜序列化问题会导致超时问题,因为调用时间不长。

当客户端从服务获得异步回复时,有时会记录包含“服务器未提供有意义的回复”的堆栈跟踪。

因此,我的Web服务的“bin”文件夹包含版本为2.0.0.0的My.Org.Core DLL副本,但堆栈跟踪是指版本1.8.0.0!我搜索了我的整个解决方案,因为任何提及这个旧版本的1.8.0.0都无法找到它!请帮忙。

以下是序列化问题:

An unhandled exception occurred and the process was terminated.

Application ID: DefaultDomain

Process ID: xxxx

Exception: System.Runtime.Serialization.SerializationException

Message: Unable to find assembly 'My.Org.Core, Version=1.8.0.0, Culture=neutral, PublicKeyToken=null'.

StackTrace:
at System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
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.AppDomain.Deserialize(Byte[] blob)
at System.AppDomain.UnmarshalObject(Byte[] blob)

4 个答案:

答案 0 :(得分:0)

看起来实际错误是由于WCF服务中的一些未处理错误导致的其他错误。

这是因为当在基于ASP.NET的应用程序中抛出未处理的异常时,应用程序意外退出。发生此问题时,应用程序日志中不会记录您必须了解该问题的异常信息。

所以要得到实际错误,

  • 尝试将try-catch块添加到代码中(某些全局错误处理或每种服务方法)并检查错误日志
  • 或者要检查实际错误,请按照此article中的步骤操作(方法1,不要参阅文章中的方法2)并记录实际错误。

希望它有所帮助。

答案 1 :(得分:0)

1-如果您在一个解决方案中有多个项目,则应打开引用旧版本DLL的每个项目文件,并将其替换为新版本。

2-如果你在一个独立的类库中有模型并且为了防止任何类型的序列化异常,我建议你将序列化合同添加到该类库中的AssemblyInfo.cs,如下所示:

[assembly: AssemblyProduct("blah.Data.Domain")]

你和合同可以是这样的:

[assembly: ContractNamespace("http://blah.xyz/test",  ClrNamespace = "blah.Data.Domain"

此合约序列化适用于类库中的所有模型。

答案 2 :(得分:0)

正如您提到的堆栈跟踪引用旧版本的dll,您是否有可能在GAC中注册旧的DLL?

答案 3 :(得分:0)

所以dll版本就是问题。

错误:My.Org.Core,版本= 1.8.0.0 coudlnt可以找到

根据你的预期dll是My.Org.Core,版本= 2.0.0.0。

第一步是在GAC中查找该dll。

RUN 然后键入%windir%\ assembly \ GAC_MSIL,现在深入查看或搜索My.Org dll,右键单击,如果找到则检查版本。如果找不到,那么你不要拥有dll。这意味着您的bin /解决方案或GAC中既没有My.Org.Core,Version = 1.8.0.0 dll。

看起来这是你的内部组织dll.So得到1.8.0.0 th dll并把它放在bin文件夹中并重新启动客户端服务。

为什么你错过了dll ?可能在构建客户端应用程序时,dll是从GAC引用的,因此在开发人员计算机中没有遇到此问题。

如何避免这种情况?虽然应用程序构建/部署将属性副本设置为local true,但是在构建应用程序时,该特定dll会明确地删除在包或bin文件夹中,而不需要从GAC引用。但显然它会增加构建时间