I have a .Net windows C# application, fairly complete and working, that I have been asked to support calling it from another program like LabView. I have added the ability to parse command line arguments at startup so I can detect that it is supposed to behave like a console application and be provided with enough information to function.
What I would like to do is have the program print out to the console its results and have the calling program pipe it or just pull the data and use it.
The printing to the console works fine but when I start the program up, it tells the command prompt window that it is done (a new prompt immediately shows up and the command prompt is waiting for input). In the process it also closes the redirection that was part of the startup line. Is there anyway to keep it from telling the calling program that it has completed before it has actually finished?
The simple solution is to pass a file to save the data to but I would prefer not to have to do that. I could also do a separate version that is a console app, but that means supporting two separate programs.
Thanks
Instead of invoking the program directly, you can use cmd /c myapp.exe.
Related
I am running a C# windows console application and passing in a couple of arguments via Task Scheduler. It runs all day loading flat file data created by other applications into SQL server. The program fails intermittently and I have Try/Catch logic that writes information regarding the exception using Console.WriteLine().
So basically I need to track down the location of the console output so I can take steps to eliminate the intermittent failures. I've had a good look around online thinking this must be a fairly common requirement to diagnose errors from Task Scheduler scheduled apps. My online search has revealed a couple of work around solutions but no direct answer as to where the console output goes when running a c# console application directly via Task Scheduler.
The two workarounds I have seen are:
(1) Get Task Scheduler to run a windows batch script (.bat file) instead of running the console app (.exe file) directly. Within the batch script use ">" or ">>" to redirect the console output to a flat file (e.g C:\app\myapp.exe arg1 arg2 > "C:\log\myapp_console_output.txt")
(2) A very similar solution is to get Task Scheduler to run the windows command line cmd.exe with /C option and passing arguments into cmd.exe to run my console app and also redirect the console output. e.g. something like:
cmd.exe /C "C:\app\myapp.exe" arg1 arg2 > "C:\log\myapp_console_output.txt"
While I acknowledge that the above workarounds may well help me to capture future failures it doesnt really help me to track down output from the intermittent failures that have already occurred. They also seem quite messy workarounds to achieve what I would have thought was a pretty common standard requirement.
Can anyone please confirm that the console output is definitely not retained somewhere when running a c# console app directly via Task Scheduler?
I just wrote a clever program called helloworld. It's a C#/.NET 4.5 console app. Deep within the twisted nested mazes of logic there's use of Console.WriteLine().
When I'm running this at a command line, it runs and I see the output. I can do other commands and mess around a bit, and later scroll up to see the output again.
Now I'm in Visual Studio, tweaking the source ("Hi" is more efficient than "Hello") and testing by tapping F5. What happens is a console window pops up and immediately vanishes. I have no idea what the program printed. How can I see the output?
I don't want to modify my source at all. After searching for solutions, I find some who say to use Console.ReadKey() - but then it would suck to be using the program at the command line. There's no real reason the user should have to tap a key when the program has already done its work. Even if i go with this, there's the problem of the output disappearing when the console window closes after a key tap.
I don't want to use Debug.WriteLine() which does write to the output window in VS, but doesn't write ordinary output for the end user to see.
I have discovered ctrl-F5, which runs the program as if it had a final Console.ReadKey() line, but there's still the problem of when I tap any key, all the output vanishes along with the window. Three minutes later, I'm thinking "Oh wait, did it print 'Hello' or 'Helo'?" No way to check.
Seems like the Visual Studio IDE should somehow capture all that a freshly built program writes to its stdout or the Microsoft equivalent thereof, and show it in its "Output" panel, or some panel, for later scrutiny. Maybe it does do this, and I don't yet know the trick to it? Seems like this would be a common desire among millions of C# developers.
If you're working on a .NET Core console application (or .NET Framework via the .NET SDK) using Visual Studio 2019, the behaviour of leaving the console window open after the program has executed will now happen by default:
Specifically:
This should prevent the need to add Console.Read() calls to console apps to prevent the console window from closing immediately after the program has finished executing. The launched console window is also re-used for subsequent runs, so if you’re used to using ctrl+f5, you won’t have lots of console windows to close after you’ve launched your application a few times.
The reason it closes automaticly is because it's done running the program. If you want to see what it did, make it need a new command like hitting any key. The Console.ReadKey(); pauses it and waits for a User to hit a key to continue. Put that command after the commands of instruction you are doing and it will pause it until you hit any key.
Console.ReadKey(); // Pauses until you hit any key
You can also run your program pressing F10 (executes one line by one), with F11 (goes inside a function).
The other option you have is to set breakpoints in Visual Studion and run the program by pressing F5 - it will stop at the next breakpoint. And the breakpoints can have conditions - i.e. conditional breakpoints.
Some options are:
1. wrap #if DEBUG around Console.ReadKey()
2. run directly from an open terminal
3. create a Test project - but again you'll need Console.ReadKey() to stop it closing.
I've been thinking of giving the in Windows implemented cmd a fresh look and make a WinForm out of it(C# .net4.0 or later or latest mono# distribution).
Now, what I plan on doing is:
only showing the form, no console visible(even in the task bar)
telling the cmd what to do by virtually typing into it
catching the consoles output and using the form to make the user interact
I thought of some kind of "return" thing, like a dll would do, but I have not used consoles and forms together in a single project, so there's my question:
How do I not show a console window but write commands into it's line and receive the output with a WinForms application?
Thanks in advance.
--EDIT
I should maybe add that my main problem is typing catching the consoles output and also typing into it while it's not visible and thus not focusable.
You may well run into difficulties other than simply suppressing the appearance of a console window. But as far as that particular requirement goes, it's not hard.
You'll use the System.Diagnostics.Process class to start the process. Before starting the process, you'll need to see ProcessStartInfo.CreateNoWindow property to true. Note that you also need to set ProcessStartInfo.UseShellExecute to false, otherwise the CreateNoWindow property is ignored.
As for the broader problem: it seems likely that you'll need to start the console process using "cmd.exe /k" to instantiate a new command-line interpreter process without it exiting before you're done with it. Then you'll also need to use the redirection features in the Process class to read from stdout and stderr, and to write to stdin.
I've got a console application and I want to run it from another application. But when I invoke it from code--to call program I use ActiveXObject--it shows the console. How do I get it to not show the console? I mean, the program works but console is shown.
If you make the application a Windows Application instead of a Console Application it will not show or open (or use) a Console. Your code can stay the same - and the application will still function (without ever creating a Form or Window).
That being said, if you control the "other" application, you may want to consider making a class library instead of a separate Application. This would allow you to just include and run code within the library without starting a separate process.
You can create it as a Windows Forms application with a hidden window. That's just one possibility like Reed Copsey pointed out, i used it once because i needed to process some specific Window Messages.
My target is to call an external program from my C# application and keep it alive even when my application is closing.
Both applications don't share anything and I could accomplish the same task by running a command from the command line by passing in a few arguments.
I've been trying to use the process class and I've been fiddling around with DTE, both let me create an instance of the external program (Visual Studio to be precise) but they will close as soon as the calling application is closing.
Is there any other way? Maybe a call to Windows, that will launch that program instead of my application?
Use Process.Start.