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.
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’m working on a windows app composed of two parts:
An agent, running in the background.
A main application with a window to start/stop the agent and configure it.
What I understand is that I should use a “windows service” for the agent.
But I’m not sure how this is supposed to be packaged? (Can I have these two parts in the same .exe?)
And how the agent and the main application can communicate (should I use a shared file? Can my agent have a private folder to work in?)
I’m looking for some architecture advices basically
Running the agent as a service is probably the best way to go. It'll run without anyone needing to be logged in to run it, and Windows provides extensive monitoring support for services. You can use the sc command to install, start and stop a service, and it even supports controlling services on other machines if you've got the appropriate permissions.
In order to have your gui communicate with it you could look at using WCF. It will allow you to define your interactions with the service as C# classes and will save you having to worry about checking shared directories or looking into a shared file etc. This approach will also make it easy to support multiple clients at the same time, whilst something like a shared folder approach will make this difficult.
You will need to have to separate .exe files, one for the service and one for the windows application. You can package these are two separate MSIs within Visual Studio, the benefit here is that if you need to move the service (for whatever reason) you are not then also packaging up the Windows App and leaving it where ever you install the service.
There are different ways you can have them communicate without getting massively complex. you could read from a text file, as you've suggested, but this could cause locking problems. When I've had to do similar I created a simple database in SQL (or any brand of database you wish), and have the Windows App insert / update configuration options to a table, and the service then reads the table to get its settings.
I am writing a windows service to process emails on a daily basis. This service includes a App.Config file, which has several parameters for the service to work accordingly.
Every time, the admin user has to go and change / add / delete the pair inside the section using a text editor.
I am planning to include a windows form to load all the pair from the section and thinking of doing any modification through the form.
All I would like to know is whether it's possible to have a winform inside a windows service and open it when ever the configuration needs to be changed? I know we can have a seperated windows application and load the App.Config file of the windows service. I just want to avoid having a seperate app for this.
If you have done something very similar to this, please share your thoughts!
Regards,
Sriram
That sounds like a security issue if nothing else.
A Windows service runs in a different context and account and cannot interact with the desktop unless specifically allowed when installing the service. This is not enough of course so you'd also have to have the service running under the same account that is running the desktop - this in itself is really bad design and not something I would recommend.
You could also have the service executable decide what to do during launch, a common pattern is to have it spawn as a console application when debugging to simplify development. But then you'd have to stop the service and launch the service executable manually interactively to get the UI behaviour.
In any way, a separate configuration tool is the way to go.
How can I load a 'login form' in OnStart event of windows Service?! I know windows service is incompatible with UI. but I need to do this without using windows startup..
Is it possible? and how?
Thanks a lot.
How can I load a 'login form' in OnStart event of windows Service?
You cannot do this, because Windows services cannot display a user interface.
I know windows service is incompatible with UI.
Oh. You already knew that. Good.
but I need to do this without using windows startup..
This does not change the fact that it is not supported and will not work.
Is it possible? and how?
No, because:
windows service is incompatible with UI.
So what do I do!?!
The real answer here is that your design is wrong.
If you need someone to log in to your application, you should not be creating a service.
Just make a standard Windows application (e.g., using Windows Forms or WPF) and set it to start automatically when any user logs on to the computer. This can be accomplished easily by adding a shortcut to it to the All Users "Startup" folder.
Then, when your app runs, you can display whatever UI you need to, without the limitations of a service.
If you need to combine UI interaction with a service, you ought to write two programs - the service, which exposes some kind of API, and a client program that interacts with that API (using whatever IPC mechanism you want to choose)
Just remember that multiple users can log onto the same machine, so you ought to write everything to cope with multiple instances of the client program running at the same time.
I was not quite sure how to phrase this question.
What I want to do is create a simple server type application in C# which simply listens for incoming socket connections and handles them the way I specify. It could be a chat application or something like that, very simple.
I looked at the example: http://msdn.microsoft.com/en-us/library/fx6588te.aspx about asynchronous sockets.
I understand the code in the example except I'm uncertain about how the code would execute. Specifically, what would be the entry point of the application in the example? How would the server know to start it?
My only experience with IIS is in web forms with C# codebehind. I understand that the code for web forms is executed when the url points to the location and then again on postbacks etc.
Where it gets foggy for me is when I don't want to use a web form but simply a collection of C# class files with a single entry point (similar to a java application).
Edit for clarity:
The goal of what I want to do is to create an application which I can put on my web host which will continuously accept requests from client applications and handle them the way I will specify and then return information to the clients. I'm just not sure how to tell the server to start the application since I only know about web forms.
Also, it would be fine if I needed to initially direct my browser to a web form and, say, press a button to start the application. In fact, it would be ideal if I could start and stop the application at will.
Also, I may have used incorrect terminology. I thought IIS servers were what you called a server which can run asp.net applications. I could be very wrong about this.
Thanks.
you cannot use IIS to start windows applications, you need a windows service application that constantly listens to the port specified, and that windows service application needs to be scheduled to start either at system start up or at any event of your choice. and that windows service applications needs to stay in memory as long as you want your app to function.
PS: your question seriously needs some editing, but I am also new to SO, so I will let respectable senior users to do what they are best at.
EDIT: If you want to simulate windows service using IIS than here are your closest bets, please follow the links to know what you need to know.
Simulate Windows Service Using ASP.NET App
Forcing your Application to Stay alive
These two links will help you keep alive your application and bamm, you can create any number of classes (Java style as you quoted) to perform whatever tasks you want it to perform
It sounds to me like you don't want to use IIS at all. IIS handles the listening for you and is the "service" to manage requests. If you are lookng to manually listen for incoming connections, then you will need the following components:
A windows service running that has..
A http listener built into it.
Take a look at the C# HttpListener class and look at the process for building a window service that can run in the background of your server.
This isn't all that difficult, but I'm not so sure it's what you need. If you don't want to use webforms, you can have a web application that resolves requests straight to custom handlers which i THINK is what you're actually looking for and makes having your own listener overkill.
EDIT: Additional info on custom handlers
Here is a start on what a custom handler is and how to use it:
http://support.microsoft.com/kb/308001
I would also look at some beginner articles on MVC3 from .net. MVC is a framework that doesn't have any of the fluff (such as viewstate) that webforms has and allows you to route a URL (request) to a Controller (class) and return pretty much anything you want. There are a lot of advantages to using MVC and if you are coming from a java/pure http background it will make much more sense than webforms.
You can get started with that one by searching around for "getting started with .net MVC3" or even start with www.asp.net for beginner resources.
Unless your goal is to learn low level TCP communication, writing and configuring services, dealing with code changes, writing own serialization/request parsing than sticking with IIS and HTTP maybe easier approach.
There is no need to use WebForms - WebService (ASP.Net or even WCF) or MVC Web API will give you ability to implement methods you want without need to write your own custom serialization and request parsing infrastructure. You can even do long poll if/when needed (i.e. SignalR).
I'd start with basic MVC application reporting JSON results as server side as it will still show all issues involved with writing chat client (persistence, discovery of other clients, quick status updates) while allowing you to focus on communication itself (including easily see all traffic if need).