Problem redirecting console in C# - c#

i am building a GUI over an console application that i use, i'm trying to use C# Process and RedirectStandardInput/Error/Output.
The problem is when i redirect anything the console applications stops printing data, i've redirected only stdin and watched the console application window itself, nothing, i've redirected stdin, out and err and no data is received by my program.
This is the only application i tested that doesn't work with Std redirection, is it an implementation issue?
Code:
fmproc = new Process();
fmproc.StartInfo.FileName = #"fm.exe";
fmproc.StartInfo.Arguments = "";
fmproc.StartInfo.UseShellExecute = false;
fmproc.StartInfo.CreateNoWindow = false;
fmproc.StartInfo.RedirectStandardInput = true;
fmproc.StartInfo.RedirectStandardError = true;
fmproc.StartInfo.RedirectStandardOutput = true;
fmproc.Start();
fmproc.StandardOutput.ReadLine();

Perhaps you could try:
fmproc.StandardOutput.ReadToEnd();
fmproc.WaitForExit();
Rather than the ReadLine(); Of course you might want to do something more interesting with the output string - but I'm just following your example code.

Related

How to start a process using Xamarin C# on an android app?

Having this code:
Process checkForUpdates = new Process();
checkForUpdates.StartInfo.FileName = #"python";
checkForUpdates.StartInfo.Arguments = "-V";
checkForUpdates.StartInfo.UseShellExecute = true;
checkForUpdates.StartInfo.RedirectStandardOutput = true;
checkForUpdates.StartInfo.RedirectStandardError = true;
checkForUpdates.StartInfo.CreateNoWindow = false;
checkForUpdates.EnableRaisingEvents = true;
checkForUpdates.Start();
string result = checkForUpdates.StandardOutput.ReadToEnd();
I'm trying retrieve the output of the command python -V in order to determine if python is installed on the device.
The code above compiles but the code seems to hang during the process without any errors. The same code works fine on UWP.
Is there any other way to make it work on Android?
The problem was that I run this code inside a background worker. I put the code in a method directly inside ViewModel and it worked perfectly fine.

Console Input Inside WPF Application

I'm trying to get console input from inside a WPF application. In the Project properties I've set it as a console application and the output works. However, now I want to be able to read input from the console since I haven't started working on the views yet. I found this snippet on here, but I don't believe it's what I was looking for:
Process compiler = new Process();
compiler.StartInfo.FileName = "C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\csc.exe";
compiler.StartInfo.Arguments = "/r:System.dll /out:sample.exe stdstr.cs";
compiler.StartInfo.UseShellExecute = false;
compiler.StartInfo.RedirectStandardOutput = true;
compiler.Start();
Console.WriteLine(compiler.StandardOutput.ReadToEnd());
compiler.WaitForExit();
Why not simply use Console.ReadLine()?
string userInput = Console.ReadLine();

Send prompt input to Diagnostics.Process

I'm currently solving a problem of starting external tool from .net app.
I have this part of code:
proc.StartInfo = new ProcessStartInfo(_app, _args);
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.RedirectStandardInput = true;
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.RedirectStandardError = true;
proc.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
But, after starting application I get an error to StandartError output witn promt confirmation answer "enter y/n".
I've already tried to input "y" via standart input, right after starting process, but still get the same error.
var standartInput = proc.StandardInput;
standartInput.AutoFlush = true;
standartInput.WriteLine("y");
standartInput.Close();
I'd really appreciate any help. Thanks.
PS: PuTTY Secure Copy client - is the external app I'm using from code. There is a confirmation promt, when running app for first time to save servers fingerprint in system registry.
The code looks OK to me. Maybe you need to sleep for a second or something before writing the "y". I would imagine that the program takes a little while to ask the user for input

How to run program through command line from .aspx page

I'm trying to run a program, say "robocopy.exe", through an aspx page using the System.Diagnostics.Process object.
My code looks like this:
Process si = new Process();
si.StartInfo.UserName = "testuser";
si.StartInfo.Password = password;
si.StartInfo.FileName = "cmd.exe";
si.StartInfo.UseShellExecute = false;
si.StartInfo.Arguments = "c/ robocopy.exe";
si.Start();
string output = si.StandardOutput.ReadToEnd();
si.Close();
Label1.Text = output;
The problem is that the cmd.exe process is started correctly, but nothing happens. The argument of roboxopy.exe is presumably not passed to the cmd process to run! Any ideas as to what Icould be doing wrong?
Sounds like a permission issue. Usually the default asp_net account that any IIS processes run under will not have execute permissions on the server. The reason that this is the case is because it is a huge security hole. I would highly recommend that you think about what you are trying to accomplish and see if there is another way to do it that does not involve running a separate executable.

strange behaviour on another process via Process.Start(startInfo)

Our C# (V3.5) application needs to call another C++ executable which is from another company. we need to pass a raw data file name to it, it will process that raw data (about 7MB) file and generate 16 result files (about 124K for each).
The code to call that executable is this:
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.CreateNoWindow = true;
startInfo.UseShellExecute = false;
startInfo.RedirectStandardError = true;
startInfo.RedirectStandardOutput = true;
startInfo.WindowStyle = ProcessWindowStyle.Hidden;
startInfo.FileName = exePath;
startInfo.Arguments = rawDataFileName;
try
{
Process correctionProcess = Process.Start(startInfo);
correctionProcess.WaitForExit();
}
catch(nvalidOperationException ex)
{
....
}
catch(...)
...
It works fine. Now we have new raw data. After replace the old raw data with the new raw data file. That executable process never return to us. It will hang forever. If we kill our C# application, those result files will be generated in the target directoy. It looks like the executable does create those result files but has issue to write to the disk and return to us until the process is terminated.
It is NOT like this with the old raw data file.
When we run the executable with the new raw data directly (no from our C# app call), it works fine. This means this executable has no problem with the new raw data.
My question 1: what's the possible causes for this behaviour?
Now I change our code with startInfo.UseShellExecute = true; and add startInfo.WorkingDirectory= ..., and disabled
//startInfo.RedirectStandardError = true;
//startInfo.RedirectStandardOutput = true;
Then it works.
My question 2: why use Windows Shell solve this issue?
My question 3: why it works before without using Shell?
My question 4: when we should use Shell and When shouldn't?
thanks,
Several possibilities:
You are redirecting output and error but not reading it. The process will stall when its stdout or stderr buffer fills up to capacity.
The program might be displaying an error message and waiting for a keypress. You are not redirecting input nor check stderr, that keypress will never come.
Some programs, xcopy.exe is a very good example, require stdin to be redirected when you redirect stdout. Although the failure mode for xcopy.exe is an immediate exit without any diagnostic.
Seeing it fixed when you kill your C# program makes the first bullet the likeliest reason.
I know this, it is a very common problem. I has to do with the output, which must be handled asynchronously. You just can't WaitForExit when output exceeds certain amount of data.
You need to add
myStdErr= correctionProcess.StandardError.ReadToEnd();
Only once usually works, if you want to overkill this works ("P" being my Process)
while (!P.HasExited)
stdErr+= P.StandardError.ReadToEnd();
If you don't need the stdout/stderr, just turn the Redirect* properties to false.

Categories