views:

248

answers:

2

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.

+2  A: 

You can definitely do this:

  • create a console app which hosts your ServiceHost
  • make that console app aware of a bunch of command line parameters (or configure them in the console app's app.config)
  • launch the console app using Process.Start() from your UI app

That should be fairly easy to do, I'd say.

marc_s
Great! Thanks for the answer. I suppose that is the approach I am going to take. I needed to run it past someone to validate and you have. Thank you!
Luke Machowski
A: 

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.

Matt Davis
it's an IIS / ASP.NET limitation - not strictly Windows per se
marc_s
Good to know. Thanks.
Matt Davis
Thanks for the insight. I have been doing extensive testing of the memory limitations (particularly around loading large models files) and there definitely is a 1.4GB limit to the memory that can be allocated. .NET itself hogs the remaining ~1GB that takes us up to 2.4GB for a 32bit process.Thanks for the idea around the appdomain. The reason I can't use that is because it seems to share the memory with the rest of the process. I need this to squeeze out every last bit of space for my model on a 32b machine. I thought memory was managed by .NET as you described, but alas its not!
Luke Machowski
Interesting. Thanks for letting me (and everyone else) know.
Matt Davis