I have a program starting up through the registry, but I want it to start up more efficiently. So I asked some questions and I have found out that a windows service is the way forward. I have looked at how to make a windows service but I have not found any answers for what I need.
I am trying to create a checkbox on my application so that when it is checked it adds a service to start up my application when the person logs in, and when it is not checked it deletes the service.
Any help would be appreciated,
Thanks.
This is not the correct way. Services cannot find out when a user logs in since Vista. In your prior thread you got the advice to create two programs, although that wasn't explicitly stated. A service that runs after the machine boots and a user interface that allows the user to communicate with the service after she logs in.
You'll need an inter-process communication mechanism to get them to talk to each other. Named pipes, a socket, Remoting or WCF will work.
Read the MSDN Library docs on the ServiceBase class, that's what you'll need to create a service.
Related
I've scenario to create an application(Windows service , Winforms app) which runs twice every day automatically on users PC. These Users are internal employees in the same network. So at morning and evening this application has to run. But it doesn't need to show any window or information saying its running. Its good to have a simple notification in system tray that its started execution.
My experience in with web application development. So I got a little stucked with these such application on deciding which is best.What my understandings are if its a standalone exe, we could ask all users to download the exe and install.
If its a windows service we may depend up on instalutil to install the service.
So I really needs an advice on this. The application is nothing, just requesting a TFS api and the resulting JSON has to store in Table. So the JSOn will be based on each user using their windows authentication.
Please suggest a good solution to achieve its the best,secure and easiest way even for non tech savvy users.
Instead of all user communicating to TFS server twice a day i guess better way is to install a service in one centralized machine which will run a window service twice a day and that machine will host that service using WCF so that other user will communicate with machine this will help you to distribute the load of tfs api. i used the same approach in my case where one machine talk to ALM and other talk to that machine to get the files.
Creating a window service is pretty simple and straight forward.
Follow the link to make one:
https://www.c-sharpcorner.com/UploadFile/naresh.avari/develop-and-install-a-windows-service-in-C-Sharp/
You can host the service in WCF using IIS, TCP, Webservice, Console application its upto you. Follow this link
https://www.codeproject.com/Articles/550796/A-Beginners-Tutorial-on-How-to-Host-a-WCF-Service
I guess i helped you :)
I'm trying to get started with an application that definitely requires some GUI for configuration management and the application has to poll a web service about every hour (to check for updates/messages) or so. Also, the application is expected to run constantly in the background/system tray.
I'm looking for some guidance on the overall architecture for this application design. Can this be a straight up WPF app or would it be better it is a windows service because of the polling and because it is expected for the application to be running all the time? Do you guys have any suggestions?
Firstly, services tend not to have a GUI. They can, but it's not advised.
What I would do, is have two applications. The service itself which performs the monitoring in question, and a user-interface application (that runs on startup), and provides an interface to the service. Communication between the two can be handled in a variety of ways.
The advantage to this is, your service will run even if there isn't a user logged on, and the UI part is present only when a user is on.
To allow for your GUI to communicate with the Windows Service you can expose WCF services on the Windows Service to provide the operations you need (e.g. Start, Stop, GetStatus, etc.).
See this article on MSDN for a starting point: http://msdn.microsoft.com/en-us/library/ms733069.aspx
I have a WCF service hosted in a Windows service.
This service the WCF have one metohd and in this method I have one important line :
Process Browser = Process.Start("iexplore.exe", hostUrl);
I install Windows service as local system, but when I'm trying to invoke that method, everything seems to execute, except that one important line... and IE didn't open.
I would like to add that the method itself is not in the service itself but in one of the service dll reference
Any idea why?
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/63a7d1ec-7077-489a-a250-f7422f04317b
" in order to get the service to actually show the UI, you'd have to set the service in Computer Management to allow it to interact with the desktop. In the services window in computer management, go to the properties of your service, and on the Log On tab, check "Allow service to interact with desktop" "
Since Windows Vista MS has been adding lots of security-related changed esp. in the area what Windows Services can/can't do. Anything "desktop-like" (printing, accessing network shares, using Office Interop etc.) is harder and harder to get working.
You should rethink your design since IMHO any "server-like process" (for example a WCF service) can be accessed in parallel by multiple requests and thus should NOT use processes which are NOT designed for this type of interaction... what happens if your webservice starts multiple IE instances that way ? Will IE behave as you need/expect it ?
IF you really really MUST do it this way you should have
a normal desktop process hosting the WCF service
OR
two processes, one your Windows Service and one running as a normal desktop process dealing with IE... these two process communicate via IPC
Under what user is the service running? Try running it under the currently logged in user, with privileges to interact with the desktop and see if that helps.
In general, its not a great idea to have services launching GUI processes. For example, what if no one is logged on. What if many people are logged on? Should it open in all sessions... etc. Have you considered exposing a simple (e.g. Net.NamedPipes) endpoint on your service, and writing a small client UI to interact with it?
I've made a console application that I will turn into Windows Service.
I want to have a WinForm GUI (exe file) for that Service, so I will be able to see all the information inside the Windows Service and control it in my WinForm GUI.
For example, if the windows service counts and saves the time passed (or any other information) I want to have access to it in my GUI (I want to see it live).
As well as activating methods inside my Windows Service.
I hope I've made myself clear.
My recommendation would be to use WCF for this. Your service could be a WCF host, and your client could connect to it.
This provides a fairly straightforward, clean way to "control" and inspect the service as much as required.
The ServiceController will only give you access to methods like Start, Stop.
To access any method, you will need to use some form of Inter-process Communication.
As suggested by Reed, WCF is one way...or you can try IPC through Named Pipes, remoting, etc.
I have created an SMS application in .NET.
I wanted that the application should run when the computer starts, even before the user logs in.
Just like the SQL Server.
You need to create your application as a Windows Service. The linked MSDN page will provide full details.
Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the About Services section in the Platform SDK documentation in the MSDN Library.
You could consider making it a Windows Service.
You'll have to write a service. Start here...
Wrap your application in a Windows Service, using the .NET System.ServiceProcess namespace.
The System.ServiceProcess namespace provides classes that allow you to implement, install, and control Windows service applications. Services are long-running executables that run without a user interface. Implementing a service involves inheriting from the ServiceBase class and defining specific behavior to process when start, stop, pause, and continue commands are passed in, as well as custom behavior and actions to take when the system shuts down.
Use ServiceEx to make a service from your executable: http://serviceex.com/ , just write one INI file, you can choose if application's window is hidden or showed etc.