进程启动IIS服务器

Question

I can not call Process.Start("DocToPDF.exe", "file.docx file.pdf") successfully from IIS.

• I have tried allowing desktop interaction from IIS Admin Service;
• I have tried granting full control permissions to DefaultAppPool for the directory containing the DocToPDF.exe

None of this worked. The DocToPDF.exe exits with code: 1 (I write the exit code to a file...). When I run the website in debug mode (F5) the program exits with code: 0 and everything is ok. It works perfectly well in debug mode. My guess is it has something to do with IIS permissions or something like that because as I said it works well when launching the application from visual studio.

Here is the method that I am using:

public byte[] DocToPdf(MemoryStream ms)
{            
    string fileName = Guid.NewGuid().ToString();
    string path = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) + "\\" + fileName + ".docx";
    string newPath = path.Replace("docx", "pdf");
    FileStream fs = new FileStream(path.ToString(), FileMode.OpenOrCreate);
    fs.Write(ms.ToArray(), 0, ms.ToArray().Length);
    fs.Close();

    Process p = new Process();
    p.StartInfo.UseShellExecute = false;
    p.StartInfo.FileName = @"C:\Utils\OfficeToPDF.exe";
    p.StartInfo.Arguments = path + " " + newPath;
    p.Start();
    p.WaitForExit();
    System.IO.File.WriteAllText(@"C:\Utils\exitcode.txt", p.ExitCode.ToString());

    var bytes = System.IO.File.ReadAllBytes(newPath);

    System.IO.File.Delete(path);
    System.IO.File.Delete(newPath);

    return bytes;            
}

Answer 1

It is almost always a horrible idea to call any process from an IIS web site/application.

1. IIS and its worker processes run in session 0. The session isolation can lead to issues if the extra executable requires to be run in a user session. (It is very likely that you hit this, as if the executable attempts to use printing drivers it will hit problems under session 0.)
2. IIS worker processes are running under application pool identities (without user profile loading if you don't change pool settings). That kind of identities can also lead to failures as the executable might require a normal user account.

There are far too many executable fail to run under IIS, so yours is not something new or uncommon.

Meanwhile, when you hit F5 in Visual Studio, your app is running under ASP.NET Development Server, or IIS Express by default, and that's in your user session . Anything works there can break when switching to IIS. So don't be surprise how little you understand about IIS/Windows. Every experts were beginners.

Typical workaround is to find an alternative way that either supported or recommended by Microsoft or a third party vendor. Note that free and open source things are usually developed or tested without such session 0 case in mind, and they can lead to more issues than you thought.