Управление версиями и структура решения в Visual Studio

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

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

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

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


.net version-control svn projects-and-solutions
person DCNYAM    schedule 23.06.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person Josh Sterling    schedule 23.06.2010
comment
+1 для непрерывной интеграции и использования сервера сборки с модульными тестами. - person David; 23.06.2010

arrow_upward
0
arrow_downward

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

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

Это, конечно, предполагает, что вы следуете заповеди «не изменяйте общие сборки таким образом, чтобы изменение нарушило существующий код». Добавление новой функции - нормально. Модификация функции таким образом, чтобы она работала по-другому внутри, но возвращала тот же результат, - это нормально. Изменение функции таким образом, чтобы она работала с новым программным обеспечением, но нарушала работу существующего программного обеспечения, НЕ ПРИНИМАЕТСЯ. Тогда перестанет беспокоиться о версиях.

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

person David    schedule 23.06.2010