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.
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 have a Windows Forms Application which runs on a server. I need this Application to always start automatically. Even if the Server just gets restartet and nobody logs into it the Application should run.
So the solutions with Registry don´t work here. I than read into Windows Services but it seems like I can´t start a WinForm Application with it.
Does anyone have an idea how I can achieve this automatic Start on Server startup?
The way we do things like that is that we create a Windows Service which runs without the need to have anyone logged in, and then if there is a need we have a separate GUI application (WinForms in your case) which interacts with the service, when needed.
The communication between the GUI application and the Windows Service is usually done by means of named pipes, but if you can get away with something simpler, like the GUI application saving a configuration file for the service to pick up, you might make it easier for you.
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.
Im looking for some advice on an application im creating using a windows service. Basically we have some timesheet software and i need to create a windows service that will poll a db to see if they have completed last weeks timesheet. If they havent completed it i want the application to popup a message stating that it is incomplete and that they should go and complete it.
Ive created a simple service from a tutorial i found and got it to install and run fine. I now need to think about the form side that popups up. Thing is im not sure its a good idea to do this from a service. Can anyone give me a steer on the best way to develop this application using a windows service.
as mentioned earlier you may not create userinterfaces from within Services. In order to achieve this. you have to build another application. you can use Windows Forms or WPF for building the NotificationArea inteagration application.
I would use WCF with net tcp binding to communicate between both applications.
Well as you aslmost said your self. This is not well suited for a windows service since there is nothing going on when a user is not logged in. If on the other hand you were also sending mails AND showing pop up a duel approach would be ideel.
I recommend scrapping the service and only use your form.
You could develop ANOTHER WinForms application that reads from a Database (for example) every X seconds
Your Windows Service will write to the Database indicating whether the job is done or not.
once your Winforms application (that can sit in the system tray for example) reads from the database and sees the job is not done - make it pop up and alert the user.
Just a thought!
I have a Windows service which I want to periodically execute an external program. I'm currently doing this the usual way
Process program = Process.Start(#"C:\mpewatch\db_parameters\DBParameters.exe");
This doesn't seem to be working. I'm executing this from a separate thread which is started in my service's OnStart handler. Is there any conceptual problem with this? Is it not possible to execute external programs from a service like this?
You can execute external programs from a service, but there are security issues. For example, your service may be running under an account which does not have read access to the folder where the external program resides, even if your interactive account does have that access.
For test purposes, try to configure the service to run under your interactive account. If the program is invoked as expected, then the problem with the original account is that it does not have sufficient privileges to run the program.
Your question didn't indicate the operating system.
On Windows XP, you can configure your Windows service to interact with the desktop by opening the service control panel, double-clicking your service, selecting the Log On tab, configuring the service to run as local system, and checking the checkbox. It's pretty straightforward. You might try testing with something like Notepad.exe just to see if you can get it working.
On Vista (and presumably Windows 7), however, you may be out of luck. I have read that the ability for Windows services to interact with the desktop has been removed in Vista. I forget what the terminology is, but basically services will run in "shell 0," whereas users will occupy "shell 1". User applications will be able to communicate with services and vice versa using technology like WCF, but services will not be able to communicate directly with the desktop. For example, any error boxes that pop up will have to be dealt with by swapping to "shell 0." Again, this is based on something I read a few months ago, and I haven't gone looking at it again. For me, I've structured my Windows service to be configured using WCF via a front-end app.
I'm sorry I don't have a link for you, but if your service will eventually have to migrate to a newer OS (or you are already there), this is something to check on.
Another critical consideration with Windows Services is that there is no GUI. Technically, there is an option to allow the service to interact with a local GUI, but you will not see it. This is due to services running as the Local System user.
Within a service, any modal dialog box (OK, Cancel, etc) is considered an error.