C＃中的.CMD执行莫名其妙地失败

Question

I'm attempting to execute a .cmd process from a C# program. When I run the process in command line, ie

C:\Directory\Process.cmd  -x 1000 -y 1000 C:\Input\input.txt

I get an appropriate result (in this case, that means that the process writes a file to:

C:\Output\output.txt

However, When I try to run this process from a simple C# program, the output file is not created. Here are a couple of my attempts:

Attempt 1)

try
{
    string processName = @"C:\Directory\Process.cmd";
    string argString = @" -x 1000 -y 1000 C:\Input\input.txt"; //The extra space in front of the '-x' is here on purpose
    Process prs = new Process();
    prs.StartInfo.UseShellExecute = false;
    prs.StartInfo.RedirectStandardOutput = false;
    prs.StartInfo.FileName = processName;
    prs.StartInfo.Arguments = argString;
    prs.StartInfo.WindowStyle = ProcessWindowStyle.Normal;

    prs.Start()
}
catch (Exception e)
{
    Console.Writeline(e.Message);
}

Attempt 2)

try
{
    System.Diagnostics.Process.Start(@"C:\\Directory\\Process.cmd", " -x 1000 -y 1000 C:\\Input\\input.txt";
}
catch (Exception e)
{
    Console.Writeline(e.message);
}

Now, in both cases, no exceptions are thrown, and Process.cmd is accessed (it prints status updates in a shell), but the process does not create any output files. Is there something wrong with the way I am attempting to call Process.cmd, that it works properly when run directly form the command line but does not work properly when I attempt to call it from my C# program?

Answer 1

Thy this one?

System.Diagnostics.Process.Start("cmd.exe", @"/c C:\Directory\Process.cmd -x 1000 -y 1000 C:\Input\input.txt");

AFAIK, '@' prepends verbatim strings, wich do not requires backslash masking )

Answer 2

The file may be getting created, but not where you think. Use

prs.StartInfo.WorkingDirectory = "yourpath"

http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.workingdirectory.aspx

The WorkingDirectory property must be set if UserName and Password are provided. If the property is not set, the default working directory is %SYSTEMROOT%\\system32.

If the directory is already part of the system path variable, you do not have to repeat the directory's location in this property.

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 only has meaning within the context of the new process.

I deleted this after realizing that a path is passed in as an argument and was probably using hardcoded path logic for the file it writes to, but since a comment has referenced this, I'll undelete in case it is still of assistance.

Answer 3

So I was finally able to get my hands on the source code, and realized that the problem was in the java code... it was interpreting the project directory as the output directory. Thank you for all of the help though, you guys gave some very useful information!