How to deploy COM object Microsoft.Office.Interop to IIS so that my C# WCF service reference will work?

Question

I am getting an error when trying to run my web application from IIS 7 on my local machine regarding Microsoft.Office.Interop.Outlook that is like the following...

Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

When I run this same web app from VS2010 and Cassini I have no problem.

When I run the web app from IIS 7 I point my VS2010 at the IIS Virtual Directory. In fact I even had VS2010 create the Virtual Directory. So I am able to debug from VS2010 and gather the error I posted here.

I have gone to the Microsoft.Office.Interop.Outlook.dll file and given EVERYONE read,write,modify, and delete. Just to rule out security.

Are there other steps when referencing Microsoft.Office.Interop dlls? Should I configure something regarding this differently. Again switch back to running in Cassini and no problems.

Answer 1

If in fact an access violation is occuring with your application and that's the root of your problem, you can deploy the resource with your application by simply setting the reference to copy to the bin directory. You can do this by selecting the reference in your solution explorer, going to properties, and changing the Copy Local property to true.

Answer 2

On my server SharePoint is installed and running under the account "Network Service". That would be a hidden account, that normally would not be allowed to run COM objects. If you go into IIS and see which App Pool it is using (under Advanced Settings). Then check the Identity of that pool. A friend had recommended that we run our SharePoint app pool (and other services) under a named account (like [domain]\svcSharepoint) so you can explicitly give permission. Otherwise, the Network Service account would show up as [domain][machine name]$ (note the $ at the end, meaning "hidden account").

One other factor would be if you installed this on Server 2008 R2, because the UAC stuff is much stronger and would deny this kind of interaction for sure. Turning off the UAC is a little risky, but could be a winner.

Last factor would be checking the DCOM configs for that COM object. [Start Menu, Administrator Tools][Component Services][DCOM Config]. Find Outlook by name or by GUID, Properites, Security.