我们在WCF服务上有一个插件系统,用于检查放置在bin文件夹中的库以获取某些程序集级属性并加载它们。这允许基于哪个客户端进行呼叫来定制某些服务呼叫。这在大多数情况下都很有效。但是,有时它似乎丢失了dll,这导致服务恢复到每个客户端的默认实现。到目前为止,解决方案只是将dll文件移出bin文件夹,然后重新进入。这会导致asp.net获取文件并自定义重新开始工作。
我不知道为什么会议在一段时间之后会被错过。关于可能导致这种情况的任何想法?
编辑:问题陈述得更清楚
我们的服务使用服务工厂根据客户端调用代码的方式分发自定义实现。如果没有自定义实现,我们将分发默认实现。我们使用GetAssemblies来检查使用属性修饰的程序集,将它们指定为自定义实现并将它们与客户端相关联。问题是GetAssemblies停止返回客户端的自定义程序集,即使该库仍保留在bin文件夹中。将dll移出垃圾箱并返回垃圾箱会将问题解决大约一周,直到再次发生
答案 0 :(得分:4)
您遇到的问题必须与appdomain的自动回收相关。显然,appdomain recycle的行为与实际重启的行为不同。在回收时,它只会加载显式引用并根据需要加载的dll。看到这个链接 http://www.chrisvandesteeg.nl/2006/06/15/appdomain-recycle-different-from-real-restart/
GetAssemblies只会返回当前加载到appdomain中的程序集,这可以解释您在程序中遇到的异常情况。为了安全起见,如果您正在处理插件类型库,则应始终扫描插件文件(dll)并使用Assembly.LoadFrom显式加载它们。另一种方法是在自定义主机(例如窗口服务)外部托管您的WCF服务,以便主机的生命周期不受IIS回收策略的约束。
有关appdomain回收的更多信息,请阅读此内容 http://blogs.msdn.com/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx
答案 1 :(得分:0)
如何加载程序集?下一个问题......为什么? bin目录中的程序集应自动加载并可供引用它们的ASP.NET应用程序使用。也许你在这里遇到了一些冲突...即访问被拒绝,因为其他一些线程/进程有一个打开的程序集句柄。对不起,这太模糊了,但这是唯一让人想起的东西。您可以使用FileMon或类似工具来检查这一点。
另外......你究竟是什么意思“丢失”DLL?你正在调用一些特定的方法来找到它,它失败了吗?错误是什么?您是否在事件查看器中检查了未处理的异常?
答案 2 :(得分:0)
GetAssemblies仅返回已加载的程序集列表。如果尚未使用该程序集中的类型,则尚未加载该类型。您需要使用Assembly.Load从磁盘加载您想要的程序集; / bin文件夹中的程序集不会自动加载到应用程序域中。
此外,您可能会考虑使用Managed Extensibility Framework (MEF),它专门用于处理您正在谈论的功能。
答案 3 :(得分:0)
...替换\ bin目录中的程序集将导致该目录的全新批处理编译。
http://msdn.microsoft.com/en-us/library/5dws599a(VS.71).aspx
您是否在global.aspx中的Application_Start中有初始化代码?
答案 4 :(得分:0)
装入提示路径仅在AppDomain加载时检查一次,即使您明确告诉它按名称加载程序集也不会找到它。为了解决这个问题,您需要重新加载主AppDomain,或者创建一个辅助AppDomain并使用它来加载程序集,这是我过去所做的,它运行正常。然而它确实带来了第二个AppDomain的开销,不确定这是不是很重要。