Вы затронули очень большую тему, которая действительно может быть настолько сложной, насколько вы позволите.
В конечном счете, выбранный вами подход к управлению версиями будет зависеть от того, чего вам нужно достичь, и наскольковремя, которое вы должны выделить на его поддержание.Они напрямую связаны между собой.
Две основные цели управления версиями - параллельное выполнение и отслеживание.Параллельное (SxS) позволяет нескольким версиям одной и той же DLL работать в одном приложении.Без изменения номера версии сборки это невозможно.Отслеживание - это просто возможность точно определить моментальный снимок кода, который выполняется на компьютере клиента.И то, и другое может быть достигнуто путем изменения версии сборки, но первое может быть достигнуто только путем изменения версии сборки.
Многие рекомендуют вам использовать номера версий для всех DLL / EXE-файлов.- это хороший способ сделать это, так как это наиболее упрощенный подход, он также обеспечивает наименьшую гибкость развертывания.
Например, если вы используете какую-либо форму абстракции контракта (определение зависимостей между DLL с помощьюинтерфейсы, а не конкретные типы), вы можете разделить ваше приложение на несколько «хранилищ версий».Примером этого могут быть клиент и сервер, где взаимозависимость, если она определена в 3-й сборке, будет заключена вашим WCF.Если все они имеют разные версии, вы можете выпустить новую версию сервера (при условии, что она соответствует одному и тому же контракту), не затрагивая клиента.И наоборот.
Как вы можете видеть, вы будете увеличивать степень детализации версий по мере роста ваших требований, но это повлечет за собой подслушивание.
Лучшее, что вы можете сделать, это именно то, что вы естьделать, сесть и спланировать свои требования, а затем наметить границы управления версиями (какие компоненты могут быть разделены контрактами).
Следующая вещь зависит от размера вашего отдела тестирования, но я также рекомендую вампосмотрите на то, чтобы версия файла отражала (хотя бы частично) номер / дату сборки.Вы будете увеличивать версию сборки только один раз для выпуска клиента, но у вас должна быть другая версия файла для каждой коллекции DLL, которая выходит из сборки.Это связано с тем, что когда вы тестируете и обнаруживаете проблему, наличие уникально идентифицируемых этих DLL-библиотек устранит любые сомнения относительно того, какая именно сборка была создана.