引用第三方dll的WCF服务在应用程序池回收中中断

时间:2018-09-25 05:06:30

标签: wcf service

这个问题已经花了我们2个多星期的时间,但没有任何解决方法可以在网上找到任何地方。

问题陈述:

我们创建了一个WCF服务,该服务分为3层:

1)WCF服务层

2)门面层

3)代理层

第1层使用第三方dll使用现成的合同,并调用立面层(第2层)来委派请求。 在业务验证或任何前端处理之后,第2层只是简单地重定向到代理层(第3层)。 第3层使用与第1层相同的第三方dll来调用其API进行业务操作。

部署后,一切都运行良好。服务可以很好地满足许多请求。直到任何人有意或在生产的固定时间点回收承载此服务的应用程序池。

回收后,服务开始变得奇怪。当我调试代码时,请求仍在处理中。在代理层(第3层),请求仍然可以按预期的方式到达业务操作,但是随后出现了一些现成的业务验证错误消息,这些消息开始从第三方dll中抛出。除非我清理临时的ASP.Net文件夹或在IIS上重新发布服务代码,否则它将继续引发相同的错误,相同的行为。这样的业务验证错误不会停止,故障或破坏我们的服务,但会中止超出其起源的第三层(代理层)中的进一步处理。

我尝试了所有可以在网上找到的内容,这是许多开发人员建议的,但没有任何效果。下面列出了一些(并非全部):

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

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

c。在其他开发环境和本地开发环境中进行过尝试-问题到处都有重复

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

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

f。在应用程序池级别使用不同的设置进行播放,例如大约两个重叠标志之一。

g在临时ASP.Net和IIS发布文件夹级别提供了各种权限。

似乎某些引用在运行时被破坏了。

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

我在第1层中使用了它们。从技术上讲,即使在第1层(服务代码)中,使用它们也没有发现任何错误。可能是我错了或者我的设计不确定。但是发生的事情已经超过了2个星期。

技术栈:

IIS 7
Visual Studio 2017
MS .Net Framework 4.5.2

请提出建议。

0 个答案:

没有答案