Разница между процессом запуска из приложения консоли и приложения ASP.NET
У меня есть приложение Web API, которое должно запускать скрипт Python, который, в свою очередь, запускает скрипт Perl:), выполняет некоторые другие операции и получает из него выходные данные. Я делаю это с запуском процесса:
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;
}
}
Сценарий внутри пытается подключиться к серверу Perforce с помощью P4 Python API, а затем сценарий Perl также вызывает команду P4. При запуске этого кода из консольного приложения все идет хорошо. Программа автоматически получает настройки Perforce (у меня есть клиент P4V со всеми указанными настройками). Но при запуске из ASP.NET Web API он не получает settigns и говорит, что не может подключиться к серверу performance:1666 (я думаю, это стандартное значение, когда settign не указан).
Я понимаю, что не так много людей используют Perforce, особенно таким образом, и могут здесь помочь, но хотели бы знать, в чем разница между запуском этого скрипта из приложения Console и приложения Web API, которое может вызывать такое различное поведение.
1 ответ
Одно из наиболее очевидных различий между выполнением кода из консольного приложения и выполнением кода в IIS* заключается в том, что обычно два фрагмента кода будут выполняться под разными учетными записями пользователей.
Часто, если у вас возникают проблемы, когда код работает в одной из этих ситуаций, а не в другой, это проблема с разрешениями или настройками для каждого пользователя. Вы можете проверить, так ли это, запустив консольное приложение под той же учетной записью пользователя, которая настроена для соответствующего пула приложений IIS, или наоборот, сконфигурировав пул приложений для использования собственной учетной записи пользователя, а затем выясните, есть ли проблема сохраняется.
Если вы подтвердили, что это проблема с разрешениями и / или настройками для каждого пользователя, вам нужно решить, как вы хотите ее исправить. Обычно я бы рекомендовал не запускать пулы приложений IIS под своей собственной учетной записью пользователя - если кажется, что вы не можете получить правильные настройки, настроенные для существующего пользователя пула приложений, я обычно рекомендую создать отдельную учетную запись пользователя (локально на компьютере или как часть вашего домена, в зависимости от того, что требуется) и предоставив ему только те разрешения / настройки, которые требуются для выполнения работы.
* IIS Express здесь исключение, потому что он не работает с пулами приложений, а код работает под вашей собственной учетной записью.