Агнец за бортом,

Самый кул и ваще правильно, маст хев, это разделять на отдельные изолированные солюшены, собирать в нугеты/npm и публиковать во внутренних репозиториях. Каждый из проектов тащит зависимости из пакетов. При грамотной версионности, можно жить даже на нескольких major версиях пакетов и апгрейдить всё каскадно, не нарушая работы существующего кода.

Но как только доходит до отладки, начинают морщить нос, ну как же, я же хочу прям вот брейк вот здесь ставить, где угодно и там отлаживаться откуда угодно. Хочу нубскую отладку с проходом по шагам, чтобы выцепить очередной null referenced exception...

Решается юнит-тестами, интеграционные тесты, правильное логирование и метрика. Мы уже второй год не разрабатываем в отладке. Точнее микро-отладки в юнит-тестах максимум.

Агнец за бортомЯ ничего не понял.

Допустим, я меняю строку кода в проекте, который находится на 4-ом уровне иерархии во вложенных зависимостях.

Что надо сделать, чтобы при отладке заработал измененный код?

Всё пересобрать. Отладку где собрался делать?

Агнец за бортомhVosttВсё пересобрать. Отладку где собрался делать?

Всё пересобирается ДОЛГО.

Отладку собрался делать в студии

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

Petro123hVosttЕсли это невозможно из-за неудачной архитектуры системыда. Это может быть. Но чтобы 200 было?
У нас давно давно проект один из 130 COM dll состоял)))

Глаза боятся, а...