2009-08-15 68 views
1

我遇到了与运行IIS7的64位Windows Server 2008服务器上的传统asp应用程序执行.dll相关的问题。情况如下:使用COM + .Net Interop 64位Windows Server 2008的经典ASP IIS 7 Server.CreateObject失败

我写了一个.Net C#程序集来执行一些加密任务。通过继承ServicedComponent,该组件可用于传统ASP环境,确保assemblyinfo文件具有ComVisible(true)属性,并且已使用“regsvcs”命令行安装该组件。

在我自己的桌面(运行IIS6的XP)上测试时,一切正常。当移动到IIS 7,Windows Server 2008时,我得到臭名昭着的“ASP 0177 Server.CreateObject失败”。

我曾尝试以下无济于事:

  1. 确保ASP和脚本扩展功能被安装在服务器上,因为这不是IIS7默认。这使我可以执行简单的ASP命令,但不能为.net程序集创建server.createobject。
  2. 启用了应用程序池32位应用程序支持支持传统的ASP网站
  3. 使用网络服务的身份应用程序池支持传统的ASP网站
  4. 尝试注册使用REGSVR32 DLL,它未能
  5. 我能够创建其他对象,如“scripting.filesystemobject”
  6. 将dll移到wow64目录,然后使用regsvcs注册它们。
  7. 是的,当我一直在执行regsvcs命令时,它们来自使用“RunAs”Administrator启动的命令行。 regsvcs命令从64位和32位版本都成功注册了 。但是,从传统的asp应用程序使用时,它会失败。

此问题与this one密切相关。但是,我认为这个问题更多地涉及到在服务器上使用工具,而不是类似于我的程序问题。

任何人有更多的想法尝试?

+0

降级到Windows 2003?这听起来像你真的不需要2008. – NotMe 2009-08-15 03:29:13

+0

不幸的是,对于这种情况,我没有降级到Windows 2003的选项。当我们将经典的asp应用程序迁移到.Net时,大多数网站都将建立在.Net中。 。所以,我认为我们必须弄清楚这个问题:( – Pat 2009-08-17 13:33:57

回答

6

经过很多的帮助和更多的研究,我们终于找到了答案。为了解决我们的问题,我们做了以下内容:

  • 不再的ServiceComponent继承(这是确定的,因为我们实际上并没有利用任何特定的COM +功能)
  • 已用下面的命令来安装该组件,这必须按顺序进行:

    GACUTIL/I “C:\的Inetpub \ wwwroot的\ ASPTest * DLL的名称*”

    regasm/TLB “C:\的Inetpub \ wwwroot的\ ASPTest * DLL *的名字”

此过程消除了原始错误,并且还具有在IIS运行时能够替换DLL的额外好处。

0

创建一个vbs测试文件并尝试在那里创建您的COM对象。如果你不能(即你​​得到相同的错误),那么你的组件没有正确注册。 如果可以 - 那么它已正确安装,并且问题在于您的应用程序在IIS中执行的帐户缺少权限。

+0

)感谢你的好主意,我能够成功创建对象,因此我开始查看权限。我加的问题下面的本地帐户管理员组(当然,只是为了测试),这仍然没有让asp网页中创建对象: 匿名登录 身份验证的用户 互动 IUSR 网络服务 大家 – Pat 2009-08-17 13:37:43

+0

酷。我们正在越来越近 看看这里: http://windows2008forum.com/f9/com-problem-in-ws2008-263.html 你打开32位兼容模式为s限制和控制? 另请参阅第1页的最后一篇文章。 – DmitryK 2009-08-17 15:18:30

+0

感谢您的这些想法。但是,我已经为传统asp虚拟目录使用的应用程序池设置了属性:“启用32位应用程序”为true。我相信在上面的链接中描述的脚本方法,只是IIS7做同样的事情的方式。现在它只是应用程序池中的配置选项...任何其他想法? – Pat 2009-08-17 15:34:16

2

试试这个

组件服务 - >计算机 - >我的电脑 - > COM +应用程序

打开一个COM +应用程序对象。

打开组件。

右键单击某个类并选择“属性”。

在“高级”下,有一个“允许IIS内部属性”复选框。

它适用于我

相关问题