好的，我在这里遇到了一个奇怪的人，我想知道你们中是否有人遇到类似的事情。
所以我有这个网络应用程序通过反射加载了一堆dll。基本上它会查找从某些抽象类型派生的类型，并将它们添加到它可以生成的事物列表中。
这是奇怪的部分。
在开发过程中，从来没有问题。安装时，一开始就没有问题。然后，在看似随机的时间，应用程序在尝试查找所有类型时中断。
我有两个并排坐着的网站，一个工作而另一个没有工作，而且他们的配置完全（我的意思是完全相同）。
IISRESET从来没有帮助过，但确实如此：
我只是将所有dll移出bin目录，然后将它们移回。这是正确的我只是将它们移出bin目录，然后将它们放回到它们来自的地方，一切正常。
有什么想法吗？
获得更多信息
当网站工作时，我注意到这种行为： 在IISRESET之后它仍然有效，但是回收应用程序池会导致它崩溃。
网站破损时： Neiter IISRESET也没有回收应用程序池修复它，但是 将一个dll移出然后再修复它。
更多信息
事实证明IsAssignableFrom没有返回正确的值。我不会相信它是真的，但是我的记录器记录结果和2种类型，它肯定返回了错误的值。疯狂的是，当比较相同的两种类型时，相同的dll将在不同的时间返回不同的值。
更多信息
IsAssignableFrom失败的特定类位于包含其他类的文件中。如果我将类移动到自己的文件，那么一切正常。但是，如果它与其他类在同一个文件中（即使它在自己的namespace块中），那么Type引用都是错误的。 Type引用将具有正确的名称和方法，但无法找到正确的构造函数。
答案 0 :(得分：2)
我可以想象有访问dll的并发问题。如果多个用户同时访问该页面，并且一个会话尝试访问dll，则获得独占访问权限，则所有其他会话都将失败。当然，这需要只有多个用户才能实现精确计时，这就是为什么在测试或开发时不会出现这个问题的原因。
在其他情况下，添加加载代码的扩展日志记录，抛出异常的堆栈跟踪。
答案 1 :(得分：1)
同一程序集的两个（或更多）副本可能会被加载到内存中。节省时间和头痛的最佳方法是强力组装。如果有一个强大的命名键，则每个appdomain只会加载一个程序集实例。
More info关于装配绑定上下文。
答案 2 :(得分：0)
此可能归结为锁定问题。默认情况下，bin目录中的所有dll都由ASP.Net加载，即使它们未在Web应用程序中使用。如果您尝试从特定的dll加载类型，同时ASP.Net正在将该DLL加载到内存中，您可能会因文件正在使用而出错。这可能表现为您所经历的行为，因为它会产生一种竞争条件，并且只会在其他特定事件发生时发生某些事件时出现错误 - 即使只有一个用户正在使用该网站。这也可以解释为什么你不总是得到这种行为。
要停止此操作，您可以将动态加载类型的dll放入bin目录中的目录并从那里加载。
为了更准确地解决问题，您必须向我们展示在加载类型时无法获得的任何错误（因为它可能与锁定问题完全无关）。