I have two application modes one is Console application and Windows Service both suppose to do the same job console will take user inputs and base on user inputs it will proceed with intended task and user inputs will be saved as user settings.
I need Windows service to use the same settings and do the same task in background with scheduling. Currently I'm facing the problem where user settings are not available when reading from Windows Service.
You can save the user settings (at time of running console app) in an XML file and read that file in your windows service and work accordingly
There are 3 possible routes that I can think of to deal with this issue (I will update this later today with more detail when I have more time).
First, combine the applications into a single Program. Modify Program.cs so that you can pass in an argument telling it to run as a Console application or Service. This method helps you to make sure that you are doing the same thing in both uses, without repeating a lot of code.
Second, share the settings file between both projects. This seems to be the basic question you are asking. I'll elaborate on this when I have more time this evening.
Third, ask if you really need the service for what you are trying to do. If the service is only being run at certain times of the day, it might be better to instead focus on allowing the Console application to also run without input, as a Scheduled task.
Related
I need to develop a project using Visual Studio. The project will run constantly in the background, checking a file path. When the image is uploaded to the file path, the application will display the uploaded image as a pop-up on the computer screen. The application will not be triggered by a user. It will constantly run in the Background, checking the file path. Which project template should I use for this? I hope I was able to explain.
I thought of writing windows service. Because it can run in the background. But I couldn't open a picture with it
I see you're a new contributor, so it would be better if you posted a bit more context of what you have already tried. For instance, providing a minimal reproducible example. I ask you this because the way to write Windows Services or Console Applications in .Net Framework and .Net Core (and subsequent) are different. How to ask a question?
That being said, a windows service, by concept, does not have UI and is not allowed to have one. They're designed precisely to only run on the background, without user interaction (at least since Windows Vista).
These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface.
From Microsoft Docs
So it seems that you need to either write your application as a different kind (for example), or create a secondary application that somehow communicates with your windows service. The decision would be up to you based on your requirements and/or possible limitations.
There are some possible alternatives in this possibly related question as well.
I am a newbie to programming So I need lot of support from my friends I am creating a windows forms application and I need that program to run automatically once a day and need to close itself after 2 minutes of the execution how to do it....
I need that program to run automatically once a day
You can use Windows Task Scheduler.
need to close itself after 2 minutes of the execution
You can implement in your application using many different approaches.
For instance, since you write WinForms applications, you can use Timer.
I would like to take the below approach.
Write console application. and add appropriate log message so that you can understand how it goes. if the application need any parameter then pass it from command line or put in a file so that the app can read the file and run automatically.
Add the app to Windows schedule task and monitor log regularly.
if the input parameter changes everyday then just update the input file when necessary.
Hope it will give you a idea.
Thanks.
Ruhul
I'm coding a console application that is reading and writing some stuff at different intervals during the day. I want this later (if its "final") as a service. For now a simple console application is better (that's how I thought) because its easier to use and I can see the result without having to register/start/end the service. Is it easy to later, if I'm done with the testing, just create a new service project and copy the code from the console application?
I heard now that we should not use Timer in a service. But I'm using System.Threading.Timer in my console application a lot. Does it mean that I'll be in trouble? Is it this "testing on console app and then using it on service" thing not a good idea? Any suggestions?
You can create Windows service and Right click->Properties and change Output Type as Console Application do your developement.Once you have done with development change back Output Type as Windows Application.
Take a look at this link to know deep about the both timers.
The problem with System.Threading.Timer is that there's no easy way to start/stop the timer. And because of that, you can't realiably use it for tasks which could possibly take LONGER than the timer interval.
Switch to System.Timers.Timer instead:
http://netpl.blogspot.com/2010/05/systemwindowsformstimer-vs.html
A good solution for you - is to try Application As Service software
You can launch every application as a service.
Background:
Started a fair amount of work before realizing that a Windows Service cannot start an app with a GUI that displays without potential problems. The proper solution of separating the GUI of the app to be started is non-trivial, so I'm trying to think of alternative solutions.
There is a GUI to manage the service that is a separate executable, but the process to be launched (actually multiple instances of it) has its own GUI that needs to be shown. It doesn't need to be made visible by the service itself, but it needs to be at least able to be made visible by another process with a visible GUI. The Windows User that is running the service and that needs to see the GUI of the launched process is the same and known at install time.
Is there some way to accomplish this or is it back to the drawing board?
Also both the service and the app to launch are both our code and modifiable.
My first thought was to suggest that you look at the WTS* functions and CreateProcessAsUser and then I followed the link you provided and saw that you have already considered this and dismissed it.
As an alternative, if I understood you correctly you have a Windows Service and GUI which is used to manage the service. So why not use the communication channel you have between the Service and the management GUI to send a message from the service to the management GUI and have the management GUI launch the other GUI apps on behalf of the service? Of course this would assume that the management GUI is always running.
You might even do this with a hidden application that is not visible and launches when the user logs-in, that way you reduce the risk of the user inadvertantly closing the application, this would be a separate app from the actual management application.
I have a GUI C# Windows form program that I would like to start as a service when the computer starts and perhaps have an icon in the system tray that when clicked maximizes the program. Is this possible without major rework?
Thanks
Windows Services cannot have a GUI, at least not directly. You will have to separate your application to a presentation layer/process and a service layer/process:
The presentation layer will remain a WinForms application
The service layer will run as a Windows Service
The two of them will have to communcate with each other with some means of inter-process communcation, like named pipes or sockets.
You can use a third party app, such as FireDaemon (http://www.firedaemon.com/), to start any program as a service. There are many options available in FireDaemon, such as form visibility, restart on failure, etc. However, it will not automatically create a tray icon for your app. So your app will have to be changed to have its own tray icon functionality and FireDaemon will just start the program and manage the process.
FireDaemon costs about $40 (USD). I imagine there are many other similar applications available.
I would first look into creating an actual service project as mentioned by other answerers, but keep this approach in mind. It has worded well for me in a handful of situations.
It depends on how the code is currently written. I have several WinForm apps that double as services, but the bulk of the work I have separated into another assembly. My solutions for those apps generally have 3 projects: WinApp, Service, and Library (I'm oversimplifying here).
If you feel that your WinForm app could make a good service then you probably have your code in such a state that you could probably separate it out easily enough. Adding a service project is pretty simple, adding the installer for it is a little more challenging but still well documented. The trickiest part is making a deployment package for it that installs the service properly, but again... its well documented as long as you know you need to look for it.
Edit: Just to clarify, in general I wouldn't consider this a major project.
You can write the code to have it run as a service, but I think the more important question is, what does it provide? There are ways of minimizing an application to the tray, and you can start said applications at launch to the system tray.
This is the link that I always refer back to about doing windows services. It is WCF based, but I think with a little modification you could make it work for you:
http://support.microsoft.com/kb/317421
As to minimizing to a tray, there's an excellent answer in this question:
What's the proper way to minimize to tray a C# WinForms app?
You could use Task Manager within windows and setup a task that would execute your application's .exe per windows boot.