首页 > 解决方案 > 引用第三方 dll 的 WCF 服务在应用程序池回收时中断

问题描述

这个问题已经花费了我们两个多星期的时间,但我无法在网络上的任何地方找到解决方案。

问题陈述:

我们创建了一个具有 3 层的 WCF 服务:

1)WCF服务层

2) 立面层

3) 代理层

第 1 层使用第三方 dll 使用开箱即用的合约并调用外观层(第 2 层)来委托请求。第 2 层只是在业务验证或任何前端处理之后重定向到代理层(第 3 层)。第 3 层使用相同的第三方 dll(与第 1 层中使用的一样)来调用其 API 来执行业务操作。

部署后一切正常。服务很好地满足了许多请求。直到任何人故意或在生产的固定时间点回收托管此服务的应用程序池。

回收后,服务开始表现得很奇怪。当我调试代码时,请求仍在处理中。在代理层(第 3 层),请求仍按预期进行业务操作,但随后第三方 dll 开始抛出一些开箱即用的业务验证错误消息。并且它继续抛出相同的错误,相同的行为,直到并且除非我清理临时 ASP.Net 文件夹或在 IIS 上重新发布服务代码。这种业务验证错误本身不会停止、故障或破坏我们的服务,但它会中止第 3 层(代理层)的进一步处理,超出其起源点。

我已经尝试了所有可以在网上搜索到的东西,许多开发人员都建议过,但没有任何效果。下面列出了我尝试过的几个(不是全部):

一个。清除缓存(第三方应用程序的客户端和服务器端)并重新运行测试

湾。为 wcf 服务创建不同的应用程序池并重新执行测试

C。在其他开发环境和本地开发环境上尝试过 - 问题无处不在

d。通过更改 IIS 中的发布服务级别设置和应用程序池相关设置进行验证

e. 清除解决方案中所有项目的所有设置的 AssemblyInfo 文件。

F。在应用程序池级别使用不同的设置,例如大约两个重叠标志。

G。在临时 ASP.Net 和 IIS 发布文件夹级别授予各种权限。

似乎一些参考在运行时被破坏了。

在我们解决方案中的其他服务中,我们从未使用过来自第三方 dll 的合同,但总是创建一个包装器并且它们工作正常。到目前为止,第三方 dll 始终用于代理(第 3 层)层。

我在第 1 层使用它们。从技术上讲,即使在第 1 层(服务代码)使用它们,我也没有发现任何问题。可能是我错了或我的设计,不确定。但是发生的事情已经花费了两个多星期的时间。

技术栈:

IIS 7
Visual Studio 2017
MS .Net Framework 4.5.2

请建议。

标签: wcfservice

解决方案


推荐阅读