Connecting a WCF service with a third-party dll with IIS

Question

I work with Windows 7, VS2010, SqlServer 2008.

My application receives data from a third-party dll (which takes data from another process that should be running in the background) and processes the data and sends it through the WCF service to the interface.

The application is complete and does what it should do. Now that I want to distribute it and run it in IIS. I got a strange problem. The application receives data from the dll, when I run it in IIS, it fails and gives an error message when connecting to the dll.

Getting factory COM class for component with CLSID {FCEC6861-5866-4F9E9A09-7CC868C30A8B} failed due to the following Error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

After some research, I found out about component maintenance and inside the DCOM configuration, I am changing the security of the DLL for everyone. Error stopped.

But now I do not receive an error, but I do not receive data, for example, when the software that provides the data is closed. But working fine with my ASP.net development server.

I also found that when I started Visual Studio in administrator mode, I had to run third-party software for data in administrative mode.

The dll link is not automatically copied to the bin folder, it is placed in the obj folder, and I manually copied it, but it does not work.

Answer 1

I think the COM component works in the same context as the caller, and elevated permissions are required to complete its work.

So:

• VS in administrator mode, COM in administrator mode, works because both have system rights to perform their work.
• IIS runs under the application pool account (not sure which one), COM will also be under this account, but it is not an administrator, so there are too few permissions to work correctly.

My troubleshooting suggestion would be to change the IIS application pool your application runs on as a local administrator. If this works fine, restore the permissions on your DCOM to the default values ​​(before switching to all) and try again. You can also try running the application pool on your local system account to see what happens. If this still works, you have confirmed this behavior as a problem.