Strictly speaking, you can. I've done it. But it might be not what you mean. Let's see.
You can create an application which starts from the same entry assembly (usually some .EXE file) and can be run either under Service Controller (let's call it Windows Service mode) or started from the Shell (interactive mode), but in these two cases
your application should behave like two completely different applications. These two modes can share a lot of common code, but they still should behave in very different ways.
In Windows Service mode, it should not use WPF at all.
It needs some effort to achieve. Well, just two hints: 1) use static property
System.Environment.UserInteractive to detect in which mode your application is running, see
http://msdn.microsoft.com/en-us/library/system.environment.userinteractive.aspx[
^]; 2) get rid of
app.xaml, because it will force starting WPF
Application in all cases; instead, create and run and instance of
System.Windows.Application (or better, a specially derived class) explicitly and only for interactive mode, see
http://msdn.microsoft.com/en-us/library/system.windows.application.aspx[
^].
I'm afraid to discourage you, but these two modes really should be completely isolated to allow
no UI in Windows Service mode.
The Windows Services are not designed to run any UI. Think by yourself: a Window Service can run when a user logs off, when no UI is possible, because there is no Desktop, Shell, etc.
You might ask me: why did I bother to do all that then? Oh, first of all, for convenience.
Windows Service and interactive mode are just different ways to have the same functionality. I used interactive mode for testing and debugging; this way I could put a lot of logging information in screen right away and put some controls for extra functionality convenient during testing and debugging. In Windows Service mode, all logging goes only in Windows log which can be read using Windows "Event Viewer" applet. Also, I included controls for on-demand installation of the service and communication with the Service Controller (Start/Stop/Restart service), something people usually do using the applet "Services".
This all takes a lot of effort, but pays off when you need a lot of debugging, because debugging of a Windows Service is considerably harder compared to interactive application.
[EDIT]
You can also consider different functionality. You can have a separate UI application (WPF or not) which communicates with some Windows Service when interactive applications can run, during user's session. The communication can be done on many different levels, but this is always IPC (
Inter-Process Communication). It can be classical remoting or self-hosted WCF using IPC channel(s) (based on Named Pipes), sockets,
TcpListener/TcpClient, etc.
Again, what you need mostly depends on your goals which you did not share with us.
—SA
Submit an article or tip