Gradually refactoring pieces of a giant, monolithic VB6 winforms app to .Net

Question

In a nutshell, the app looks up an instruction for something to do from a database, performs the action, and saves information about the success or failure of that action back to the database. It performs about 40 different actions, things like automating Office applications, copying files, running searches, etc.

The application is a single EXE, so everything runs in the main app's process space and that has been a major source of instability because it has to load a lot of 3rd party DLLs to do the work and they often will do something unsavory that crashes the entire app.

The plan: I want to move the code that does the dangerous heavy lifting out of the VB6 exe and into external processes that run independently of the main app. The original app will only handle the database stuff and initiate other processes to do it's bidding.

What is the best way to do this? If I was still in VB6 I think I would be building ActiveX EXEs to do this, but I'm not sure what the .Net equivalent is. Ideally the VB6 app would declare an object that instantiates the external process, and using methods of the object set parameters, execute the process, possibly receive progress notifications, and finally receive the results of the operation.

What is the best way to go about this?

Thanks!!

Answer 1

In your case, spawning another process (via a console application or whatever) is probably not a good idea. You have to worry about communicating with that process which can be a real hassle, and it's not really going to buy you any stability. What I would probably do is use VB.NET to make a COM-Visible class library that uses BackgroundWorker threads.

This will give you the ability to work in the background within the .NET library, and it won't really affect the VB6 application at all as long as you're careful about exception management (within the .NET library). The VB6 application can wait for the .NET library to do the heavy lifting and feed it a nice friendly message.

Answer 2

Hm, cannot say I have tried something like this before, but

One possible solution

1. Write an application\service that a) spawns child processes, and b) hosts a WCF service to facilitate communication between processes
2. Write child processes to process "Actions"

Another possible solution

An alternative may be to use Windows Workflow Foundation 4. It is relatively stable and relatively easy to use (having dabbled in this myself). I do not know if it offers the isolation you require, but worth a look.

You would essentially authour your own custom activities to perform your actions, and then dynamically execute them via WorkflowInvoker.

Yet another possible solution

Yet another alternative that may be somewhat heavy handed but is somewhat more conventional in terms of single-process hosting and offers the isolation you require, would be to look into Managed Add-in Framework [MAF] (check out the link's section about isolation levels). It may be somewhat intimidating, but my friend Kent Boogaart has done some nifty things with it, and if you keep things simple it may just turn the trick.