.Net Process.Start Default Directory

.NET Process.Start default directory?

Yes!
ProcessStartInfo Has a property called WorkingDirectory, just use:

...
using System.Diagnostics;
...

var startInfo = new ProcessStartInfo();

startInfo.WorkingDirectory = // working directory
// set additional properties

Process proc = Process.Start(startInfo);

Process.Start working directory in the same string as filepath

The documentation for public static Process Start(string fileName) is found here: https://msdn.microsoft.com/en-us/library/53ezey2s(v=vs.110).aspx

As you can see the description for that parameter is:

The name of a document or application file to run in the process.

The remarks also note:

This overload does not allow command-line arguments for the process. If you need to specify one or more command-line arguments for the process, use the Process.Start(ProcessStartInfo) or Process.Start(String, String) overloads.

So in summary no, you can't do this. Even if your program accepted a working directory as a command line argument this overload will not work.

Unable to set Process.StartInfo.WorkingDirectory to call exe from c#

The only way for this to work is for you to change your working directory to the passed in working directory before attempting to start the other process. The WorkingDirectory property is just that, and doesn't in any way get involved in locating the executable to run. That just relies on your working directory and your PATH environment variable, if you fail to provide a fully-qualified name.

static bool RunProc(string exe, string args, string workingDir)
{
var prevWorking = Environment.CurrentDirectory;
try
{
Environment.CurrentDirectory = workingDir;
Process proc = new Process
{
StartInfo =
{
FileName = exe,
CreateNoWindow = true,
RedirectStandardInput = true,
WindowStyle = ProcessWindowStyle.Hidden,
UseShellExecute = false,
RedirectStandardError = true,
RedirectStandardOutput = true,
Arguments = args,
}
};

proc.Start();
proc.StandardInput.WriteLine(args);
proc.StandardInput.Flush();
proc.StandardInput.Close();

return true;
}
finally
{
Environment.CurrentDirectory = prevWorking;
}
}

Process.Start in Core 3.0 does not open a folder just by its name

I suspect the ProcessStartInfo.UseShellExecute property is what would allow this to work on .NET Framework. From the documentation...

The default is true on .NET Framework apps and false on .NET Core apps.

...and the Process.Start() overloads that just take string parameters will likely just leave that property at the default. To work around this, create your own ProcessStartInfo with the UseShellExecute property set to true and pass that to an overload of Process.Start() instead...

ProcessStartInfo startInfo = new ProcessStartInfo(path_to_folder) {
UseShellExecute = true
};

Process.Start(startInfo);

For completeness, when I try running this...

Process.Start(Environment.SystemDirectory);

...in .NET Core 3.0 I get this exception...

Unhandled exception. System.ComponentModel.Win32Exception (5): Access is denied.

  • at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
  • at System.Diagnostics.Process.Start()
  • at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
  • at System.Diagnostics.Process.Start(String fileName)

The missing link between Process.Start() and Process.StartWithCreateProcess(ProcessStartInfo startInfo) is Process.StartCore(ProcessStartInfo startInfo), which branches based on the value of UseShellExecute and I imagine gets inlined. The exception appears to be thrown after a call to
CreateProcess(), presumably because a directory path is specified as the file to executable.

Note that if you pass a path to a non-executable file to that same Process.Start(String fileName) overload the exception message becomes "The specified executable is not a valid application for this OS platform."

The reason why calling Process.Start(String fileName, String arguments) works despite following largely the same code path is because the ProcessStartInfo instance it creates under the covers has a FileName property that does refer to a file (explorer.exe) that can be directly executed even if UseShellExecute is false.

Process.Start fails and claims The directory name is invalid.

It turned out that the following change helps: Instead of starting the process with providing the full path to the EXE file, we now first change the current directory to that of the EXE, then start the EXE in the current directory, and finally we change back to the directory we were in before.

It is weird, but it helps.

Open a folder using Process.Start

Have you made sure that the folder "c:\teste" exists? If it doesn't, explorer will open showing some default folder (in my case "C:\Users\[user name]\Documents").

Update

I have tried the following variations:

// opens the folder in explorer
Process.Start(@"c:\temp");
// opens the folder in explorer
Process.Start("explorer.exe", @"c:\temp");
// throws exception
Process.Start(@"c:\does_not_exist");
// opens explorer, showing some other folder)
Process.Start("explorer.exe", @"c:\does_not_exist");

If none of these (well, except the one that throws an exception) work on your computer, I don't think that the problem lies in the code, but in the environment. If that is the case, I would try one (or both) of the following:

  • Open the Run dialog, enter "explorer.exe" and hit enter
  • Open a command prompt, type "explorer.exe" and hit enter

C# Process.Start Path

In the event that you just want to get the path of the running application to launch a secondary application (in the same directory) you should be able to use:

System.Reflection.Assembly.GetExecutingAssembly().Location

Reference:

http://msdn.microsoft.com/en-us/library/aa457089.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assembly.location(v=vs.110).aspx

How is Process.Start different from Start Run?

Re-posting comment as answer (and rephrasing):

Unlike explorer shell's Start->Run, which automatically sets current working directory to the same folder where target executable is located, .NET's Process.Start does not do that. This is often the case where executable tries to load resources relative to current working folder and expecting it to be same one where executable is located (such as loading config files, DLLs and libraries, etc.) that is leading to crashes or other failures.

Use StartInfo.WorkingDirectory to specify working folder to where the executable is located, and 9 out of 10 times, that'll be it!

Yeap, I've stepped on this rake more than once...



Related Topics



Leave a reply



Submit