Click here to Skip to main content
15,354,641 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
We are developing a WPF Application that we would like to be install
and run as a Windows Service.
Application is dealing with File Uploading.We need to show balloon
tip messages(Like Upload Failed,Upload Success..etc) in the system tray.
It should be possible to install the Application as a windows service on a server.

Is it possible?
Thanks in advance for any help!!!
Updated 7-Feb-22 4:24am
Sergey Alexandrovich Kryukov 12-Oct-11 10:33am
Interesting question, my 4. I did not vote 5 only because you did not explain your ultimate goals which is always important. However, my vote of 4 is very high; I rarely vote like that for questions :-)
CGN007 18-Oct-11 3:15am
Updated the Question with details...

1 solution

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[^]; 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[^].

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.


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.

CGN007 14-Oct-11 7:05am
Thank you for the reply.I'll update the question with details...
You're welcome. Yes, we can continue this discussion if you need.
CGN007 19-Oct-11 2:16am
I've updated the question.I think now you are more clear about my needs.
Please check...
Venkatesh Mookkan 19-Oct-11 0:29am
How did you do that? Have 5!
Thank you, Venkatesh.
Did what? Such kind of dual-purpose application? Difficult production need pressed me to bite a bullet. Have you ever heard of integration work without source code from another party (different platform and language), debugging robotic manufacturing control application together sitting in different states, having no change to meet, using just telephone, Web camera and Internet? This is what we have done.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900