Ok so I have a C# program which handles some scheduled tasks. However I need to be able to call a specific function within this program from windows task scheduler.
I have no code or no starting points because frankly I don't even know the proper terminology to put into a google search... its like I am trying to search for "ferrari" by typing in "things with disk shaped objects mounted on the sides". I just have no idea where to even start. I need someone to just give me a quick brief on where I should be looking to accomplish this task. Once I know where to look I can figure it out.
Heres what I need to do.
I have a c# winforms application that has several functions inside of it (lets say method_1, method_2, and method_3). I want to create a windows scheduled task that runs just method_2. I was imagining some sort of launch parameter like you can put in the "target" line of shortcuts like "chrome.exe /d" or whatever.
Thoughts? I am probably over thinking things honestly, but some simple suggestions would be nice.
It's a little unusual to have a windows scheduled task executing a winforms app... scheduled tasks are more commonly used to execute background tasks/services. It's a little hard to give you further advice without knowing more about what you're trying to do.
Usually, you'd move the common logic to its own assembly and compile it as a Class Library.
Then you'd have your WinForms project reference the shared class library, a third project for your scheduled task that also uses the class library.
But if want to send parameters to your WinForms app, you could change your Program.Main signature from this:
static void Main()
to this:
static void Main(string[] args)
The args array will contain the arguments passed to your application. You can interpret these and call the appropriate method.
In addition to dcastro I like to add that you could also create a library and create several dedicated executables to call specific functions inside this library
Then also use this library from your winforms app.
Projects in your solution:
library.dll with all the shared methods
Task1.exe: Exe to be called from the scheduled Task. (References library.dll)
WinFormApp.exe: Your gui (References library.dll)
Related
How to make process-1 able to fire an event in process-2, and send along few argument, to signal the 2nd process to do a specific action, and optionally receive a reply?
It is possible to do this using the filesystem, there could be a file, where process-1 dumps some commands/querys, and process-2 would be constantly reading from that file, but, this solution is not nice.
Any other way to do it?
(I know that its easy in VB.net to fire an event in a running process whenever a new process is started, IF the "single instance" is enabled in the project properties)
You can use named EventWaitHandle to achieve cross-process synchronization.
This article seems to do what you are used to with vb.net single instance (and it seems still a viable option).
In short it seems that there are three approaches to accomplishing single instance like solutions:
Use a Mutex
Cycle through the process list to see if a process with the same name is already running
Use the Visual Basic system for single instance apps (which you can access from C#)
If by "process" you mean "app-domain", it's fairly easy to set up eventing between the two. In fact if you have two classes in two separate app-domains (where each class has MarshalByRefObject as a base class), then .net will automatically set up a remoting structure that will make events appear to behave as they would in a single app-domain. (Example here: http://msdn.microsoft.com/en-us/library/system.marshalbyrefobject.aspx)
The key here though is 'appear'. 'App-domain' and 'process' separation are intended to keep resources isolated on purpose. To access anything outside of your process you really need help from the operating system, like a shared file or internet connection or named pipes - something to that effect. But .net concepts like events don't exist outside of your space in the runtime.
In other words, you'd have to use something like Named-Pipes (http://msdn.microsoft.com/en-us/library/system.io.pipes.namedpipeserverstream.aspx) if both processes are on the same machine, TCPClient/TCPListener (http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.aspx) if communicating across multiple systems, or WCF if you need something more heavy duty.
If you'd like to see a specific example of one of these technologies in practice, I can write one up for you, btw.
Did quite a bit of reading on how to get data from my main app to the background agent. Microsoft suggestion seems to be to use isolated storage with mutex.
It is suggested in a few places that you can create a static class in a third project (referenced by main and agent) and pass the data that way (but no samples). I could not get that to work. The background agent did not seem to have access to the static class created by the main app.
Has anyone got that to work? Or is isolated storage the best way?
What you have read in a few places is completely impossible by design.
Background agents live in a separate process. If you'll define static variable in a shared library, you'll have 2 completely independent copies of that variable, one in the GUI process, another one in the background agent process.
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).
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.
I have a console application that will be kicked off with a scheduler. If for some reason, part of that file is not able to be built I need a GUI front end so we can run it the next day with specific input.
Is there as way pass parameters to the application entry point to start the console application or the GUI application based on the arguments passed.
It sounds like what you want is to either run as a console app or a windows app based on a commandline switch.
If you look at the last message in this thread, Jeffrey Knight posted code to do what you are asking.
However, note that many "hybrid" apps actually ship two different executables (look at visual studio- devenv.exe is the gui, devenv.com is the console). Using a "hybrid" approach can sometimes lead to hard to track down issues.
Go to your main method (Program.cs). You'll put your logic there, and determine what to do , and conditionally execute Application.Run()
I think Philip is right. Although I've been using the "hybrid" approach in a widely deployed commercial application without problems. I did have some issues with the "hybrid" code I started out with, so I ended up fixing them and re-releasing the solution.
So feel free to take advantage of it. It's actually quite simple to use. The hybrid system is on google code and updates an old codeguru solution of this technique and provides the source code and working example binaries.
Write the GUI output to a file that the console app checks when loading. This way your console app can do the repair operations and the normal operations in one scheduled operation.
One solution to this would be to have the console app write the config file for a GUI app (WinForms is simplest).
I like the Hybrid approach, the command line switch appears to be fluff.
It could be simpler to have two applications using the same engine for common functionality. The way to think of it is the console app is for computers to use while the GUI App is for humans to use. Since the CLI App will execute first then it can communicate it's data through the config file to the GUI App.
One side benefit would be the interface to the processing engine would be more concise thus easier to maintain in the future.
This would be the simplest, because the Config file mechanism is easily available and you do not have to write a bunch of formatting and parsing routines.
If you don't want to use the Config mechanism, you could directly write JSON or XML Serialization to a file to easily transfer data also