Структура версий и решений в Visual Studio

Question

У меня есть система, которая имеет три приложения (одно приложение для Windows и два веб-приложения). Эти приложения объединяют две общие сборки. Поэтому у меня всего 5 проектов. Раньше у меня было отдельное решение для каждого проекта. Это позволило мне каждую версию каждой сборки в исходном элементе управления. Однако это имеет значительные накладные расходы, потому что я должен открыть каждое решение отдельно, чтобы проверить, не изменилось ли какое-либо изменение, которое я сделал для одной из общих сборок, для любого из приложений.

Я подумал о переходе к структуре, в которой одно решение содержит все проекты. Это позволяет мне сразу увидеть влияние любых изменений, которые я делаю, но это приводит к проблемам с версией. Если я меняю общую сборку или меняю только одно приложение, каждый проект/сборка скоро будет на другом уровне версии. В исходном управлении, поскольку все решение находится вместе, у меня нет одного номера версии для использования в моем репозитории проектов.

Каждое обсуждение, которое я прочитал, похоже, решает одну проблему или другую проблему. Или несколько решений для упрощения управления версиями или единого решения для упрощения управления зависимостями.

Какие предложения люди должны структурировать решения/проекты, имея возможность правильно выполнить сборку?

Answer 1

Я бы придерживался нескольких решений. Ваше приложение Windows действительно не должно (и не должно) знать, что происходит в ваших веб-приложениях.

Я работаю с аналогичной установкой, где у нас есть несколько веб-приложений с общими сборками, совместно используемыми между ними. Имея ежедневную (или непрерывную, если время сборки достаточно быстро), сборка помогает значительно. Мы используем NAnt и CruiseControl, но доступные варианты столь же многочисленны, как мнения.

Если вы используете непрерывную сборку, вы можете запустить другое решение (веб-приложения и т. Д.) После создания разделяемых библиотек и передачи их модульных тестов. Вам все равно придется открывать другое решение, но сервер сборки может сказать вам, если вам нужно.

Answer 2

Лично мне нравится решение, которое облегчает управление зависимостями. Меня гораздо больше беспокоит нарушение изменений, чем у меня есть предметы в той же версии #.

Единственный раз, когда я (лично) был бы обеспокоен версией #, когда мне нужно устранить неполадки или исправить ошибку. И если мне нужно исправить ошибку, то я в конечном итоге перекомпилирую код и буду иметь самую последнюю версию. Честно говоря, если есть кто-то, где работает код, который использует более старую версию какой-либо общей библиотеки классов, которую я разработал, и что? Если это сработает, мне все равно, если он в старой версии. Вероятно, единственная причина в том, что новая версия - это то, что какое-то другое приложение, написанное позднее, нуждалось в дополнительной функциональности.

Это, конечно же, предполагает, что вы следуете за заповедью: «Вы не должны менять общие сборки, это так, что изменение нарушает существующий код». Добавление новой функции в порядке. Изменение функции, чтобы она работала по-разному внутренне, но возвращает тот же результат в порядке. Изменение функции так, что она работает для нового программного обеспечения, но нарушает существующее программное обеспечение, НЕ ОК. Тогда беспокоиться о версировании становится проблемой.

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