Updated for clarity, hopefully...
Yes, I was wondering if there are any use cases to say
Program p = new Program();
Yes I am referring to the Program class that comes with a new Console App template.
What are some use cases where you would want to instantiate the Program class in a c# console app?
If you, say, want to run multiple threads (as in a service app), each with their own copy of Program, it's useful to be able to:
Program p = new Program();
Main() won't automatically be called in these instances. This lets you, say, create service threads if the app is running as a service, or run some interactive console code within main(), depending on how the app was started. This is very handy when debugging services.
When you don't need a GUI -- when you don't need user input. Or you only need very simple user input (say..... in test code).
If your app will be running unattended on a server -- why have the overhead of an un-viewed form?
If good UI was not something you needed, but you do still need to display something.
I have written Win forms apps that could be executed silently... that is without showing the form, executing, then ending.
One very good reason might be to make sure an app can run when no GUI can be. On many linux servers and Windows Core installs GUI apps are not an option.
Related
I have a C# console app. This console app is intended to run in the background as long as my computer is running. At this time, that console app looks like this:
static void Main(string[] args)
{
while (true)
{
if (args.Length > 0)
{
Console.WriteLine("Args received!");
foreach(var arg in args)
{
Console.WriteLine("Arg: " + arg);
}
}
}
}
The console will initially load a lot of data. That's why I want to keep it running instead of always starting it. Still, once it's running, I need a way to "call" it again from another console window.
At this time, I'm thinking of starting the console app shown above using
START /B MyConsole.exe
from the command line. Then, I want to pass data do it in another console window like this:
MyConsole.exe --data [some info here]
This doesn't feel right at all. In fact, I'm fairly confident this won't work. Still, I need some way to have a running console app and pass data to that app from another console window via a command as shown above. The reason why I'm set on the approach shown above is ultimately I'm integrating with a third-party app that let's me execute command line commands. But, because my data is so large, I need to first have that app running.
How can I do this in C#?
Thank you!
The keywords here are inter process communication.
The easiest way to do this might be pipes.
Although not the newest and hippest technology anymore, I think your best bet on making pipes work easily in C# is WCF.
You could always host something else in your console application, like ASP.NET.
Your console application that is holding all the data might be better implemented as a windows service.
Maybe if you data is in fact just files, maybe using a memory mapped file might be easier than the inter process communication.
That said, communication between processes is a lot more complicated than command line parameters. None of those suggestions is particularly easy to implement (at least compared to a console application) and a lot of the details depend on the details of what you want to do.
I would create self-hosted ASP.NET Core Web Api application which will expose some rest endpoints so you could change your arguments based on the data sent (save it somewhere in memory, whatever). In the background there maybe an implementation of IHostedService running and doing some work in a loop based on the data sent.
I am having to design a client application that will be installed on all computers in our company that will collect and report hardware and software information for inventory purposes to a SQL database. The application may need to be updated remotely and possibly some parameters such as polling time period be updated remotely as well. I am not entirely sure of the best way to architect this type of application. In trying to research and think this through I have come up with the following options:
write a Windows Service that would always run automatically, anytime a computer booted up and on a Timer have it perform the necessary inventory functions.
write a Windows Service that acts like base platform for future expansions, but contain the actual inventory client in a Forms/WPF app that is minimized to the system tray and can be opened to change settings. The Windows Service would verify that the Forms/WPF app is always running and handle any management tasks such as possibly performing upgrades on the Forms/WPF app.
write just a Forms/WPF app that is configured to run on Startup. It would be minimized to the system tray and on a timer perform the inventory function and report to the database.
That is the three main options I have come up with. I'm hoping someone who has tackled a problem like this in the past can provide some insight into how they designed their project. Any advice is much appreciated.
In case anyone else has a similar question, the path I've ended up taking is to create a Windows Service that has all of its main logic in a separate dll and has a separate program for updating. The Update program stops the service, moves/overwrites the dll's for the service and then restarts the service. The main dll that the Service runs processes on a polling/timer feature and periodically checks for and downloads updates and then can schedule the Update program to run. I found a great example here.
Even though I've already chosen how I am going to implement this project, I am still open to hearing how others have handled similar situations.
I need to write a program in .NET which runs every few hours and does some task. It does not require user interaction but it needs a configuration file like App.config where I can put that configuration information.
So should I write console program in C# ( like php or perl script) and schedule it in task manager ( like crontab) or write a Windows Service or something else?
If you want scheduling capabilities and that schedule needs to be very configurable, a windows scheduled task does that pretty well. You would write that as a console app.
However, I would suggest a service for most things. Here is a great tutorial that talks about how to create windows services. Its much easier than you think.
http://www.switchonthecode.com/tutorials/creating-a-simple-windows-service-in-csharp
My suggestion would be to go for the console app and use the task manager.
It saves you from having to implement a custom timer
It gives you elaborate control over timing
It saves you from having to implement an UI
It gives you automation options, like piping in- and output at the command line
Depending on the complexity of your task the best option would be to create an application which can be run via a task scheduler. If you need to run something every few hours a windows service would also work, but remember if you create a windows service then you will have to use a timer control within your application which might hang up without giving any clues. There are lots of examples for both the concepts and instead of using windows service you can use Window Communication Foundation (WCF).
I running a process for doing some task. Suppose 10 person are requesting to run that process then what will happen?
Whether it will maintain a queue or ?
I am writing the program in C#.
Any answers will be appreciated :)
If you have a simple Application, windows will always create a new process and load the executable within this place.
To have a single application which will get notified if the same user starts the same application a second time you can use the SingleInstance approach.
If you want that several users on the same machine will use the same instance you need to break down another fence. This can be achieved by using a windows service. In this case every user start it's own GUI (maybe using the SingleInstance behaviour) and this GUI will sync the showing up task list with a running service in the background.
Further infos about writing services you find an stackoverflow, google or at msdn.
Is it possible to run a windows form application or a console application under system account? Like asp.net application can run under system account by changing machine config file :
<processModel userName="machine" password="AutoGenerate" />
This is to give more privileges to the program ...
It sounds like you're attacking the symptom rather than the problem. What exactly does your program need to do that requires additional permissions? Maybe there's a different way of accomplishing that task without requiring any kind of elevation.
Yes. You can run any app under the system account. One technique is to launch it as a scheduled task, or by using the "at" command line utility.
Unfortunately, however, since Windows Vista, applications run in this way can't interact with the user, since they run in a different session.
This means that running a WinForms (or any kind of GUI, really) application in this way is kinda pointless. Similarly for a console app, if you want to see the output.
If it's for a one-off, you can probably live with it. Otherwise, you should be looking at creating a Windows Service, which can be configured to run under any user account (including SYSTEM). If you want to interact with it, you'll need to implement a separate app that talks to it through (e.g.) .NET remoting.
Can't you do that by launching it from a scheduled task in Windows?
That depends on what your goal is. If you want it to run under the system account and let a user interact with it, you can't do that. If you absolutely need to do this your best bet it to create a service that handles the operations that require additional priveleges and runs as System, and the connect to that service from a GUI running as user. However, if you go this route, realize that you're creating a hole in the security boundary between what a standard user can do and what System can do so be sure you protect the connection between the GUI and the service and limit the scope of the service to only what you absolutely need it to do.
As lassevk mentions if you just need to do this once or occasionally you can use runas to run in another security context but still have an interactive GUI / console.
On the other hand, if you just want it to run unattended at a certain time, you should be able to use the task scheduler like Martin suggests.