在 Windows Server 2003 上从 Web CGI 脚本执行 .net 应用程序时出现 InteropServices COMException

Question

免责声明：我对 .net 和 COM 完全一无所知。

我有一个供应商的应用程序，似乎是用 .net 编写的，我正在尝试用 Web 表单（一个 cgi-bin Perl 脚本），这样我最终可以从单独的计算机启动该供应商的应用程序。 我使用的是 Windows Server 2003 R2 SE SP1 系统，我使用 Apache 2.2 作为 Web 服务器，使用 ActivePerl 5.10.0.1004 作为 cgi 脚本。 我的 cgi 脚本使用 Perl 反引号运算符调用驻留在同一台计算机上的供应商应用程序。

...
$result = "Result: " . `$vendorsPath/$vendorsExecutable $arg1 $arg2`;
...

现在我只是在服务器计算机上本地运行 IE Web 浏览器并访问“http://localhost/ cgi-bin/myPerlScript.pl”。 供应商的应用程序失败并记录一条调试消息，其中包括以下堆栈跟踪（我更改了几个名称，以免泄露供应商的身份）：

...
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80043A1D): 0x80040154 - Class not registered
   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
   at VendorsTool.Engine.Core.VendorsEngine.LoadVendorsServices(String fileName, String& projectCommPath)
...

当我使用确切的服务器计算机上的 Windows 命令行运行供应商应用程序时cgi 脚本传递的相同参数运行得很好，因此通过 Web 脚本调用他们的应用程序会导致问题。 这个问题可能与安全相关，因为整个过程在 Windows XP Pro 计算机上运行得很好（命令行和 Web 调用）。 实际上，我在那里开发了我的 Web 脚本，并在尝试将其移至 Windows Server 2003 计算机之前让它完全正常工作。 那么，Windows Server 2003 计算机有何不同之处，会阻止 Web CGI 脚本成功执行供应商的 .n​​et 应用程序呢？

我能否以某种方式解决此问题以使其在我的服务器上正常工作，或者供应商是否必须对其 .net 应用程序进行更改并发布新版本？ 我可能是世界上唯一尝试从单独的程序执行该供应商的应用程序的人，因此，如果有一个我可以在我的服务器计算机上自行实现的解决方法，我不想用这个问题来打扰供应商。 另外，我有点着急，不想等待 4 或 6 个月供应商修复并部署新版本。

感谢您提供的任何建议。

Answer 1

在我看来，你有权限问题。 您的 .NET 应用程序似乎尝试使用 COM 对象，但没有足够的权限来执行此操作。

每个COM对象（COM服务器）都有启动/激活和访问权限（只需启动dcomcnfg并查看一些众所周知的应用程序的DCOM配置）。 对于dcomcnfg（组件服务），您不仅可以查看还可以更改此权限（选择一个应用程序并在上下文菜单中打开属性对话框。然后选择“安全”选项卡，在“启动和激活权限”块，然后单击“编辑”）。 典型的问题是 INTERACTIVE 用户对大多数 COM 对象具有启动/激活权限，但作为服务运行的进程不是该组的成员。 因此，您必须通过向某个帐户（由您的 Apache Web 服务器使用）或组（如 IIS_IUSRS ）授予具有交互用户的相同启动权限来自定义权限。 此权限信息将保存在 HKEY_CLASSES_ROOT\AppID 项的子项中（请参阅二进制 AccessPermission 注册表值）。

为了识别导致问题的 COM 对象，我建议您使用 Process Monitor（参见 http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx）和Process Explorer（请参阅http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx）。 进程监视器可以帮助您准确找出您的程序（$vendorsExecutable）尝试启动哪些其他进程。 最后一次访问 HKEY_CLASSES_ROOT 中的一个用于启动 COM 对象。 你会发现它是哪个进程。 不要忘记在具有完全管理权限的帐户下启动此工具（在服务器上通常不存在此类问题）。 要更快地找到您需要的信息，请使用进程名称过滤器和进程监视器的搜索功能。

如果您第一次做这样的工作，它可能看起来非常复杂。 这并不容易，但一切都有明确的逻辑，我确信您可以解决这个问题。

Answer 2

请告诉我这是否有帮助：您收到“0x80040154（类未注册）”错误消息当您注册 ATL 服务器时

根据供应商开发其应用程序的工具，这可能是由于 DLL 注册而引起的，而该 DLL 实际上并未在您的 Windows Server 2003 上注册。

Answer 3

典型的原因是您没有安装先决条件。 很难说是哪个，因为 COM 类被许多应用程序使用。

找出丢失的类的一种方法是 sysinternals 工具 进程监视器 。 它可用于监控注册表的使用情况。 这可以帮助您准确跟踪脚本尝试加载的类。 命名的 COM 类驻留在其下

HKEY_LOCAL_MACHINE\SOFTWARE\Classes

，并且它们的底层 GUID 条目位于其中。

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID

如果 Apache 正在那里查找条目但没有找到它，则该条目可能是 perl 脚本丢失的 COM 类。