Запуск консольного приложения программно при необходимости

Question

У меня есть консольное приложение C#, которое обрабатывает очередь (в db) и обрабатывает загруженное пользователем содержимое. Выполняется как запланированное задание.

Если какой-либо пользователь сбрасывает какой-либо контент, процесс не будет поднимать его, пока не наступит время его запуска.

Если работа выполняется один раз каждые 5 минут, она должна ждать максимум 5 минут для запуска. Я хочу обработать пользовательский контент сразу.

Если пользователь1 сбрасывает контент, а затем пользователь2 сбрасывает контент через 30 секунд, я хочу выполнить 2 экземпляра моей работы.

Можно ли запустить задание \ task для запуска из кода C# (MVC-контроллер)?

Answer 1

По существу, похоже, что вы просто хотите выполнить асинхронную операцию. В зависимости от версии .NET существует несколько вариантов. Например, Task Parallel Library - это простой способ вызвать асинхронную операцию. Таким образом, если задача воплощен в какой-либо объект (для того же примера, скажем, метод, называемый Process на объекте под названием content), то это может выглядеть следующим образом:

var processContent = new Task(() => content.Process()); 
processContent.Start(); 

Задача затем продолжить асинхронно и поток управление вернется к приложению (что особенно удобно в веб-приложении, где вы не хотите, чтобы пользователь смотрел на невосприимчивый браузер, естественно).

Если вы используете .NET 4.5, вы также можете использовать the async and await keywords, чтобы сделать его более понятным. По сути, вы говорите о запуске процесса в a separate thread.

Все это предполагает, что веб-приложение и консольное приложение имеют один и тот же внутренний код бизнес-логики. Который, конечно, , вероятно, что они должны делать. Если по какой-то причине это не вариант (и я рекомендую изучить его вариант), вы можете start a process из кода. Это может быть что-то же просто, как:

Process.Start("C:\Path\To\ConsoleApplication.exe"); 

Хотя разветвление все эти процессы могут выглядеть довольно грязный и может быть очень трудно управлять с точки зрения обработки ошибок/протоколирования/и т.д.. Другая причина, по которой лучше всего поддерживать логику в том же процессе, что и приложение, только в отдельном потоке.