In a console app on Mono/OSX I want to call the mdtool to build an iOS project. I succeed to have the right command line arguments and it runs correctly in bash shell script.
Now If I call it with the Process/ProcessStartInfo classes in my console app, after the build I got this and my programm exits.
Press any key to continue... logout
[Process completed]
Here's the code to call mdtool:
var buildArgs = string.Format("...");
var buildiOSproject = new ProcessStartInfo
{
FileName = "/Applications/MonoDevelop.app/Contents/MacOS/mdtool",
UseShellExecute = false,
Arguments = buildArgs
};
var exeProcess = Process.Start(buildiOSproject);
exeProcess.WaitForExit();
//code here never called
I got my answer on the Xamarin forums (http://forums.xamarin.com/discussion/267/calling-mdtool-trough-processstartinfo#latest) but it seems a problem with the debugger so I switch off the "Run on external console" property in the options of my project and it's working now.
Try adding the following to your StartInfo initializer. I faced the same problem with another tool when it exited. Although I had already used RedirectStandardOutput and RedirectStandardError, I got it fixed only after adding RedirectStandardInput also.
buildiOSproject.StartInfo = new ProcessStartInfo
{
...
RedirectStandardOutput = true,
RedirectStandardError = true,
RedirectStandardInput = true,
...
}
Related
When I try to run cmd command 'efwmgr C: -commit' from C#, got empty log file without any information, and when check manually 'ewfmgr C:', got 'Boot Command NO_CMD', so commit not run.
Same code just changed Arguments = "/C chkdsk C:" it runs and works well, inserted whole output into my log.
Method which I used.
public static void StartProcess()
{
var procStartInfo = new ProcessStartInfo
{
CreateNoWindow = false,
WindowStyle = ProcessWindowStyle.Normal,
FileName = "cmd",
Arguments = "/C ewfmgr C: -commit",
UseShellExecute = false,
RedirectStandardOutput = true,
RedirectStandardInput = true,
RedirectStandardError = true
};
var process = new Process { StartInfo = procStartInfo, EnableRaisingEvents = true };
using (StreamWriter writer = new StreamWriter(#"D:\commitFile.txt"))
{
process.OutputDataReceived += (sender, e) =>
{
writer.WriteLine(e.Data);
};
process.Start();
process.BeginOutputReadLine();
process.WaitForExit();
}
}
This is the nearly example I found on https://social.msdn.microsoft.com/Forums/vstudio/en-US/4e014365-8e8f-4f93-998a-156f2e55ebab/how-to-get-and-write-ewf-current-to-text-file-using-c?forum=csharpgeneral
You probably getting an error in process error output stream. Append your log in ErrorDataReceived event handler. And for the 'ewfmgr' is not recognized as an internal or external command you should edit process environment variable or specify full path to your application.
This is how you code should look like:
var procStartInfo = new ProcessStartInfo
{
CreateNoWindow = false,
WindowStyle = ProcessWindowStyle.Normal,
FileName = "cmd",
//Append PATH environment variable bellow if you use this
Arguments = "/C ewfmgr C: -commit",
//Or use full path to application without changing environment variable
//Arguments = "/C c:\full\path\to\application\ewfmgr C: -commit",
UseShellExecute = false,
RedirectStandardOutput = true,
RedirectStandardInput = true,
RedirectStandardError = true
};
procStartInfo.EnvironmentVariables["PATH"] += #";c:\full\path\to\application\";
var process = new Process { StartInfo = procStartInfo, EnableRaisingEvents = true };
using (StreamWriter writer = new StreamWriter(#"D:\commitFile.txt"))
{
process.OutputDataReceived += (sender, e) =>
{
writer.WriteLine(e.Data);
};
process.ErrorDataReceived+= (sender, e) =>
{
writer.WriteLine(e.Data);
};
process.Start();
process.BeginOutputReadLine();
process.BeginErrorReadLine();
process.WaitForExit();
}
Just wanted to point out an update regarding this issue for anyone that might encounter this, or any other file "missing" from Windows/System32 directory:
First things to check is your system architecture, and your process architecture:
There are several posts about this feature (although I prefer to call it issue), I can safely say that this one explains it correclty, and that ewfmgr.exe works just fine if you set your architecture correclty.
In order not to rely on another post/link, I'll rewrite/copy the answer from David there:
There is one explanation that makes sense:
You are executing the program on a 64 bit machine.
Your C# program is built as x86.
The bcdedit.exe file exists in C:\Windows\System32.
Although C:\Windows\System32 is on your system path, in an x86 process you are subject to the File System Redirector. Which means that C:\Windows\System32 actually resolves to C:\Windows\SysWOW64.
There is no 32 bit version of bcdedit.exe in C:\Windows\SysWOW64.
The solution is to change your C# program to target AnyCPU or x64.
As a side note I'd like to also add that by default, VS projects for C# are set as "Any CPU" configuration, however there's checkbox ticked in project properties on the build tab, that says "Prefer 32-bit": This needs to be unchecked/disabled, or "Any cpu" build will result in 32 bit application as well.
Other than that, I've successfully implemented fully working EWF manager into our service application. Unfortunatelly I haven't had any luck using pInvoke and ewfapi dll, since it didn't seem to return correct results. I'm not sure yet whether there was an issue in implementation, or whether the EWF api itself is broken (to be honest, its really buggy and unreliable. For us specifically, the "Disable" command does nothing - after reboot, ewf is still enabled. The only way to disable it is to Disable and Commit, or use CommitAndDisableLive, which both unfortunatelly commit current state onto the drive, so I had to use fallback and reboot the machine before disabling protection, to be sure its in clean state), so I went the route to call it using command line, and parse response parameters to control it. Unfortunatelly it was time critical and I needed production ready solution, so I had to make a workaround, but I'll post a separate question about the pInvoke, and then put on GitHub altogether as a final solution.
I'll come back and edit this post to include the GitHub link once I have the time to upload it. Should someone need it right away, I'm happy to send it over as-is.
Hope it helps.
I am running processes from C# using the following code;
private static void ExecuteShellCMD(string workingDir, string commandWithArgs, bool bWait = true)
{
ProcessStartInfo info = new ProcessStartInfo();
info.Verb = "runas";
info.FileName = "cmd.exe";
info.WorkingDirectory = workingDir;
info.Arguments = "/C " + commandWithArgs;
info.UseShellExecute = false;
using (Process myProcess = Process.Start(info))
{
if (bWait)
{
myProcess.WaitForExit();
}
int ExitCode = myProcess.ExitCode;
//Log exit code here.
}
}
It loads an elevated command window and executes the code/bat file I pass it, but without logging anything to the console. This doesn't appear to be consistent on other machines, and has worked in the past on my machine, and I wondered if anyone had any ideas about how I can consistently make this Process just print logs into the command window the process makes.
I can see logs if I set UseShellExecute = true but then can't use Verb without accepting the elevation prompt which is undesirable.
I have tried looking for solutions around the web, and I am aware that I can redirect the output using other settings. Most of the questions and tutorials on this subject seem to deal with redirecting the ouput to somewhere else but I want to be able to keep track of the progress in the command window itself.
Perhaps I have missed an command line argument or similar?
Turns out this was actually a bug in Unity Hub. The process and output were working fine, however when ran from a Unity instance that was launched from Unity Hub it took control of the output and didn't release it. This was solved by just launching Unity directly and a bug report has been filed against Unity hub.
I need to run an elevated command in my c# application and get the output.
I'm creating a new System.Diagnostics.Process instance, coupled with a new System.Diagnostics.ProcessStartInfo instance.
The command is being sent to cmd.exe, and unfortunately may require elevated user access (meaning UseShellExecute = true and Verb = "runas" must be present).
As a result of using UseShellExecute = true, RedirectStandardOutput will not work.
It's important I record the output of the command, but the only way I can see of getting this is adding something like > output.txt to the argument list, then calling System.IO.File.ReadAllText to read the result.
Can anyone think of less hacky way?
I have been searching and I cannot seem to get this work. I am trying to launch SFC from a button in a C# app. I am aware that it requires rights elevation and in the scope of what I am trying to do is behavior that I want.
I have tried:
To run cmd as administrator along with command?
Running CMD as administrator with an argument from C#
and
C# how to run a process(with arguments) through an administrator elevated cmd
The code I tried last was:
private void button6_Click(object sender, EventArgs e)
{
ProcessStartInfo procStartInfo = new ProcessStartInfo("cmd", "/c " + "processNeedToRun")
{
RedirectStandardError = true,
RedirectStandardOutput = true,
UseShellExecute = false,
CreateNoWindow = true,
Verb = "runas"
};
}
I either get no process launching at all the cmd window flashes saying incorrect credentials or the command was incorrect.
what am I doing wrong?
Per the comment added I changed it to this:
private void button6_Click(object sender, EventArgs e)
{
ProcessStartInfo procStartInfo = new ProcessStartInfo("cmd", "/c " + "sfc.exe /scannow")
{
RedirectStandardError = false,
RedirectStandardOutput = false,
UseShellExecute = true,
CreateNoWindow = false,
Verb = "runas"
};
}
and no change
EDIT:
So I managed to find a solution:
I created a new console app, edited the manifest to require admin and did this
Process.Start("CMD.exe", " /c SFC /Scannow");
That does have the behavior I want. Thanks for the help!
Your console is not elevating, the problem is you can either use the Verb = "runas" and have it elevate or you can use UseShellExecute = false and redirect the outputs, you can not have both.
Your three options are:
Use UseShellExecute = true and disable the redirections
Add a manifest file to your program so it elevates itself as an administrator on start and it can then in turn launch administrative processes and monitor them.
Do a combination of both by writing a 2nd exe that has a manifest file that always runs as administrator. Then have your 1st program launch the 2nd program with Verb = "runas", you then have your 2nd program start SFC with UseShellExecute = false. Your 2nd program then forwards the output via some form of IPC (WCF over named pipes would likely be easiest) to the first unelevated program to be displayed to the user.
Try setting
ProcesStartInfo.UserName and ProcessStartInfo.Password to impersonate the new process with elevated credentials.
I am trying to pass parameters to Powershell script from a C# class. I am running the script using Process.Start.
string powerShellLocation = #"C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe";
ProcessStartInfo psi = new ProcessStartInfo(powerShellLocation);
psi.Arguments = String.Format("{0} {1}", scriptPath, "some_parameter");
The above does not work. Can someone please tell me how to achieve this?
You need to set the parameter name. Something like this should work:
string parameters = string.Format("-FILE {0} -parameter1 \"{1}\"", psFilePath, parameter1Value);
Process powershell = new Process()
{
StartInfo = new ProcessStartInfo("powershell.exe", parameters)
{
UseShellExecute = false,
RedirectStandardOutput = true,
RedirectStandardError = true
}
};
What you have would work. You have not mentioned what you meant by above does not work and what your script is.
I tried the C# code with the Powershell script:
param([string]$a)
write-host "test"
write-host $a
and it gave the output:
test
some_parameter
as expected. There is no need to specify -File and -paramter1 like the other answer mentions, but will depend on what your script does.
Did you set the execution policy to unrestricted or to something that allows you to execute the script. By default Powershell sets scripts to be unrestricted to prevent malicious scripts from running.
Run this command as an administrator when powershell is running:
Get-ExecutionPolicy