Controlling a COM application with a .NET web service

[eja24601]

Hello,

I am writing an application to control a software package (referred to from
here on as "The Package") that was written in COM. I want to control this
application via the web, and my design approach is to offer a web service
that exposes the package's functions to an end user.

My current hurdles follow:

1. If The Package is already running in the server, the service fails with
the dreaded
"Retrieving the COM class factory for component with CLSID {xxx1} failed due
to the following error: 80070005" error.

I don't get this error running in debug mode (i.e., the service can grab
control of the The Package even if it is already up and running).

2. If The Package is not already running in the server, the service launches
it and can invoke its (The Package's) functions. Unfortunately, The Package
runs invisibly.

So my issues are: how can I detect if The Package is already running and
take control of it without running into the error message (I'm guessing the
error message is actually due to the fact that "someone else" has control of
The Package when my service tries to take it).

When my service launches The Package on its own, how can it launch The
Package in a "Visible" mode?

FWIW, my design approach to referencing the COM objects is:

1. Create a Class library project. In that class library project, add a
reference to the COM objects. This creates a .NET interop.

2. Create my web service, which references the Class library project.

I took the above approach because I discovered that ASP.NET web services
don't like direct COM object references. If I'm wrong with this, I'd like to
know that too, but my primary interest is in the behavior of The Package when
control is attempted from my service. As I've mentioned, I believe I've
already addressed the "80070005" error, which might be more of an
"application is already running and controlled by someone else" error.

Thanks,
Eric

 

[John Saunders]

It may not be possible to get this to work reliably. Is the package designed
to work in a multi-threaded environment? A web service is a multi-threaded
environment, and there are many COM objects that will simply not work
properly in one. An example is that none of the Microsoft Office
applications should be called from a web service - they are designed to be
called from an interactive application, not from a service.

 

[eja24601]

Hi John,

Thanks for your response. I don't know if the package is designed to work in
a multi-threaded environment or not.

Now, would this work:

Create a stand-in for the web service, i.e., an executable, class library or
service that runs on the server and controls the package. Any requests from
the web are brokered through that service... even just describing it, it
still sounds like a web service to me!

I have access to some existing code written in classic ASP and using the
classic CreateObject/GetObject logic to control this package. I guess I could
take that approach, too, but I was hoping to get something cleaner.
Referencing the COM objects via the Interop and therefore having access to
Intellisense is so cool....

Come to think of it, am I banging my head against the wrong wall? Since I am
building a web app (ASP.NET), couldn't I just control the package directly
from within the ASP.NET web pages via the interop?!?

Thanks,
Eric

 

[John Saunders]

Hi John,

Thanks for your response. I don't know if the package is designed to work
in
a multi-threaded environment or not.

Now, would this work:

Create a stand-in for the web service, i.e., an executable, class library
or
service that runs on the server and controls the package. Any requests
from
the web are brokered through that service... even just describing it, it
still sounds like a web service to me!

I have access to some existing code written in classic ASP and using the
classic CreateObject/GetObject logic to control this package. I guess I
could
take that approach, too, but I was hoping to get something cleaner.
Referencing the COM objects via the Interop and therefore having access to
Intellisense is so cool....

Come to think of it, am I banging my head against the wrong wall? Since I
am
building a web app (ASP.NET), couldn't I just control the package directly
from within the ASP.NET web pages via the interop?!?

The wall you're banging your head against is the old COM application that
does not support multi-threaded environments.

Sorry to inform you that ASP.NET web applications have the exact same issue.

How was this COM package used before? In a desktop application? However it
used to work, that may be the only way to successfully use it.

 

[eja24601]

Hi John,

The wall you're banging your head against is the old COM application that
does not support multi-threaded environments.

Sorry to inform you that ASP.NET web applications have the exact same issue.

How was this COM package used before? In a desktop application? However it
used to work, that may be the only way to successfully use it.
--

Yes, the COM package is part of a desktop application. It has been
successfully used before as part of an ASP package, as I may have mentioned
before. I may have to explore the CreateObject/GetObject approach worst case.

If I may go off-tangent here: I' ve been doing my development in Windows XP.
However, I've just been told that the production environment may be upgraded
to Vista. I was originally doing the development on a Vista PC, but I was
having trouble creating a COM reference in VS 2008 (going through the same
steps in XP, I succeed). Is this by design on Vista, or is there a
work-around (i.e., a security setting) for allowing the reference to be made?

Eric

 

[John Saunders]

Hi John,


Yes, the COM package is part of a desktop application. It has been
successfully used before as part of an ASP package, as I may have
mentioned
before. I may have to explore the CreateObject/GetObject approach worst
case.

If I may go off-tangent here: I' ve been doing my development in Windows
XP.
However, I've just been told that the production environment may be
upgraded
to Vista. I was originally doing the development on a Vista PC, but I was
having trouble creating a COM reference in VS 2008 (going through the same
steps in XP, I succeed). Is this by design on Vista, or is there a
work-around (i.e., a security setting) for allowing the reference to be
made?

Sorry, I don't know. I don't yet develop on Vista.

I think you're going to have a problem here. See
http://msdn.microsoft.com/en-us/library/ms230195.aspx.