IIS7处理程序映射

Question

我有一个ASP.NET网站，在我的家用PC上完美无瑕地执行。但是当我从主机提供商运行它时不太好。我需要在后面的代码中调用一个COM DLL。本地IIS7始终会在我的DLL导入属性中找到指定为“C：\ MyDLL.dll”的DLL。问题是，无论何时执行对我的DLL的调用的代码，页面上都不会发生任何事情。就好像代码从不执行？因此，为了在我的最后查明问题，我承诺在家中设置一个运行IIS7的Win2k8服务器来复制我的主机提供程序环境。花了一段时间才知道如何将我的网站加入到IIS7中，但是现在我终于能够执行我的网站了。但！我期待更好的日志记录？似乎登录IS7的范围仅限于记录哪些页面加载以及何时加载？ :(

我没有挖成跟踪呢。也许我的下一个选择，但我不知道是否“处理程序映射”可以做什么来帮助我的加载COM DLL？可能是一个权限的事情吗？

Answer 1

有在这里一个类似的问题，有一些技术，可以帮助您解决： Web service works in asp.net but not IIS

即：

• 的差异用户上下文本地服务器之间（不知道你正在使用的网络服务器...如IIS在Vis中表达ual Studio？）以及IIS 7应用程序池上的进程标识。
• ASP.NET中的可信赖级别，可在计算机上配置。然而，这听起来像你正在与一个虚拟主机公司合作，这个虚拟主机公司通常不允许网络应用以完全信任的方式运行（除非你有一个完整的虚拟机）。
• 在您的家庭服务器上，您可以检查Windows事件日志，并查看是否在触发代码时注意到任何写入错误（例如，检查应用程序日志和安全日志）。另外，您可以尝试运行免费的SysInternals工具之一，例如Process Explorer或Process Monitor（http://technet.microsoft.com/en-us/sysinternals/bb795533.aspx），它允许您实时查看机器上资源的访问和故障。

Answer 2

那么，我会被诅咒的。在我的电脑上，我拥有宝贵的DLL，位于“C：\ myDLL.DLL”，它可以从VisualStudio2013完美地工作。只要我顽固地坚持把我的DLL放在同一位置（为什么不呢？）在我的测试Win2k8 64位服务器框中运行IIS7，当我的C＃试图在Internet Explorer中尝试调用我的DLL函数时，什么都没有发生（或Firefox或Chrome）。没有，nada，zilch，rien du tout :(

在user2731610的建议下，我使用ProcessMonitor检查我的DLL是否被ASP进程worker访问，ProcessMonitor显示找到了DLL并且正确“创建”，“打开”和“查询内部”，但没有发生过这一点？

我在我的DLL上使用了DependencyWalker，发现在myDLL.dll中引用了NT.dll和Kernel32.dll。我推断，也许，myDLL.dll需要位于相同的位置作为那些其他两个DLL？所以我把myDLL移到了C：\ Windows \ System32，还有C：\ Windows \ SysWOW64。为什么不呢？我决定把一个副本在这两个地方，以防万一。因为我记得，当我运行ProcessMo时nitor早些时候ASP系统地查询了多个位置来搜索我的DLL？可能包含在PATH声明中的所有位置？难道它复杂...

DependencyWalker在我的DLL中显示3个条目。首先，Kernel32.DLL，CPU = x64。其次，NTDLL.DLL，CPU = x64。第三，myDLL，CPU = x86。不同的CPU“类型”被DependencyWalker标记为“具有不同CPU类型的模块”的错误？我相信myDLL编译为32位，而Kernel32和NTDLL编译为64位。尽管如此，这似乎并不重要。

在安全性下，我添加了IIS_IUSRS用户并完全控制它。这种设置可能没有什么区别，但在尝试诊断问题的过程中，这可能是一个候选人。

最后，我想说，我在这个问题上花费了太多的时间，并且我广泛地搜索网络寻求帮助。我对所遇到的所有文章和帖子感到沮丧，没有真正清楚发生了什么。我猜COM被认为是老技术，新的资源将被管理的解决方案。

这是一个漫长而令人沮丧的研究的结尾。我看不到隧道尽头的灯光，并且即将诅咒微软。感谢您的帮助和耐心。