0

我的目标是通过 P/Invoke 从 ASP.NET 应用程序调用本机 DLL。到目前为止，我可以成功地从控制台应用程序调用 DLL，甚至可以从运行在 HttpListener 上的 OWIN 服务器调用，该服务器托管在 Azure WorkerRole 中。

当我尝试在简单的 ASP.NET 应用程序或 Azure WebRole 中托管完全相同的代码时，就会出现问题。在这种情况下，对 DLL 的调用会引发 AccessViolationException。

根据我的研究，看起来问题可能来自本机 DLL 不是线程安全的事实——即使在控制台应用程序中尝试从并发线程调用它的测试也会抛出 AVE，这表明它不是线程——确实安全。因此，我正在与 DLL 的作者核实。

但与此同时，我仍然想知道这是否真的是 ASP.NET/IIS 崩溃的根本原因，因为在我的测试期间，我一次只执行一个请求。所以等待线程安全得到修复，我想知道你们是否知道其他可能导致 P/Invoke 在 ASP.NET/IIS 中失败的具体情况。

更新

根据我的大量测试，结果证明崩溃是由 DLL 试图加载外部文件引起的。在非 IIS 应用程序中，将这些文件放在与 DLL 相同的文件夹级别就可以了；但例如在我的开发机器上，在 IIS 上运行的相同代码会尝试在“C:\Program Files (x86)\IIS Express”中查找文件。

所以我现在的问题是：有没有办法控制一个简单的路径，File.Open如果没有，有没有办法获得默认路径，以便我可以在启动时复制所需的文件？

谢谢

4

2 回答 2

0

请不要在每次应用程序启动时都复制文件，那只能南下。

更好的解决方案是让 DLL 的提供者添加一些代码来检查 Windows 注册表中的路径值。如果注册表中存在该值，则 DLL 将尝试从该值中的路径加载其关联的库；否则它将回退到尝试从 DLL 的当前目录加载它们。

于 2014-03-02T11:00:56.893 回答
0

您观察到的只是表明您使用相对路径。这意味着当在 IIS Express（不是 IIS）下运行时，进程会尝试在其下进行搜索，C:\Program Files (x86)\IIS Express因为它假定这是解释相对路径时要使用的基本目录。

您应该始终使用绝对路径而不是相对路径，这样就不会发生此问题。

http://msdn.microsoft.com/en-us/library/ms178116(v=vs.100).aspx

于 2013-10-29T05:43:38.950 回答