Разработка патчей в DotNet

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

Самое главное — контролировать зависимости: хорошо определить интерфейсы между сборками в начале и добавить новые интерфейсы для расширения существующей функциональности (вместо внесения «критических изменений» в существующие интерфейсы), чтобы можно было внести полезные изменения в приложение без развертывания большого количества сборок в вашем патче. (Если есть много зависимостей, вы обнаружите, что внесение изменений в любом месте по-прежнему потребует от вас развертывания почти всех сборок у клиента, что несколько противоречит цели).

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

Если вы используете метод исправлений, я бы также посоветовал периодически предоставлять клиенту полную версию, так как чем больше исправлений вы применяете, тем выше риск того, что что-то выйдет из синхронизации. (Подумайте о том, как работает Центр обновления Windows — ОС постепенно обновляется с помощью исправлений, но время от времени Microsoft выпускает пакеты обновлений, объединяющие все маленькие исправления в одно большое, и реже они выпускают полностью новую версию операционной системы. что пользователи должны переустанавливать с нуля)