COM Interop fails when moving to new server

I've run into a problem I just can't seem to solve. The background: Years ago, I developed a web site for one of my customers using ASP 2.0 and Ajax. One function of the web site is to produce customer invoices, on demand. Their in-house production system is written in Visual Foxpro 8 with SQL Server 2005 on the back end. Since I already had an invoice generation object that would produce a PDF file, I rolled up a COM EXE and created a COM wrapper for use in my ASP page. It works great for years, but now we're trying to move the page to a different location and things aren't working so great.

The network techs have re-produced the environment and the rest of the web site runs perfectly. I can even instantiate the COM object (I've logged the init and all is well), but the very first call to one of the objects methods results in an "Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))". I'm just plain stuck!

Here's what does work:

1) Using a visual foxpro program from the same server I can instantiate the object, call the generate invoice method and produce the PDF - no problem whatsoever.

2) Using VBScript from a very simple ASP page I can use Server.CreateObject() to instantiate the object and successfully generate the invoice from there.

So far I kn开发者_如何学运维ow:

1) the object is registered correctly and is launching as the proper user, with all of the rights needed to do it's business.

2) the wrapper for the COM EXE and COM object versions are matched.

I apologize for the long post. To make a long story short: Why would ASP.NET not be able to make a call to any method of a VFP COM object after it's been instantiated successfully?

Thanks in Advance - I'm seriously stuck on this one.

Erik

For those running into the same situation, adding the COM EXE to the Data Execution Prevent (DEP) exception list allowed the calls to the objects methods.

Did you compile it as an EXE, a runtime DLL, or Multi-Threaded DLL. Additionally, a problem I've had before is that of single or multiple instances of an OlePublic dll entry. To confirm, modify your project... then from the Top Menu, click "Project", then "Project Info". On the third tab is "Servers" showing the available servers in your project. On the right side of it is "Instancing" this would be either single or multiple. Sometimes, just throwing this to single has solved instances for me. However, if multi-threading, make sure you have the multi-threaded dll too.. VFP9T.DLL

--- EDIT PER RESPONSE... Since you compiled it as an EXE, Its probably going to show up as a distributed COM object. Go to the Windows "Start", and run "DCOMCNFG" which will bring up the DCOM Configuration manager. You'll have to scroll down the list of items until you find your exe (OlePublic class name) and might have to revise permissions, who can launch / access / execute... apply impersonate, etc...

FOR TESTING ONLY --- You could set this COM server as impersonate Administrator -- JUST TO TEST and see if any errors or not. If no errors, then you'll know its a permissions thing, then change it back to a more restricted user.