Difference between starting process from Console applciation and ASP.NET application

Question

I have a Web API application that needs to run a Python script which in turn runs a Perl script:) does some otehr stuff and get the output results from it. The way I do this is with starting a Process:

        var start = new ProcessStartInfo()
        {
            FileName = _pythonPath,                                 //@"C:\Python27\python.exe",
            Arguments = arguments,                                  //@"D:\apps\scripts\Process.py
            UseShellExecute = false,
            RedirectStandardOutput = true,
            RedirectStandardError = true
        };

        using (Process process = Process.Start(start))
        {
            using (StreamReader reader = process.StandardOutput)
            {
                var result = reader.ReadToEnd();
                var err = process.StandardError.ReadToEnd();                
                process.WaitForExit();

                return result;
            }
        }

The script inside tries to connect to Perforce server using P4 Python API and then Perl script call a P4 command as well. When running this code from Console application, everything goes fine. The program automatically gets the Perforce settings (I've got a P4V client with all the settings specified). But when running from ASP.NET Web API, it doesn't get the settigns and says that it cannot conenct to perforce:1666 server (I guess this is the standard value when no settign specified).

I do understand that not so many people use Perforce, especially in such way and can help here, but would like to know what is the difference between running this script from Console app and Web API app that mich cause this different behaviour.

Answer 1

One of the most obvious differences between running code from a console application and running code in IIS ^* is that, usually, the two pieces of code will be running under different user accounts.

Frequently, if you're experiencing issues where code works in one of those situations and not the other, it's a permissions or a per-user-settings issue. You can verify whether this is the case by either running the console application under the same user account that is configured for the appropriate IIS application pool, or vice verse, configure the application pool to use your own user account, and then see whether the problem persists.

If you've confirmed that it's a permissions issue and/or per-user-settings, then you need to decide how you want to fix it. I'd usually recommend not running IIS application pools under your own user account - if you cannot seem to get the correct settings configured for the existing application pool user, I'd usually recommend creating a separate user account (either locally on the machine or as part of your domain, depending on what's required) and giving it just the permissions/settings that it requires to do the job.

---

^* IIS Express being the exception here because it doesn't do application pools and the code does end up running under your own user account.