从asp.net挂起执行批处理

Question

I'm running a batch from my ASP.NET c# page. I'm trying to use the System.Diagnostics.ProcessStartInfo method described in the link below. When I click my button to run the batch, the page just hangs with "Waiting for ".

The original code I'm using

Here are some similar problems with solutions:

Possible solution 1

Possible solution 2

Unfortunately, I don't understand solution 1 at all and solution 2 does seem to indicate there is a problem with the paths I'm trying to use, but I'm a little unclear on this as well. Any help is greatly appreciated.

My code:

protected void RunPkg_Click(object sender, EventArgs e)
{
    // Get the full file path
    string strFilePath = "C:\\inetpub\\wwwroot\\DecisionSupport\\CMSBenPerfUpload\\RunPackage.bat";

    // Create the ProcessInfo object
    System.Diagnostics.ProcessStartInfo psi = new System.Diagnostics.ProcessStartInfo("cmd.exe");
    psi.UseShellExecute = false; 
    psi.RedirectStandardOutput = true;
    psi.RedirectStandardInput = true;
    psi.RedirectStandardError = true;
    psi.WorkingDirectory = "C:\\inetpub\\wwwroot\\DecisionSupport\\CMSBenPerfUpload\\";

    // Start the process
    System.Diagnostics.Process proc = System.Diagnostics.Process.Start(psi);

    // Open the batch file for reading
    System.IO.StreamReader strm = System.IO.File.OpenText(strFilePath);

    // Attach the output for reading
    System.IO.StreamReader sOut = proc.StandardOutput;

    // Attach the in for writing
    System.IO.StreamWriter sIn = proc.StandardInput;

    // Write each line of the batch file to standard input
    while(strm.Peek() != -1)
    {
      sIn.WriteLine(strm.ReadLine());
    }

    strm.Close();

    // Exit CMD.EXE
    string stEchoFmt = "# {0} run successfully. Exiting";

    sIn.WriteLine(String.Format(stEchoFmt, strFilePath));
    sIn.WriteLine("EXIT");

    // Close the process
    proc.Close();

    // Read the sOut to a string.
    string results = sOut.ReadToEnd().Trim();

    // Close the io Streams;
    sIn.Close(); 
    sOut.Close();

    // Write out the results.
    string fmtStdOut = "<font face=courier size=0>{0}</font>";
    this.Response.Write(String.Format(fmtStdOut,results.Replace(System.Environment.NewLine, "<br>")));

UPDATE: I changed the paths to C:\\Temp\\ just to see if it made a difference, but it didn't. I opened my security wide open on the dirs I'm using, no go.

UPDATE 2: Running this on my dev box is the same, but I actually get feedback shown in the block below. If I manually perform this in cmd, it executes no problem. If I manually run the batch itself, there's no problem.

> Microsoft Windows [Version 6.1.7601]
>Copyright (c) 2009 Microsoft Corporation. All rights reserved.
>
>C:\inetpub\wwwroot\DecisionSupport\CMSBenPerfUpload>dtexec /f "ACO-SHS-PatDB.dtsx"
>Microsoft (R) SQL Server Execute Package Utility
>Version 10.50.1600.1 for 32-bit
>Copyright (C) Microsoft Corporation 2010. All rights reserved.
>
>Option "#" is not valid.
>
>C:\inetpub\wwwroot\DecisionSupport\CMSBenPerfUpload>

Answer 1

Your process identity doesn't have right to the directory. Another queston where do you plan to publish this. A sane administrator would prvent any website to run executables or batch file on the server

Answer 2

I'm going to put an answer in here because I hate leaving things unresolved. I never could get this to work exactly right in this form. I had a network admin check permissions just to make sure I wasn't overlooking something, and they couldn't find anything that made a difference either. All permissions seemed to be properly granted.

Somewhere between the version differences in my dev PC and the server for all parts, Windows, SQL Server, Visual Studio, somewhere in there the problem kept itself well-hidden. Kudos to Microsoft for making products that fail to work properly from one machine to the next without wasting far too many hours hunting for a resolution.

Either way, I ended up going a different route. I built very simple SSIS packages on my SQL 2012 server that could be executed from Stored Procedures built on the server. This kept permission and version issues at bay. I then used C# scripting to write out my XML results files to the directories needed. The one issue to overcome was that C# executescalar will not handle XML larger than 2033 characters so I had to use ExecuteXmlReader and loop through the results to built my string before writing it to file.

This problem, though ending differently than it began, is resolved.