将ASP.NET 4 App dll进行卷影复制，但改为加载bin dll

Question

在大型asp.net 4应用程序中存在一个非常奇怪的问题。 IIS有时不是从卷影副本位置加载模块，而是从dll最初来自的bin目录加载。

有谁知道IIS模块加载的工作方式，这是正常现象还是错误？

这是导致我们的问题

• 在开发中； 相应的dll被锁定在bin文件夹中，这意味着msbuild无法在构建时替换它。
• 这导致我们遇到一个特别令人讨厌（且很难找到）的问题（正在与黑客一起解决），其中我们在nhibernate queryovers中获取TypeMismatchException

笔记

• 在Win7和WinServer2008R2，IIS 7.5上运行的ASP.NET 4应用程序，使用MVC3，MVC4，WebForms，WebApi的多个项目
• 通过附加VS调试器并检查加载的模块而获得的模块信息
• 如果我IISRESET并清除temp asp.net文件文件夹，然后将应用程序后台处理，则dll将全部复制到卷影复制位置，然后从那里加载。 如果我然后再次执行IISRESET并后台处理应用程序，则会从bin位置而不是卷影复制位置加载模块
• 这仅影响Web项目的项目依赖关系，始终从卷影副本位置加载入口点。 IE Proj.Web将从卷影副本位置加载，该Proj.BusinessLogic ＆ Proj.DataAccess的项目依赖项将从bin文件夹加载，外部依赖项（自动映射器，瞥见等）将从卷影副本位置加载。
• 我们不会在代码web.config或IIS config（默认设置）中覆盖任何应用程序池或应用程序域配置。
• 无法找到详细记录了模块加载或应用启动的任何位置。

Answer 1

几周前发现了此问题的根本原因，希望现在发布以帮助遭受类似问题的任何人。

在我们的一些开发人员经过一番努力之后，我们发现这是由于我们在扫描dll进行nhibernate配置时所造成的。

当我们从代码中显式加载dll时，我们滥用了Assembly helper方法。 而不是使用Assembly.LoadFrom(assemblyPath)而是使用Assembly.LoadFile(assemblyPath) 。 这些方法之间存在许多差异，此处相关的是LoadFile()加载指定的文件，而LoadFrom()将应用逻辑以从其他位置（如temp，cache或GAC LoadFrom()查找程序集。 有关差异的更多详细信息，请参见此问题 。

无论如何，在更改了这一行代码之后，我们所有的问题都消失了。