【发布时间】：2018-12-31 11:26:04
【问题描述】：
TL;DR：为什么 COM+ 组件会从 .NET 成功激活但无法从 ASP 加载？
我的场景：
我使用 C#/.NET（框架 4.0）创建了一个 COM+ 对象。
我正在使用 Visual Studio 安装程序项目将其部署到服务器，该项目既将 DLL 安装到 GAC 也将其注册到 COM。
浏览
C:\Windows\Microsoft.NET\assembly\GAC_MSIL，可以成功找到我注册的DLL。查看组件服务加载项，我可以创建一个应用程序并添加我已注册的组件。请注意，名称是不同的（在 DLL/命名空间和 ProgId 之间），这确实让我相信这两件事都正确发生。
但是，我正在尝试从 ASP Classic 创建此 COM 的新实例。这意味着程序中有一行调用CreateObject("PROGID")，这是在抛出。
我已经做了以下事情：
- 我创建了一个包含一行
CreateObject("PROGID")的VBS 文件，并调用了它。它也失败了，因此问题不仅限于 ASP。 - 我使用了 Powershell 2.0（机器上唯一可用的）并调用了
New-Object -ComObject "PROGID"，它也失败了。 - 我已将 LinqPad 复制到机器上并使用
Type.GetTypeFromProgID和Activator.CreateInstance。我成功调用了该实例。
这个错误似乎很常见，是 80070002。这应该表明 COM 找不到程序集文件。检查注册表后，我可以看到 COM 记录的程序集名称（FQ 程序集名称）确实与我安装的程序集相对应。运行时是新的CLR（v4.0.30319），类名也正确。
我完全感到困惑，事实上 .NET 可以毫无问题地实例化 COM 对象，而 VB6/ASP 正在中止。
更糟糕的是，上周 DLL 已成功部署，我只是在安装新版本，所以我应该会遇到任何问题。
在 ASP 和 .NET 之间加载 COM 的方式有什么不同会导致这种情况吗？我在想什么：
- 任何必须设置但未设置的权限。
- 从任何 .NET DLL 中找到从 .NET 运行但从 VBS 运行的依赖项没有找到。
- 核心运行时版本可能非常适合 ASP/VBS。
最后一项应该是正确的，因为我上周成功地完成了这项工作，并且我没有对运行时进行任何更改。
【问题讨论】：
-
经典 ASP 问题与权限相关，他们加强了应用程序池与 COM 交互的方式。因此，VBScript / Powershell 测试可能会失败，因为它们没有在提升的进程中运行（UAC 再次触发）。
-
位数怎么样：32bit vs 64bit？
-
@SimonMourier 我需要仔细检查，但我猜该应用程序是 32 位的。我正在将 .NET 组件编译为 MSIL。
-
如果您使用 c:\windows\SysWOW64\cscript.exe 运行 VB 脚本会发生什么？那它行得通吗？如果有效，则表明您已将对象注册到 32 位配置单元。 vbscript 文件的正常运行是使用 64 位引擎完成的。您的 ASP 引擎是 64 位还是 32 位？
标签： .net asp-classic com