Geek Answers Handbook

Connecting to a COM interface in aspx code running on IIS?

I created a Windows service (exe based on the ATL Visual Studio wizard) that provides a COM interface. There is no problem starting the In-proc server or the Windows service. I need a Windows service, as I need some processes to be available outside of IIS access.

I create several web pages (aspx / C #) that invoke my service and everything did a great test on Visual Studio.NET Development Server. Now I'm trying to redirect web pages to IIS 7 (works on Windows 7) for further testing. But, when pages work under IIS, calls to my COM interface all crash on error

"Retrieving the factory COM class for the component failed due to the following error: 80070005 Access denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

I checked the service:

  • registered in Windows under HKCR \ Clsid \ (note, I registered the launch of "myservice.exe / RegServer", since regsvr32.exe works only with dll)
  • myservice.exe has read and execute permissions for user IIS_IUSRS
  • is a 64-bit exe (so it should load into the default IIS application space)
  • Works great in the .NET Developement Server debugger (but not in IIS)

Any ideas why this won't work? Is there anything related to the COM interfaces contained in exe vs dll?

Any IIS features calling a COM interface open in a Windows service?

+4
source share
3 answers

I suppose you need to grant access to the process of the application pool of your site in order to use your COM object in the DCOM configuration.

  • Go to Component Services
  • Computers> My Computer> DCOM Configuration
  • Find the AppID or Your Service Name in the list. Right click on it and select properties.
  • Click the Security tab
  • Select the launch and activation rights and select "Configure".
  • Provide the application pool process (possibly ASPNET, but check the IIS application pool properties for your site): Local launch and local activation.

Please let us know if this solves your problem.

By the way:

> is a 64bit exe (so should load in the default IIS app-pool space)

This is not entirely true. An application pool is an ISS-controlled process. Your service works in a separate process no matter what. Thus, your service has nothing to do with IIS application pools.

+2
source

It is very similar to the security / permissions issue - so first make sure that any user running IIS has sufficient permissions and, in particular, checks to see if your ASPNET group has permission to use COM (I think it's not the default) .

EDIT - after posting this post, I found another post that might help - look here too

+1
source

Thanks guys. I really appreciate your answers. Your information pointed me in the right direction. The problem really was a security / resolution problem. To aggravate the problem, whenever I rebuilt my service, the rights set for IIS_IUSRS were removed from exe, so some of the failures that I observed were related to simple rights to service.exe. Therefore, if you start to see that errors in the intermediate access get into your COM object during development, check the exe permissions after the reassembly! I hope this helps others.

To complete, here is how I solved the problem:

  • changed the "identifier" of my services application pool to "LocalSystem" (since my COM was in a Windows service running under a system account - most people will not require this level) (IIS manager | application pools | right-click in your application pool | Advanced Settings | Authentication
+1
source

More articles:


All Articles