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

Question

I've created a Windows service (an exe based on the Visual Studio ATL wizard) which exposes a COM interface. No problems running as an in-proc server or a Windows service. I need a Windows service since I need some processes to be available outside of IIS access.

I've been creating some web pages (aspx/C#) calling my service and everything has worked fine testing within the Visual Studio .NET Development Server. Now, I'm trying to push the web pages to IIS 7 (running on windows 7) for further testing. But, when the pages are running under IIS the calls to my COM interface all fail with the error

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

I've verified the service is:

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

Any ideas why this would not work? Something to do with the COM interfaces contained in an exe vs dll?

Any possibilites of IIS calling a COM interface exposed in a Windows service?

Nellnella

What about the app pool identity? Does it have access? You could change it your identity to test it. – Ostensory

Answer 1

I believe you need to grant access to your site's app pool process to use your COM object, under DCOM Config.

• Go to the Component Services
• > Computers > My Computer > DCOM Config branch
• Locate the AppID or Name of your service in the list. Right-Click on it and select properties.
• Open the Security tab
• Pick Launch and Activation Permissions and select Customize.
• Grant the app pool process (probably ASPNET, but check the IIS app pool properties for your site) the following: Local Launch and Local Activation.

Please let us know if this solves your problem.

Incidentally:

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

That's not quite true. The app pool is an ISS-controlled process. Your service runs on its own separate process no matter what. So your service has nothing to do with IIS app pools.

Copper

Answer 2

It looks very much like a security/permissions problem - so first make sure that whatever user the IIS worker is running under has sufficient rights and in particular check that your ASPNET group has permission to use COM (I think it doesn't by default).

EDIT - after posting that, I did find another post that might help - take a look here too

Hearsay

Answer 3

Thanks Guys. I really appreciate your responses. Your information pointed me in the right direction. The problem was indeed a security\permissions issue. To compound the problem, whenever I rebuilt my service, the rights I set for IIS_IUSRS was purged from the exe so some of the failures I was seeing was due to simple rights on the service.exe. So if you start seeing intermitent errors access your COM object during development then check the rights on your exe after re-builds! I hope that helps others.

For completion, here's how I resolved the issue:

• changed the 'identity' of my services application pool to 'LocalSystem' (since my COM was in a Windows service running under the system account - most people will not require this level) (IIS Manager | Application Pools | right-click on your app pool | Advanced Settings | Identity

Nellnella

Well, running as LocalSystem will certainly make security errors go away, but it is not really a very good idea. LocalSystem is the most powerful account on the machine, and you really should restrict its use to only where it's absolutely necessary. If you're just writing something to play with the coding techniques, then it's fine. If you're trying to make a product out of this, even an internal application within a company, you really should investigate the problem. Using LocalSystem unnecessarily is akin to removing a door from its hinges because the keys are too hard to use. – Copper

"Added execute rights... For IIS_IUSRS" This is just weird. The only one that needs execute permissions to run a service is the Service Control Manager (SCM), and that runs as LocalSystem. Your IIS app doesn't run the service; it launches COM objects through the DCOM infrastructure, and DCOM talks to the SCM to launch the service if necessary. Unless there is something missing from your description of the app. – Copper

Thanks Euro. You are correct the execute rights for IIS_IUSRS was not necessary. I updated my response above. – Nellnella