>>Well, you could bring up the app, and have some user interface in teh COM to start the processing, but other than that, I don't see how it would help.
>
>Currently, our App runs the LongTask (I keep calling it that), for each dataset (can be more than 10), inside a DO WHILE LOOP. And the LongTask has to finish before I loop back again and run the LongTask if there are still more datasets to be updated.
>
>I was thinking if I move the LongTask out of the app and make it a multi-thread COM server; the DO WHILE LOOP will just instantiate the LongTask now in the COM server, and the app will just go on its way.

That's the way of COM. COM is a connected protocol so whatever you do has to finish before it returns to you. THere are ways around this such as using events if the object supports a COM event interface.

Queued components and COM+ events can provide async operation, but in many cases this is not likely what you want because neither of these mechanisms can return a result to you in any way (unless you code the COM component to store a result somewhere).

You can do a lot of things to 'simulate' this process however, by offloading processing to another application or application server. Message Queue (MSMQ) is one way to do this, although I find it limited especially in a mixed environment with lots of non-sequential events. You can also roll your own and that might provide more flexibility - I did just this with an Async manager class described in an article at:

http://www.west-wind.com/articles.asp

That scenario deals with running async over the Web, but it can be applied to any type of application really.

Bottom line to all of this - if you need a result back from these async requests you're going to have to write some code to make this happen.