views:

1633

answers:

3

I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:

I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.

When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".

I have tried the following to no avail:

  1. Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
  2. Enabled 32 Bit application support for the app pool supporting the classic asp site
  3. Used NetworkService as the identity for the app pool supporting the classic asp site
  4. Tried registering dll using regsvr32, which failed
  5. I am able to create other objects such as "scripting.filesystemobject"
  6. Moving dll's to the wow64 directory and then using regsvcs to register them.
  7. And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.

This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.

Anyone have any more ideas to try?

A: 

Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly. If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.

DmitryK
Thanks for the great idea. I was able to get a VBS Script successfully creating the object. So, I started to look at permissions. To quickly see if permissions were the problems I added the following local accounts to the administrators group (of course, just for testing) which STILL did not allow the asp page to create the object:Anonymous LogonAuthenticated UsersInteractiveIUSRNetwork ServiceEveryone
Cool. We are getting closer.Have a look here:http://windows2008forum.com/f9/com-problem-in-ws2008-263.htmlHave you turned on 32bit compatibility mode for scripts and controls?Also check the last post on page 1.
DmitryK
Thanks for these ideas. But, I have already set the property: "Enable 32-Bit Applications" to true for the app pool being used by the classic asp virtual directory. I believe the script method described in the above link, is just the pre IIS7 way of doing the same thing. Now its just a configuration option in the app pool... Any other ideas?
what is the account your app pool runs under? Can you verify permissions for this account? Does this account have at least RX on the actual DLL?
DmitryK
Currently, my app pool executes under NetworkService. However, I have already gone through task of adding this account and several others to the admin group on the server, so I would think we have already been down that path. See my first comment for reference. Thanks.
More interesting info: When running the vbscript file from cmd.exe (located under system32) the createobject works. However, if I try to run this same vbscript using the cmd.exe located in the SysWow64 folder, the vbs script createobject statement fails. The SysWow64 folder holds the 32 bit versions from my understanding. I imagine this is similar to how my classic asp application is running under 32 bit mode as well. So, I think we are dealing with a 32 bit vs 64 bit issue, rather than some permissions problem...
Aha! When registering your DLL - make sure you run the regsvr32 from the WOW64 directory to allow the 32bit DLL to register properly. You will be better of unregistering your DLL (regsvr32 /u name.dll) and then re-registering it again properly.
DmitryK
Actually regsvr32 fails with an error stating: "entry point DllRegisterServer was not found. Regsvr32 I think was meant for the old style true com dll's if I remember correctly. The method to register a net com wrapped assembly is regsvcs or regasm (which I have already tried the 32 bit and 64 bit versions of)I think we might have to open a case with microsoft if we cannot figure out a method around this.
Very good. Did you use /codebase switch when registering your interop DLL (regasm)?
DmitryK
Also what is the error code you are getting when trying to create object? Is it 8000FFFF or something different?
DmitryK
A: 

After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:

  • No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
  • Utilized the following commands to install the component, which must be done in order:

    gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"

    regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"

This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.

+1  A: 

Try this

Component Services -> Computers -> My Computer -> COM+ Applications

Open a COM+ Application object.

Open Components.

Right-click on a class and select Properties.

Under "Advanced" there is a check box for "Allow IIS intrinsic properties".

It works for me

ines