我们在.net项目中引用了第三方专有的CLI DLL。此DLL只是其专有C ++库的接口。我们的项目是一个asp.net（MVC4 / Web API）Web应用程序。
C ++非托管库相当不稳定。有时它会崩溃，例如晃来晃去的指针。我们无法解决它，使用这个库是一流的客户要求。
当应用程序崩溃时，IIS中的应用程序池不再响应。我们必须重新启动它，这样做需要几分钟（是的，那么长！）。
我们希望保持这个不稳定的DLL不会崩溃我们的应用程序。这样做的最佳方式是什么？我们可以将CLI DLL保存在单独的AppDomain中吗？怎么样？
提前致谢。
答案 0 :(得分：6)
我认为对这个问题的每一个答案都将是一种解决方法。
我的解决方法是不与Web应用程序中的DLL直接交互。
而是将您的请求从Web应用程序写入Message Queue或SQL表。然后，您可以使用另一个应用程序，例如Windows服务，它读取请求，与DLL交互，然后将结果写回Web应用程序进行读取。
我不是说SQL /消息队列是正确的方式，我更多的是考虑一般的流程。
答案 1 :(得分：4)
我遇到了第三方库的问题，该库访问受保护的内存以便与硬件复制保护加密狗交互。它在控制台或winforms应用程序中运行良好，但在从IIS应用程序调用时崩溃就像疯了一样。
我们尝试了几种不同的东西，其中一些在本页的其他答案中有所提及。但最终，对我们来说最好的解决方案是向我们提供一项非常古老的技术 - .Net Remoting。我知道 - 这些日子有些皱眉。但它非常符合这一特殊需求。
不稳定代码放在Windows服务应用程序中。 Web应用程序对此服务进行远程调用，该服务将命令中继到第三方库。
现在我确信你可以用WCF，套接字等做同样的事情。但是远程处理设置起来既快速又容易，而且由于我们只与同一台服务器通信，所以无需打开任何端口即可工作。它只是在命名管道上进行讨论。
它确实意味着除了Web应用程序之外还要安装第二个服务，但在我的特定用例中这是可以接受的。
如果你做了类似的事情，并且第三方代码实际上破坏了服务，你可能会在主应用程序中编写一些代码来重新启动它。
因此，当你有不稳定的代码来处理时，过程边界可能比App Domain更有用。
答案 2 :(得分：2)
我首先会增加IIS进程的回调率，可能是DLL代码在一定次数的调用后失败，或者在进程达到一定的内存使用量后失败。
您可以在此处找到有关IIS 7.0回收选项配置的信息：http://technet.microsoft.com/en-us/library/cc753179(v=ws.10).aspx
在您的情况下，当您知道应用程序的负载较少时，我会在特定时间回收该进程。并且在一定数量的请求（低于默认值）之后尝试并且大部分时间都有“新鲜”过程。
回收过程是优雅的，因为旧的过程没有终止，直到替换它的那个过程准备就绪，所以不应该有明显的停机时间。 有关回收机制的更多信息，请访问：http://technet.microsoft.com/en-us/library/cc745955.aspx
如果上面的问题没有解决问题，我会用我自己的代码来管理不稳定的DLL执行。
此代码应该从失败中恢复，例如通过重复失败的调用直到获得结果，如果在多次尝试后无法通过正常错误而失败。
在内部，对不稳定DLL的调用可以在生成的线程中进行，甚至代码也可以在可以使用Process.Start启动的新外部可执行文件中。
这最后一个选项有更多开销，但它可能是您唯一的选择。有关详细信息，请参阅此SO问题：How do you handle a thread that has a hung call?
答案 3 :(得分：2)
我建议遵循解决方案。
使用其他Web应用程序包装此dll。可以是以下之一。由于您已经使用了web api，因此它最适合您。
控制你的p调用代码，这样你就没有任何错误？请参阅以下文章。