Установка расширений без перезапуска

Одно из удобств платформы Portal: установка и обновление расширений не требуют перезапуска веб-сервера (nginx, IIS) и не останавливают работу портала для пользователей.

В классическом SharePoint on-premises развёртывание farm solutions (WSP) и обновление сборок в GAC часто приводят к recycle app pool или iisreset — кратковременному простою. В Portal расширения подключаются горячей перезагрузкой DLL в уже работающих процессах.

Граница доверия: пакеты ставит только portal admin. DLL выполняется в процессе API/Worker (не в отдельном sandbox). Пути в ZIP проверяются против zip-slip; код от admin по-прежнему имеет полный доступ к процессу.

Что можно обновлять без рестарта

Тип расширения	Пакет	Где выполняется	Механизм
WebPart	.portalpart	Portal.Api	Выгрузка и загрузка DLL в памяти API (AssemblyLoadContext)
Event Receiver	.portalevent	Portal.Worker	Сигнал через Valkey → перезагрузка обработчиков
Timer Job	.portaltimer	Portal.Worker	Тот же сигнал через Valkey

Не перезапускаются: nginx / IIS, контейнер api, контейнер worker, службы portal-api и portal-worker.

WebPart

1. Администратор загружает .portalpart в Админка → WebPart (или POST /api/v1/webparts/packages).
2. При переустановке пакета с тем же id в manifest.json старая DLL выгружается из памяти API, новая регистрируется в каталоге.
3. Новый код подхватывается при следующем рендере или action-запросе WebPart.
4. CSS и JS версионируются в URL (?v=1.0.2) — после обновления пользователю может понадобиться жёсткое обновление страницы в браузере (Cmd+Shift+R / Ctrl+Shift+R).

Подробнее: Сборка и обновление WebPart.

Event Receiver и Timer Job

1. API сохраняет пакет в объектное хранилище (S3) и публикует сигнал в Valkey на канал portal:event-handlers:reload.
2. Worker подписан на этот канал и перезагружает DLL Event Receiver и Timer Job без docker compose restart worker.
3. Если Valkey временно недоступен, Worker подхватит изменения при следующем опросе очереди (интервал по умолчанию ~5 с).

Подробнее:

• Event Receivers
• Timer Jobs

Схема

Админка → загрузка пакета (.portalpart / .portalevent / .portaltimer)
        ↓
   PostgreSQL + S3 (метаданные и файлы пакета)
        ↓
   ┌─────────────────────────────────────────────────────┐
   │ WebPart          → API: unload/load DLL in-process  │
   │ Event Receiver   → Valkey signal → Worker reload DLL  │
   │ Timer Job        → Valkey signal → Worker reload DLL  │
   └─────────────────────────────────────────────────────┘
        ↓
   Пользователи продолжают работу без простоя

Когда перезапуск всё же нужен

Рестарт служб или контейнеров требуется не при установке расширений, а при других операциях:

• обновление платформы Portal (новая версия API/Worker);
• смена переменных в .env или конфигурации;
• миграции схемы БД (db-init);
• ручной рестарт по регламенту обслуживания.

См. Установка и Troubleshooting.

Сравнение с SharePoint

	SharePoint (on-prem, farm solutions)	Portal
WebPart / WSP	Часто recycle app pool	Hot-reload DLL в API
Event Receiver / Timer Job	Зависит от типа решения	Reload DLL в Worker
nginx / IIS	Может затрагиваться	Не перезапускается
Простой для пользователей	Возможен при деплое	Не требуется при установке пакетов