I have several running .net service processes and now I want to write a monitor application where the user can see all services and what they are currently doing.
The service write their output to a log file/event log.
The monitor application should present the services (this is easy) and then the user can choose on of the service and sees what the service is doing.
My idea was to poll the logfile (or set a FileSystemWatcher on it) and reload the logfile all the times.
Is there a better way / what are the alternatives?
e.g.
Is is possible to connect to the service process and the service process raises events (with the logtext) to the monitor application process (in Win32 I did that long ago, but I don´t know how to do that in .net)?
Or write to shared memory?
Or is is possible to pass messages through the C# ServiceController?
Ideally, youre service can write its messages into any kind of logger interface. Let's call it IServiceLogger which provides a method like Log(string message). Imaging that your service has a list of loggers implementing this interface and writes into each of them.
With this, you can plug any implementation of that interface to retrieve the logs from the service. So this could be an ServiceFileLogger implementation to write into the file system as well as a NetworkLogger which sends those log messages to all connected clients.
Regarding the NetworkLogger, you still have to do some work to handle the connection between the monitoring clients and the server (the process which receives the logs and sends them to the clients) but you could build really smart monitoring tools and deploy them in your company network or even build a website showing live logs.
Tip:
If you want a more standardized solution, I'd highly recommend to take a look at log4net which basically does the same internally but has a huge set of features on top. With log4net you can use (or create) a bunch of different log appenders which receive these messages and can process them further like writing emails, inserting into a database, writing into files, etc. So I think you can find a matching appender or create your own for your monitoring clients.
To achieve that you can use Windows Communication Foundation. You can expose an event in your service, and your monitor can bind to this event.
This method depends on the implementation, but you can learn about WCF here: https://msdn.microsoft.com/en-us/library/ms734712(v=vs.110).aspx
Related
I am new to .NET and seeking help for the Windows Service Updates Notifications.
I have a use case that is somewhat similar to "https://stackoverflow.com/questions/41232170/c-sharp-show-notification-prompting-a-update".
The application is developed in C#.NET and is deployed and running as Windows Service.
However, the application is not using any MSI installer to install it. I am using a batch script that configures the Windows Service application.
Now, I want to show the notifications about the updates about the Windows Service to the user, when the system gets restarted.
I came across about the usage of WCF or by using the Task Scheduler, but not sure which one would be the better solution.
Please advice.
Ok, there are (were, because MS disabled the first one that I'm going to explain) two ways to notify your user about updates from a service.
First, the bad, ugly (and non-working in recent versions) way: interactive services.
You can configure a service as interactive, if you add the SERVICE_INTERACTIVE_PROCESS flag the service will be able to create a GUI that will be attached to Display_0. This presents a ton of problems (trying to show a GUI when there's no user session, if you have two sessions open only the first one will show the GUI and so on) but it's a cheap dirty way to show data to the user. Avoid it.
Second, the right way: a standalone GUI program.
In this case you create a secondary program that will show the data to the user, you can start it with the user session or let the user decide if he wants to receive info by opening manually this application. This program needs to receive the updates from the service in some way, which is better is up to you but I would use UDP for this, in this way your service doesn't needs to care if any GUI app is connected or not, you broadcast an UDP message and everyone listening will receive it, you don't need to mantain a server that handles connections, you don't need to have an storage in order to maintain the event data and it will support any number of instances of the GUI (if more than one user has started a session in the machine all of them will get notified).
But as I said, that would be my preference, you can do it as fancy as you want, you can use Pipes, use a file that contains the event and use a FileSystemWatcher to get notified when changes happen in it, you can even host an ASP .net web app which implements a SignalR hub and then you can create your GUI in html. It's up to you decide which mechanism is the best for your scenario.
I am writing a service based application, and a UI application within it.
I am using Event Logs to log my error, but some of these errors are critical and user should be aware of.
What I need is to check if The UI application (Windows Application Project) is available, and running... if it's running send the error directly to the UI through a service based application (Windows Service Project).
Now, what to do? There are two step I should take, first check if UI is running, second send info like a class instance or a string or binary data (like using serialize) to the UI and UI receive it.
I think the two applications of yours can interact using the Socket mechanism.
And check this for the "is running" bit:
Checking if my Windows application is running
If you don't mind adding a new dll to your project I suggest to take a look at log4net. There is an appender for remoting, RemotingAppender that fit perfectly your needing. You just need to find some samples on how to implement the "receiver" in your UI app. As an additional benefit, you can use the same library to append in the EventLog, or on a file and so on.
I created a Winforms C# application to spawn threads and run jobs on our production server. I created the jobs in a winforms application because I need a GUI to configure and run the services.
We recently changed servers and I'm logged off after a certain amount of idle time and the application is shut down so I need to make Windows services to keep it running even when I'm logged out. The problem is I need the GUI.
What's the best way to create windows services (because I need them to run when I'm logged off) with a GUI interface?
If you create real Windows Services
you can start, stop and get information about the service by using the ServiceController class
EDIT
If you need data from the service, you could use WCF or a Socket to communicate with the service. Another option is to publish the results of the service in a file that is in a well-known folder.
Spawning a windows service in the user session (= Interactive Windows service) is not a good idea and considered as an exploit. I solved this problem in my project by splitting the application in a GUI and a Service-part, just like kenny said. They communicate via WCF. Another possiblity are Memory-Mapped files.
If you want a simple way to talk between your processes you can also use NamedPipeServerStream and NamedPipeClientStream.
This technology is old, not really clever but easy to use (if you know stream management in C#) and fast.
The only drawback is that they do not talk Object out-of-the-box. But for that purpose I use XML Serialization.
On the sender side : Object => XML String => byte[]
On the receiver side : byte[] => XML String => Object
To keep it simple I always use String[] objects which I parse on the receiver side like I would do in the void main(String[] args) of an application
With services you can also use CustomCommands, but this only ask the service to spawn a method without giving it parameters.
Except if you store parameters somewhere (ie: an XML file) where your service have access to them
I am developing a solution in .Net utilising the VMWare Web Service API to create new isolated virtualised development environments.
The front end will be web based. Requestors input details for the specific environment which will be persisted to SQL. So I need to write an engine of some sort to pull the data from SQL and work on the long running task of creating resource pools, switch port groups and cloning existing VM templates etc. As work progresses, events will be raised to write logs and update info back to SQL. This allows requestors to pull data back into a webpage to see how it's progressing or if it's completed.
The thing I am struggling with is how to engineer the engine which will exec the long running task of creating the environment. I cannot write a windows service (which I would like) as we work in a very secure environment and it's not possible (group policy etc). I could write a web service to execute the tasks, extending the httpRuntime executionTimeout to allow the task to complete. But I'm keen to hear what you guys think may be a better solution to use (based on .Net 3.5). The solution needs to be service oriented as we may be using it on other projects within our org. What about WWF, WCF? I have not used any of the newer technologies available since .Net 2.0 as we've only just been approved to move up from .Net 2.0.
First of all, a Windows Service isn't insecure. One of software development devils is discarding a solution by ignorance or because a lack of investigation, requirement analysis and taking decisions collaborately.
Anyway, if you want to do it in a SOA way, WCF is going to be your best friend.
But maybe you can mix a WCF service hosted by Internet Information Services and Message Queue Server (MSMQ).
A client calls a WCF service operation and enqueues a message to some Message Queue Server queue. Later, a Windows scheduled task executed overtime, checks if your queue has at least an incoming message, and task processes this and others until you dequeue all messages.
Doing this way, IIS WCF host will never need to increase its execution time and it'll serve more requests, while the heavy work of executing this long tasks is performed by a Windows scheduled task, for example a console application or a PowerShell cmdlet (or just a PowerShell script, why not?).
Check this old but useful MSDN article about MSMQ: http://msdn.microsoft.com/en-us/library/ms978430.aspx
I don't understand your comment regarding services being insecure, I think that is false.
However I would look into creating something that uses a messaging bus/daemon.
RabbitMQ: http://www.rabbitmq.com/
MassTransit: http://masstransit-project.com/
NServiceBus: http://nservicebus.com/
Then you can basically use something like WCF, Console App or Service as your daemon.
I have a data loading application that has to be executed multiple times per day at irregular intervals. I am planning to write a service to kick off the downloads and import the data to a database server. Are there advantages to using a standard service over a webservice or vice versa?
I think you're missing the point here.
Web Services typically are used for a form of communication or remote execution. You call a remote function on a web-service to either adjust the behavior of the machine it's running on or to retrieve data from it.
Windows Services are background processes that run on a machine without any "logged on user" being required. They can perform tasks and do things while the user is at the login screen, or do elevated operations. You can talk to services to adjust their behavior or retrieve information, but it's general purpose is different than a webservice.
The biggest notable difference here is that web-services must be called, they don't run on their own.
For your application I would suggest using a Windows (Standard) Service, as you can have it execute code once per day. I would only use a web-service if you've got something else to automate the calls to the web-service and you require a response from the server detailing it's execution result (success/fail/warning/etc...)
You could also consider writing a normal (windows or console) application that is triggered by a Windows Scheduled Task. What you've described doesn't necessarily sound like something that would require a service.
Sounds like a good use of a windows service to me. Off the top of my head, I'd use a windows service if:
1. Work is performed on a scheduled basis (regular or irregular intervals) in the background;
2. No interaction is needed - work is just done in the background and kicks off based on polling or some other type of trigger (message dropped in queue, database value trigger, scheduled timespan, etc.);
3. Needs to be monitored (either starts/stops along with logging) and you can take advantage of WMI, perfmon and event log with little effort.
A web service is better for tasks that are interactive (like if you wanted to initiate the download based upon a request received).
Sounds like a windows service is the approach you should take.
Hope this helps. Good luck!
If "irregular interval" does mean, the application is invoked by another application, I would use a web service.
If the action is scheduled, I would use a windows service.
If you are working with SQL Server (scheduled or not), I would also consider SQL Server Integration Services.