简而言之，应用程序从数据库中查找要做的事情的指令，执行操作，并将有关该操作成功或失败的信息保存回数据库。它执行大约 40 种不同的操作，例如自动化 Office 应用程序、复制文件、运行搜索等。
该应用程序是单个 EXE，因此所有内容都在主应用程序的进程空间中运行，这一直是不稳定的主要根源，因为它必须加载大量第 3 方 DLL 来完成工作，它们通常会做一些令人讨厌的事情，导致整个应用程序崩溃。
计划：我想将执行危险繁重任务的代码从 VB6 exe 移至独立于主应用程序运行的外部进程中。原始应用程序将仅处理数据库内容并启动其他进程来完成其投标。
最好的方法是什么？如果我还在使用 VB6，我想我会构建 ActiveX EXE 来执行此操作，但我不确定 .Net 的等效项是什么。理想情况下，VB6应用程序将声明一个实例化外部进程的对象，并使用该对象设置参数的方法，执行该进程，可能接收进度通知，最后接收操作结果。
解决这个问题的最佳方法是什么？
谢谢！！
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!!
发布评论
评论（2）
嗯，不能说我以前尝试过类似的事情，但是
一个可能的解决方案
另一种可能的解决方案
另一种可能是使用 Windows Workflow Foundation 4。它相对稳定且相对易于使用（我自己也涉足过）。我不知道它是否提供您需要的隔离，但值得一看。
您基本上可以编写自己的自定义活动来执行您的操作，然后通过 WorkflowInvoker 动态执行它们。
另一种可能的解决方案
另一种替代方案可能有点严厉，但在单进程托管方面更传统，并提供您所需的隔离，那就是研究 托管外接程序框架 [MAF]（查看链接中有关隔离级别的部分）。这可能有点吓人，但我的朋友 Kent Boogaart 用它做了一些漂亮的事情 ，如果你把事情简单化，它可能会扭转局面。
Hm, cannot say I have tried something like this before, but
One possible solution
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.
在您的情况下，生成另一个进程（通过控制台应用程序或其他方式）可能不是一个好主意。您必须担心与该流程的沟通，这可能是一个真正的麻烦，而且它不会真正给您带来任何稳定性。我可能会做的是使用 VB.NET 制作一个使用 BackgroundWorker 线程。
这将使您能够在 .NET 库内的后台工作，并且只要您小心处理异常管理（在 .NET 库内），它就不会真正影响 VB6 应用程序。 VB6 应用程序可以等待 .NET 库完成繁重的工作并为其提供友好的消息。
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.