Запустить консольное приложение (.exe) из приложения ASP.NET (IIS 7,5)

Question

У меня есть приложение ASP.NET для Windows 2008 R2 (.NET Framework 4.0, IIS 7.5), и я хочу запустить консольное приложение когда я нажимаю кнопку на веб-странице. Вот код:

protected void btnUpdate_Click(object sender, EventArgs e) 
    { 
     string fileLocation = @"D:\DTDocs\App_Code\LoadDTDocsXML.exe"; 
     ProcessStartInfo oStartInfo = new ProcessStartInfo(); 
     oStartInfo.FileName = fileLocation; 
     oStartInfo.UseShellExecute = false; 
     Process.Start(oStartInfo); 
} 

При запуске приложения ASP.NET из в Visual Studio 2010 (с внутренней IIS), консольное приложение хорошо работать. Но когда я запускаю приложение ASP.NET вне VS 2010, у меня нет ошибки, но консольное приложение не выполняет его работу (он должен создать xml-файл на диске). Я думаю, что проблема в конфигурации IIS 7.5, я не знаю точно, к какой учетной записи я должен предоставить права доступа к папкам, связанным с моим консольным приложением. В IIS 7.5 я установил Учетные данные физического пути для Конкретный пользователь = моя учетная запись Windows, но это не решило проблему. Спасибо.

Answer 1

ASP.NET Dev Server работает под учетными данными текущего пользователя (это вы). IIS 7.5 запускает приложения ASP.NET под пользователем, указанным в настройках пула приложений - обычно ApplicationPoolIdentity (к которому вы можете обращаться как пользователь «IIS AppPool \ [ApplicationPoolName]» при настройке прав доступа к файлам). Вы также можете изменить его на «Сетевая служба» (значение по умолчанию в IIS 7.0).

Проверьте, какой идентификатор настроен для вашего пула приложений и предоставить этим пользователям необходимые разрешения.

Answer 2

первая проблема, которую я вижу, это доступ к безопасности/файлу. при запуске из VS сервер и клиент - это один и тот же компьютер под вашими учетными данными. при запуске в тестовой/производственной среде сервер и клиент являются физически разными машинами, а IIS запускает веб-сайт под ограниченными разрешениями. поэтому есть очень хороший шанс, что IIS не сможет получить доступ к файлу в D: ... из-за безопасности.

Следующая проблема запускает консольное приложение с веб-сайта. Консоль - это еще одна форма пользовательского интерфейса, как html и WPF. лично я бы не запускал консоль из Интернета (если только не было другого выбора). Я бы интегрировал API в веб-приложение. 2 пользовательских интерфейса используют одну и ту же логику.

Answer 3

Просто чтобы добавить к другим 2 ответам - Вам нужно действительно нужно запустить exe с вашего веб-сервера?

Мне приходилось делать это в прошлом, и это почти всегда возможность последней инстанции - это значительно ослабляет вашу безопасность (теперь все, кто должен сделать, чтобы запускать исполняемые файлы в вашей системе, - это найти один недостаток в вашем коде) и имеет целый ряд других проблем (веб-сервер не «входит в систему» ​​на сервере, поэтому у него нет рабочего стола, олицетворение - настоящая боль в a $$, чтобы нормально работать (при условии, что вы собирается запустить исполняемый файл с различными разрешениями на веб-сервер) и т.д.

Если есть другой путь для достижения своей цели, он почти наверняка будет проще.

опцион мы пошли в том, чтобы иметь новое приложение с WCF en dpoint, с которым может взаимодействовать веб-сервер. Таким образом, когда кто-то нажимает кнопку, вызов WS вызывает наше приложение через WCF и сообщает ему, чтобы он выполнял различные команды. Таким образом, у вас есть:

• Чистое разделение между кодом сети и консоли.
• ненадежной консоли приложение не снесут веб-сервер & наоборот
• Если приложение консоли давно работает, это позволяет шататься ваши релизы сайт/консольного приложения, так что вы не убить app mid-execution просто потому, что вам нужно обновить CSS и опубликовать.
• Огромные преимущества безопасности - веб-сервер не может запускать исполняемые файлы, даже если они скомпрометированы.
• Приложение WCF сможет внимательно изучить запросы, чтобы решить, действительны ли они до выполнения.

Следует иметь в виду, что, хотя вы это делаете, если кто-то злонамеренно работает над тем, что происходит, и может начать процесс, они могут, возможно, сделать это с почти нулевым усилием. Убедитесь, что этот метод заблокирован.

Редактировать: прочитав ваши комментарии выше, я думаю, что вы столкнулись с проблемой «рабочего стола». При запуске исполняемого файла с сервера приложение никогда не будет видимым для зарегистрированного пользователя, поскольку рабочий стол пользователя не доступен из IIS и наоборот. Это очень похоже на проблему с графическим интерфейсом в службе Windows.

This также может представлять интерес.