问题
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?
回答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.
回答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
回答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
来源：https://stackoverflow.com/questions/15563083/connecting-to-a-com-interface-in-an-aspx-code-behind-running-on-iis