I'm trying to open an external executable. I can easily open external executables by using the Process class from System.Diagnostics:
Process p = new Process()
p.StartInfo.FileName = processName;
p.Start();
This works fine with most programs, like browsers and notepad, creating a process and showing its graphical interface. However, when I try to open my desired program, the process is started (can see it in the task manager, it even takes a whole CPU core for processing) but the GUI window doesn't show. What could possibly happen to a process from Process.Start to not show its GUI?
For reference, the program I want to execute is ADOM release 60, which runs 100% fine when I open it directly in the Explorer shell or in the Powershell. This is reproducible in both console and WindowsForms applications.
Here are some other settings that did not help:
p.StartInfo.CreateNoWindow = true; // or false
p.StartInfo.ErrorDialog = false;
p.StartInfo.WindowStyle = /* any of possible values */;
p.StartInfo.UseShellExecute = true; // or false
You need to set the WorkingDirectory to the root folder where the executable is located.
var executablePath = .....;
var p = new Process();
p.StartInfo = new ProcessStartInfo(executablePath);
p.StartInfo.WorkingDirectory = Path.GetDirectoryName(executablePath);
p.Start();
The default value of WorkingDirectory is %SYSTEMROOT%\System32. Many legacy applications have hard coded relative paths that resolve to full paths with said directory and will fail miserably when trying to read (or create) files where they are not supposed to.
Related
I need to run a batch file which launches several other processes. I want to run the batch file silently so that no console windows are created. I can run the batch file using:
Process p = new Process();
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = true;
p.StartInfo.RedirectStandardOutput = false;
p.StartInfo.FileName = "start_system.cmd";
p.Start();
p.WaitForExit();
This does not show the console window for start_system.cmd but the child processes launched by start_system.cmd create console windows. I end up with many console windows on my screen. How can i prevent all those child console windows from showing up?
Its a very long batch script which does a lot of work (not just launching other processes) and i cannot run all the statements from the batch file one by one.
start_system.cmd looks like:
#echo off
...
lots of environment variables settings
...
call %SDK_DIR%\env\env.cmd
...
other settings
...
call %SDK_DIR%\bin\fs.cmd
...
call %SDK_DIR%\etc\proc.cmd
...
lots of other calls
...
I'm working on a WPF application targeting .NET 3.0. I need to call an exe which requires administrative privileges. I can get the UAC to prompt for permission by using something like:
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.Verb = "runas";
startInfo.UseShellExecute = true;
startInfo.FileName = "target.exe";
Process p = new Process();
p.StartInfo = startInfo;
p.Start();
My problem is I need to redirect standard output, and doing so with UseShellExecute = true results in an exception stating that:
The Process object must have the UseShellExecute property set to false
in order to redirect IO streams
However, setting it to false results in the UAC not prompting for permission and I get an exception stating:
The requested operation requires elevation
How can I redirect standard output and prompt for UAC?
I have seen this similar question, however the solution is to use the app.manifest to give my application administrative privileges. This is something I cannot do due to requirements.
UseShellExecute must be set to false to redirect IO, and to true to use the Verb property. So you can't.
But this article seems do the magic, although I haven't tested it.
It's written in C++, but a wrapper API can easily be created to be called from C# by using DllImport.
Note: If you want to pass data between the two programs and have access to the target program's source code, you can easily re-design you application to use Named Pipes instead of redirecting standard I/O.
There is another pretty simple solution:
If you want to run a child-executable elevated AND redirect the output (optionally including window hiding), then your main code must be running elevated too. This is a security requirement.
To accomplish this:
Manually edit your app.manifest in your project folder.
Find the comment regarding UAC Manifest Options, you will see the 3 examples of requestedExecutionLevel.
Under the comment, locate the tricky asInvoker which is currently enabled, and replace it with requireAdministrator.
Restart Visual Studio in order to take into effect, and after re-building your app it should have the typical UAC shield icon.
Now your code will run elevated, everything that it launches will be elevated too, and you can also capture output streams. Here is an example in VB.NET:
Dim startInfo As New ProcessStartInfo
startInfo.Verb = "runas"
startInfo.FileName = "subprocess-elevated.exe"
startInfo.Arguments = "arg1 arg2 arg3"
startInfo.WorkingDirectory = Environment.CurrentDirectory
startInfo.WindowStyle = ProcessWindowStyle.Hidden
startInfo.CreateNoWindow = True
Dim p As Process = New Process()
p.StartInfo = startInfo
p.StartInfo.UseShellExecute = False
p.StartInfo.RedirectStandardOutput = True
p.StartInfo.RedirectStandardError = True
p.Start()
Console.WriteLine(p.StandardOutput.ReadToEnd)
Console.WriteLine(p.StandardError.ReadToEnd)
p.WaitForExit()
I am running a WebApi on Azure, in one of the request I need to run an external EXE, and return by its running result.
It works perfect on my local machine.
the exe reads a file, process it, and write the result to a new file to the local storage.
I have writing privileges (done writing of file and directory before)
I doubled checked the paths and the existence of the resources
all the paths look ok - example: D:\home\\site\wwwroot\myexe.exe
here is the call:
ProcessStartInfo si = new ProcessStartInfo();
si.WindowStyle = ProcessWindowStyle.Hidden;
si.UseShellExecute = false;
si.CreateNoWindow = true;
si.FileName = _pathToExe;
si.Arguments = _prathToArguments;
Process p = new Process();
p.StartInfo = si;
p.Start();
p.WaitForExit();
when debugging it I noticed that the process "completes" right away, and doesn't preform his work.
What am I missing? Am I allowed to run in this way an exe Azure? or should I use Work Role?
Thanks!!
I'm working on a WPF application targeting .NET 3.0. I need to call an exe which requires administrative privileges. I can get the UAC to prompt for permission by using something like:
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.Verb = "runas";
startInfo.UseShellExecute = true;
startInfo.FileName = "target.exe";
Process p = new Process();
p.StartInfo = startInfo;
p.Start();
My problem is I need to redirect standard output, and doing so with UseShellExecute = true results in an exception stating that:
The Process object must have the UseShellExecute property set to false
in order to redirect IO streams
However, setting it to false results in the UAC not prompting for permission and I get an exception stating:
The requested operation requires elevation
How can I redirect standard output and prompt for UAC?
I have seen this similar question, however the solution is to use the app.manifest to give my application administrative privileges. This is something I cannot do due to requirements.
UseShellExecute must be set to false to redirect IO, and to true to use the Verb property. So you can't.
But this article seems do the magic, although I haven't tested it.
It's written in C++, but a wrapper API can easily be created to be called from C# by using DllImport.
Note: If you want to pass data between the two programs and have access to the target program's source code, you can easily re-design you application to use Named Pipes instead of redirecting standard I/O.
There is another pretty simple solution:
If you want to run a child-executable elevated AND redirect the output (optionally including window hiding), then your main code must be running elevated too. This is a security requirement.
To accomplish this:
Manually edit your app.manifest in your project folder.
Find the comment regarding UAC Manifest Options, you will see the 3 examples of requestedExecutionLevel.
Under the comment, locate the tricky asInvoker which is currently enabled, and replace it with requireAdministrator.
Restart Visual Studio in order to take into effect, and after re-building your app it should have the typical UAC shield icon.
Now your code will run elevated, everything that it launches will be elevated too, and you can also capture output streams. Here is an example in VB.NET:
Dim startInfo As New ProcessStartInfo
startInfo.Verb = "runas"
startInfo.FileName = "subprocess-elevated.exe"
startInfo.Arguments = "arg1 arg2 arg3"
startInfo.WorkingDirectory = Environment.CurrentDirectory
startInfo.WindowStyle = ProcessWindowStyle.Hidden
startInfo.CreateNoWindow = True
Dim p As Process = New Process()
p.StartInfo = startInfo
p.StartInfo.UseShellExecute = False
p.StartInfo.RedirectStandardOutput = True
p.StartInfo.RedirectStandardError = True
p.Start()
Console.WriteLine(p.StandardOutput.ReadToEnd)
Console.WriteLine(p.StandardError.ReadToEnd)
p.WaitForExit()
So I have a chunk of code to call powercfg with the /requests option and get the result back from stdout.
Process p = new Process();
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.FileName = "powercfg";
p.StartInfo.Arguments = "/requests";
p.Start();
string output = p.StandardOutput.ReadToEnd();
p.WaitForExit();
However when I run this code I get entirely different output than when I run the same command on the command line.
In the case of the code version I only get a load of "[DRIVER] ?" values back, but on the command line I get usually 2 or 3 properly formed responses.
I've run my code from the same command prompt window as the same user with the same environment, still no joy.
Any ideas ?
So the actual reason was that my application needed to be compiled for "Any CPU". Setting it to x86 or x64 caused issues with it loading the correct version of one of the dependent libraries.
It may have something to do with the user context your application is running in, for example if you run your app as an administrator Process.Start will attempt to start the process in the same context.