如何启动 WCF 服务的进程外实例?
我想从另一个(UI)应用程序启动 wcf 服务主机的新实例。我需要该服务脱离进程,因为我想利用 32 位 .NET 进程的整个 1.4GB 内存限制。
明显的方法是使用 System.Diagnostics.Process.Start(processStartInfo) ,但我想知道这是否是一个好方法。我计划将服务主机 exe 与 UI 应用程序捆绑在一起。当我启动该过程时,我将传入 WCF 服务的关键参数(如端口和地址等)。然后,UI 应用程序(或其他应用程序)将连接到这个新进程以与服务交互。一旦服务一段时间没有活动,它就会自行关闭,或者 UI 可以显式调用来关闭服务。
I would like to start a new instance of a wcf service host from another (UI) application. I need the service to be out of process because I want to make use of the entire 1.4GB memory limit for a 32bit .NET process.
The obvious method is to use System.Diagnostics.Process.Start(processStartInfo)
but I would like to find out whether it is a good way or not. I am planning on bundling the service host exe with the UI application. When I start the process, I will pass in key parameters for the WCF service (like ports and addresses etc). The UI application (or other applications) will then connect to this new process to interact with the service. Once the service has no activity for a while, it will shut itself down or the UI can explicitly make a call to shut the service down.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您绝对可以这样做:
ServiceHost
的控制台应用程序,我想说,这应该很容易做到。
You can definitely do this:
ServiceHost
Process.Start()
from your UI appThat should be fairly easy to do, I'd say.
也许我在这里完全偏离了立场,但我不认为 .NET 进程有 1.4 GB 内存限制。为每个进程分配的内存由操作系统管理。对于 32 位操作系统,有 4 GB 可用内存空间,但该空间由所有进程共享。因此,虽然看上去只有 1.4 GB 可用空间,但从技术上来说这并不正确。
我提出这个问题的唯一原因是,解决此问题的另一种方法是将 WCF 服务加载到 UI 应用程序内的单独 AppDomain 中。 System.AppDomain 类可以被视为进程中的轻量级进程。当您使用完 AppDomain 后,也可以将其卸载。由于 WCF 可以跨越 AppDomain 边界以及进程边界,因此这只是另一个考虑因素。
如果您不熟悉 AppDomains,@marc_s 推荐的方法是最直接的。然而,如果您正在寻找一个了解AppDomains 的借口,这将是一个很好的机会。
Perhaps I'm completely offbase here, but I don't think there is a 1.4 GB memory limit for .NET processes. The memory allocated for each process is managed by the OS. For 32-bit opeating systems, there is a 4 GB memory space available, but that is shared among all of the processes. So while it may appear that there is only 1.4 GB available, it's not technically true.
The only reason I bring that up is to say that the other way to approach this would be to load your WCF service inside a separate AppDomain within your UI application. The
System.AppDomain
class can be thought of as a lightweight process within a process. AppDomains can also be unloaded when you are finished with them. And since WCF can cross AppDomain boundaries as well as process boundaries, it's simply another consideration.If you are not familiar with AppDomains, the approach that @marc_s recommended is the most straightforward. However, if you are looking for an excuse to learn about AppDomains, this would be a great opportunity to do so.