Автоматически восстанавливать визуальные студийные проекты, но изменить ссылку
Этот вопрос, вероятно, слишком широкий, но...
У меня есть 300 проектов (скажем, project1_v1.sln, project2_v1.sln...), все они зависят от 1 библиотеки классов (скажем, classLib_v1.sln), каждые 3 месяца нам нужно вносить небольшую поправку в библиотеку классов (интерфейсы и реализацию), которая сломаете некоторые проекты, вы потом исправите эти проекты и развернете.... противно....
НО....
вместо того, чтобы вносить поправки в существующие проекты, мы бы скорее регенерировали их как новую "разветвленную" версию....
Итак... клон classLib1.sln, чтобы заставить classLib2.sln внести поправку, а затем заново сгенерировать project1_v1.sln, в project1_v2.sln, который ссылается на classLib2, а не на classLib1.....compile.... и исправляет.
Т.е. есть 2 версии каждого проекта.
ощущается как некая автоматизированная "производственная линия" продуктов.
Мы используем TFS, но наш контроль версий очень линейный, поэтому я не знаю, как с этим справиться, не создавая беспорядка.
мысли?
Было несколько полезных ответов, но просто для ясности, речь идет не о том, чтобы избежать критических изменений, код будет сломан, об автоматизации изменений (ссылки), а затем об использовании этой автоматизации, чтобы сообщить нам, где код сломалось.
Внедрение зависимостей было принято как решение, и его можно использовать, но вам все равно нужно автоматизировать изменение конфигурации, а недостатком является то, что настраиваемый DI не является типоустойчивым, поэтому компилятор больше не может сказать вам, где вы находитесь. У меня проблема.
3 ответа
В конечном счете, я думаю, что это вопрос о CI и sourcecontrol (а не об архитектуре программного обеспечения, DI и любых других подобных вещах), иногда неизбежно приходится применять изменение, которое что-то нарушает (если вы не связываете свой код с какими-либо абстракциями).... и используйте CTRL C, чтобы поделиться поведением!).
Таким образом, ответ... исследовать, как использовать sourcecontrol и CI для стадии разработки, UAT и производственных версий семейства приложений
Если обновление интерфейсов вызывает перестройки и цель состоит не в том, чтобы перестраивать против существующих потребителей при новых изменениях, то не следует вносить изменения в существующие интерфейсы, вызывающие перестройки.
Если представлены новые функциональные возможности, то должен быть создан новый интерфейс, который может наследоваться от общего интерфейса в качестве базового или даже от предыдущего интерфейса; следовательно, только выставляя новые функциональные возможности новым потребителям.
Это можно сделать с помощью внедрения зависимости, вместо того, чтобы постоянно перекомпилировать код, вы полагаетесь на конфигурацию xml, таким образом вам не нужно перекомпилировать код каждый раз, когда меняется зависимость. Но имейте в виду, что это будет работать до тех пор, пока вы не добавите новые функции или методы вместо удаления или переименования используемых вами.
Ниже приведен один из вопросов, которые имеют ту же проблему.
Внедрение зависимости - выберите DLL и реализацию класса во время выполнения через файл конфигурации
Теперь есть еще одна вещь. У tfs есть опция процесса непрерывной интеграции, которой вы можете воспользоваться, для этого вы должны быть администратором tfs. Вы можете указать опцию Gated Check-In, чтобы обезопасить себя от сбоя при изменении кода. Вот документация Gated Check-in
Теперь вы можете поставить для всех своих проектов также триггер на tfs, и если они указывают на определенную папку, чтобы отслеживать изменения в этой папке, если кто-то зарегистрировал изменение в зависимой dll или проекте, который там хранится, то вы может запустить автоматическую сборку на tfs, чтобы увидеть, правильно ли компилируется этот конкретный проект или нет с использованием этой новой зависимости.