Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ok, I hope this is not too much confusing (with my poor English). I want to build a small .Net 4.0 app which monitors several other applications on a Windows Server OR on a regular Windows PC. It will have a WPF GUI with a variety of graphical controls.

The app will be used in the following scenarios:

  1. If installed on a PC it should run as a “normal” single Windows desktop app
  2. If installed on a Server, it should run as a Windows Service. To use/manage the app it must have the same WPF GUI as in scenario 1 and the GUI should be run on the Server or on a remote PC

At the moment I consider to write the application logic and connect it to the WPF GUI using a self-hosted WCF Data Service IN BOTH SCENARIOS. Since I’m not a pro developer I suppose it’s possible that I've missed something ;-)

Will this work? Are there other/better solutions? Any answer or comment is highly appreciated.

share|improve this question
Related:… – Adam Lear Dec 20 '11 at 14:43
Your English is better than around 90% of the kids over here (England) nowadays.# – Darren Young Dec 27 '11 at 18:48
haha! thanks :-) – Mike Dec 27 '11 at 22:17
up vote 5 down vote accepted

You will need to write two separate parts: the service back end (which has no GUI) and the front end controller (the GUI). They will need to communicate using some form of windows interprocess communication.

Doing this as a single application may be possible, but in the windows service case it would have no GUI so still need a separate one. If you are really clever you might be able to write a single program that can be both the front and back end parts, but this probably makes the program more complicated than it needs to be.

Remember on Windows Vista and above a service has no interaction with the desktop at all.

As you say you are not a pro developer, this will be a big challenge to you. Doing what you want is complex. It is easier in .net than in plain WIN32, but be aware that your application then has a reliance on the .net framework being installed (you may need to choose your framework version carefully).

share|improve this answer
+1 thankfully though, for Windows 7 .NET updates is part of windows updates. Unfortunately, not everybody has Windows 7. – Jetti Dec 20 '11 at 3:38
Getting a particular version of .NET installed on Windows XP or later is not that hard. – JeffO Dec 20 '11 at 3:48
Getting .net might not be that hard. "Hard" depends on your users. If you are aiming at Mum and Dad, getting .net is so-damn-hard-your-eyes-will-water. If dealing with a s/w professional, its pretty easy. Depends on your objective. – quickly_now Dec 20 '11 at 7:01
Thanks a lot for your answer and the comments. So, what about this solution: I create a VS Solution with 3 projects: 1) Class Library Project for the back end which has no GUI, 2) a Windows Service Project which implements/runs the assembly from the Class Library Project and exposes a WCF Data Service for the GUI and 3) a WPF GUI Project which implements/runs the assembly (using late binding) from the Class Library directly on a PC OR it connects to the Windows Service using WCF if installed on a Server. Would this work? – Mike Dec 20 '11 at 15:45
Dont know :) Not a .net expert. You could create a class library which defines your inter-process comms. Then use 2 solutions (applications) built off that common library - one is the back end service, the other is the GUI. You then just install this everywhere. Users of a workstation or a server should not really need to know or care if the application is one big lump, or two, if you package it up right and install it. This also solves a separate problem which is the detection of platform type you are on to change install or run-time behaviour. Avoiding that is nice if you can do so. – quickly_now Dec 21 '11 at 5:20

Not sure this will be so difficult. Do your front end code as Silverlight or WPF, back end in WCF. The Silverlight oriented WCF-RIA will make most of the data plumbing fairly simple.

share|improve this answer

This is an interest question, and It is similar as a project which is under progressing.

we have requirement to monitoring a ini file changed event, the ini file is a output of a hard device, whenever the ini file changed, we need read all information from the file and store them into a file database. Then we should provide a GUI to view the file database.

What I choose to use is creating a Windows Service to WCF lib which can provide inter process comm and creating a windows form as GUI to consume WCF interface.

Hope this can give you a hint.

share|improve this answer
Thanks for your answer. I'm also using WCF through Named Pipes. Unfortunately, WCF Data Services works only over http :-/ – Mike Dec 27 '11 at 22:21
@Mike: that should not be a problem because WCF supports self-hosting. – ThomasX Mar 30 '12 at 11:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.