Управление версиями и структурами решений в Visual Studio - PullRequest
1 голос
/ 23 июня 2010

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

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

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

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

Ответы [ 2 ]

1 голос
/ 23 июня 2010

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

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

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

0 голосов
/ 23 июня 2010

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

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

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

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

...