CODEWITHSUNDEEP
c#process
asfallows
asfallows

Reputation: 6108

More than one important path for .NET Process

In a project I'm currently working on, I am starting an external process. However, the external process is the EXE of a complex program which loads current-user information from a user folder. The desktop shortcut for the program resolves the matter by setting the "Target:" parameter to X:\exepath\prgm.exe and setting the "Start In" parameter to the user's path, X:\exepath\users\username.

I currently launch the process like this:

Process p = new Process();
p.StartInfo = new ProcessStartInfo( "X:\exepath\prgm.exe" );
p.StartInfo.WorkingDirectory = "X:\exepath\users\username";
p.Start();
while (!p.HasExited) { }

However, when the process is started, the program it launches ends up looking for all resources in the WorkingDirectory instead of pulling user content from that folder and all other content from the directory the EXE resides in. This suggests that Working Directory and the system shortcut "Start In:" parameter behave differently.

Is there any way to mimic that behavior with a C# Process? Alternatively, is it possible to create a shortcut in C#, which I could then start with my Process invocation?

Please let me know if more info would be helpful.

EDIT -

After some more trial and error, I decided to use WSH to create a shortcut and run it. WSH uses the name WorkingDirectory for the value of the "Start In:" parameter. It behaves identically under the hood as the execution of the process in my code above. I am still getting the error.

Upvotes: 6

Views: 257

Answers (2)

asfallows
asfallows

Reputation: 6108

I have resolved my problem, which was not related to the creation of a Process after all. In fact, the root cause is a little embarrassing, but potentially educational, so I'll provide an explanation.

The code I posted in the OP was sample code to illustrate the problem. In my actual project, I was retrieving the ExePath and the UserPath from registry keys. The project is a Chooser tool to switch between multiple installed versions of the third-party software, and reads/edits these registry keys to do its work.

When I wrote the code that writes to the registry, I used DirectoryInfo.FullPath, which returned "X:\ExePath" instead of "X:\ExePath\". This made the program unable to find the files it needed from the ExePath folder, looking for X:\ExePathsettings.inf" instead of "X:\ExePath\settings.inf". I inserted trailing backslashes to my code and to the existing registry entires, and everything worked just fine.

Lesson learned: Always check your path values very, very carefully.

Upvotes: 1

mletterle
mletterle

Reputation: 3968

The difference is likely due to using a Shell Process to execute: http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.useshellexecute.aspx

The WorkingDirectory property behaves differently when UseShellExecute is true than when UseShellExecute is false. When UseShellExecute is true, the WorkingDirectory property specifies the location of the executable. If WorkingDirectory is an empty string, the current directory is understood to contain the executable.

When UseShellExecute is false, the WorkingDirectory property is not used to find the executable. Instead, it is used by the process that is started and has meaning only within the context of the new process.

I suspect if you set p.StartInfo.UseShellExecute to false it may behave as you want.

Upvotes: 1

Related Questions