Привет.
Когда-то имплементировал долгоиграющий процесс для ASP.NET приложения как виндоус сервис. Плохо, потому что супорту надо устанавливать 2 части софта: собсно веб-приложение и винсервис. Обьянснять почему такая простая вещь может быть плохой, думаю, не надо для тех, кто создавал крупные комерческие приложения.

Есть ли что-то еще?
Клауд хорошо, но не сильно кастомизируется.

QueueBackgroundWorkItem (.NET 4.5). Хорошо, но AppDomain таки убивается через 1.5 мин, если IIS впадает в спячку.

Мне нужен процесс, посылающий SMS последовательно. Т.е. послал первому, ждет 10 мин, нет ответа, послал 2-му ... 100-му, 200-му. Процесс рассылки может занять несколько суток и в течение этого времени все должно рассылаться независимо от того, работает ли IIS, рециклирован или остановлен.

Микрософ Кью не предлагать.

Спасибо.

Нашел прекрасный обзор тут:

http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx

И статья и коментарии к ней сводятся все-таки к разделению логики, i.e. написанию отдельного виндоус сервиса.

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

mabanza,
Решение надйено довольно простое. Долгоиграющий класс наследуется от IRegisteredObject и имплементирует его Stop() метод.
Когда IIS выгружает домен, он опрашивает все зарегистрированные обьекты, рассылая им Stop().
Теоретически можно никогда не покинуть скоп этого метода, локнув там объект для блокировки.
Во всяком случае, можно удерживать блокировку до тех пор, пока не запишется лог или не завершиться процесс.
Вполне вероятно, что именно так и имплементирован QueueBackgroundWorkItem в .NET 4.5.2
Спасибо.