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!!
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.