Hybrid Windows Service + Console App

  • Thread starter Thread starter Chris Mullins
  • Start date Start date
C

Chris Mullins

For some reason the question, "Can I make an EXE that is both a Windows
Service and a Console Application?" has come up quite a bit for me over the
last few weeks.

I've been doing this for years, but for some reason I've never seen it
documented anywhere. C# (or VB.Net) is perfectly happy to create an EXE that
can be:
1 - Both a WinForms App or a Windows Service
2 - Both a Console App or a Windows Service

(or, indeed, any combination of the three).

This is typically useful for debugging - it's nice to have a single .EXE
that you can run from the command line (with "-debug"), or start as a
Windows Service. The classic trick of "push the code into a Class and create
two Exe's" always struck me as a bit silly.

I added this, along with the relevant C# souce code, to a blog entry at:
http://www.coversant.com/dotnetnuke/Default.aspx?tabid=88&EntryID=19
 
Hello Chris,

It's absolutely wrong approach to add UI to the service, because they work
in the different context with different security and service can be run before
any logged user.
You need to use any kind of IPC to communicate between UI and service

CM> For some reason the question, "Can I make an EXE that is both a
CM> Windows Service and a Console Application?" has come up quite a bit
CM> for me over the last few weeks.
CM>
CM> I've been doing this for years, but for some reason I've never seen
CM> it
CM> documented anywhere. C# (or VB.Net) is perfectly happy to create an
CM> EXE that
CM> can be:
CM> 1 - Both a WinForms App or a Windows Service
CM> 2 - Both a Console App or a Windows Service
CM> (or, indeed, any combination of the three).
CM>
CM> This is typically useful for debugging - it's nice to have a single
CM> .EXE that you can run from the command line (with "-debug"), or
CM> start as a Windows Service. The classic trick of "push the code into
CM> a Class and create two Exe's" always struck me as a bit silly.
CM>
CM> I added this, along with the relevant C# souce code, to a blog entry
CM> at:
CM> http://www.coversant.com/dotnetnuke/Default.aspx?tabid=88&EntryID=19
CM>
CM> --
CM> Chris Mullins MCSD.Net, MCPD Enterprise
CM> http://www.coversant.net/blogs/cmullins
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
 
I think you're missing the point - I'm not advocating adding UI to a
service. I'm advocating a way to very easily debug 99% of the service code
that your write.

There's always that last little bit that can't be debugged this way due to
security context differences and other issues.

The typical approach requires running the service, then attaching to the
process and debugging from there. It's much easier to debug if you can just
"run" it like a normal console application.
 
Hello Chris,

Yep, a little bit missing :)

CM> I think you're missing the point - I'm not advocating adding UI to a
CM> service. I'm advocating a way to very easily debug 99% of the
CM> service code that your write.
CM>
CM> There's always that last little bit that can't be debugged this way
CM> due to security context differences and other issues.
CM>
CM> The typical approach requires running the service, then attaching to
CM> the process and debugging from there. It's much easier to debug if
CM> you can just "run" it like a normal console application.
CM>
CM> CM>---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
 
Back
Top