MS Build инсталировать, запустить из-под IIS и выполнить специфический target.​

MS Build инсталировать, запустить из-под IIS и выполнить специфический target.

Голая система с включенным ИИС.

Требуется куда-то разместить МС Билд со всеми нужными библиотеками, не дублируя имеющиеся, но так чтобы МС Билд их юзал. Обычно после перемещения он их не видит. По ощущениям там захардкожены относительные пути. Размещение МС Билд - вне структуры каталогов ИИС.

Требуется из-под ИИС запустить указанный МС Билд и чтобы он выполнил написанное в определенном Таргетсе. Таргетс лежит в произвольном месте файловой системы, но полный или относительный путь известен. Чтобы не было глупых вопросов - компилировать ничего не надо - надо работать с довольно объемным ХМЛ - резать, склеивать, добавлять - инструменты для этого будут. Но это не в этой части задачи.

Вопрос - как это делать?

Все то же самое, но в системе проинсталлена МС ВСтудия... Как тогда?

А нейросблёв чё говорит?

Что надо поднимать сервер на котором были наработки.

Мне больше рассказал, но думаю самое интересное это:

Архитектурная рекомендация (почему так делать не стоит)

Запуск MSBuild из IIS-воркера считается антипаттерном:

• w3wp.exe оптимизирован под HTTP, а не под длительные процессы.
• Пул приложений может быть переразвернут, убит IIS-ом из-за таймаута или потребления памяти.
• Масштабирование и отказоустойчивость отсутствуют.

Правильная архитектура:

1. Веб-приложение принимает запрос и кладёт задачу в очередь (RabbitMQ, Azure Queue, Hangfire, BackgroundService).
2. Отдельный фоновый воркер (Windows Service, консольное приложение, Docker-контейнер) вычитывает очередь, настраивает окружение, запускает MSBuild и возвращает статус.
3. Веб-приложение опрашивает статус или получает callback/webhook.

• Пул приложений может быть переразвернут, убит IIS-ом из-за таймаута или потребления памяти.
• Масштабирование и отказоустойчивость отсутствуют.

-----

Вот это создает проблему. Правда Я не понимаю почему ИИС прибивает внешний процесс.

Масштабирование не критично - там все одно очередь.

А фоновый воркер мне не нравится - может отвалиться...

Я не понимаю почему ИИС прибивает внешний процесс.

не извращаюсь я с IIS, но выглядит логично особенно если processModel.createWorkerProcessJobObject="true"

Спросим подробности, всю простынь с решением приводить не буду, только выводы

• Ограничить время выполнения (WaitForExit с таймаутом)
• Писать логи в файлы (/fileLogger)
• Фиксировать статус отдельно
• Корректно убивать процесс при превышении лимита

не извращаюсь я с IIS

А как нынче вайбкодеры деплоят? Одним промпт-аркестратором сразу на всю распределённую поляну пачку мультисервисных контейнеров накрывают?

Как обычно, фантазии лезут изо всех дыр, вместо того чтобы спросить, что имелось в виду?