Структурирование проектов и зависимостей больших приложений winforms в C#

Управление исходным кодом

у Нас есть 20 или 30 проектов, встраиваемых в 4 или 5 дискретных решений. Мы используем Подрывную деятельность для SCM.

1) у Нас есть одно дерево в SVN, содержащем все проекты, организованные логически пространством имен и названием проекта. Существует .sln в корне, который создаст их всех, но это не требование.

2) Для каждого фактического решения у нас есть новая магистральная папка в SVN со ссылками SVN:External на все необходимые проекты так, чтобы они были обновлены от их местоположений под основным деревом.

3) В каждом решении .sln файл плюс несколько других необходимых файлов, плюс любой код, который уникален для того решения и не совместно использованный через решения.

Наличие многих меньших проектов время от времени является чем-то вроде боли (например, сообщения обновления TortoiseSVN становятся грязными со всеми теми внешними ссылками), но действительно имеет огромное преимущество, что зависимостям не позволяют быть круговыми, таким образом, наши проекты UI зависят от проектов ФИЛИАЛА, но проекты ФИЛИАЛА не могут сослаться на UI (и, ни если они!).

Архитектура Мы полностью переключились на использование мс SCSF и предприятие CAB шаблон для управления способом, которым наши различные проекты объединяются и взаимодействуют в интерфейсе Win Forms. Я не уверен, если у Вас есть те же проблемы (несколько модулей должны совместно использовать пространство в среде стандартных форм), но если Вы делаете тогда, это может принести некоторую исправность и соглашение к тому, как Вы проектируете и собираете свои решения.

я упоминаю что, потому что SCSF имеет тенденцию объединять ФИЛИАЛ и функции типа UI в тот же модуль, тогда как ранее мы поддержали строгие 3 политики уровня:

FW - код Платформы. Код, функция которого касается проблем программного обеспечения. ФИЛИАЛ - Бизнес-объекты. Код, функция которого касается проблем проблемной области. UI - Код, который касается UI.

В том сценарии зависимостями является строго UI-> ФИЛИАЛ-> FW

, Мы нашли, что можем поддержать ту структуру даже, в то время как использование SCSF генерировало модули, таким образом, все хорошо в мире:-)

Чтобы управлять зависимостями, независимо от того, сколько у вас есть сборок / пространств имен / проектов, вы можете взглянуть на инструмент NDepend .

Персонал, я поддерживаю несколько крупных проектов, в рамках одного или нескольких решений, если это необходимо. Я написал о своих мотивах сделать это здесь: Воспользуйтесь преимуществами компиляторов C # и VB.NET

Я думаю, что довольно важно, чтобы у Вас было решение, которое содержит все Ваши 80 проектов, даже если большинство разработчиков использует другие решения большую часть времени. По моему опыту, я склонен работать с одним большим решением, но избегать боли восстановления всех проектов каждый раз я поразил F5, я перехожу к Проводнику Решения, щелкаю правой кнопкой по проектам, которыми я не интересуюсь прямо сейчас, и действительно "Разгрузите Проект". Тем путем проект остается в решении, но это ничего не стоит мне.

Однако 80 большое количество. В зависимости от того, как хорошо те 80 разламывают на dicrete подсистемы, я мог бы также создать другие файлы решения, что каждый содержит значимое подмножество. Это сохранило бы меня, усилие большого количества из щелкает правой кнопкой/Разгружает по операциям. Тем не менее, то, что у Вас было бы одно большое решение, означает, что всегда существует категорическое представление их взаимозависимостей.

Во всех системах управления исходным кодом, с которыми я работал, их интеграция VS принимает решение поместить .sln файл в управление исходным кодом, и многие не работают правильно , если , что .sln файл находится в управлении исходным кодом. Я нахожу это интригующим, так как .sln файл раньше считался персональной вещью, а не вещью всего проекта. Я думаю единственный вид .sln файла, который определенно заслуживает управление исходным кодом, "одно большое решение", которое содержит все проекты. Можно использовать его для автоматизированных сборок, например. Как я сказал, люди могли бы создать свои собственные решения для удобства, и я не против тех, которые входят в управление исходным кодом, но они более значимы для людей, чем к проекту.

Я думаю, что лучшее решение состоит в том, чтобы прервать его к меньшим решениям. В компании я в настоящее время работаю на, у нас есть та же проблема; 80 проектов ++ в на решении. То, что мы сделали, должно разделить на несколько меньших решений с проектами, принадлежащими вместе. Зависимый dll's из других проектов создан и связан в с проектом и зарегистрирован к системе управления исходным кодом вместе с проектом. Это использует больше дискового пространства, но диск является дешевым. Делая его этот путь, мы можем остаться с версией 1 проекта до обновления до версии 1.5, абсолютно необходимо. У Вас все еще есть задание с добавлением dll's, решая обновить до другой версии dll все же. Существует проект на коде Google, названном TreeFrog, который показывает, как структурировать дерево разработки и решение. Это еще не содержит документацию шумов, но я предполагаю, что можно получить идею того, как сделать это путем рассмотрения структуры.

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

Они действительно имели depencies на других проектах, но, если интерфейсы не изменились, или они должны были обновить версию dll, который они использовали, они могли продолжить использовать меньшие проекты, не волнуясь обо всем остальном. Таким образом они могли проекты регистрации, в то время как они работали над ними, и затем прикрепляют их (после изменения номера версии), когда другие пользователи должны начать использовать их.

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

Мы часто находили, что огромные разделы кода часто не изменялись, таким образом, это была бессмысленная загрузка всего этого время. (Когда Вы работаете над меньшими проектами.)

Другое преимущество использования этого подхода находится в определенных случаях, у нас были части функциональности, которая заняла месяцы для завершения, при помощи вышеупомянутого подхода, предназначенного, это могло продолжиться, не прерывая другие потоки работы.

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

У нас есть одно гигантское решение по управлению источниками, на главной ветви.

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

Однако есть одно условие для этого: не должно быть слишком много взаимосвязанных проектов в рамках решения.

Хорошо, переваривание этой информации, и также отвечает на этот вопрос о ссылках проекта, я в настоящее время работаю с этой конфигурацией, которая, кажется, 'работает на меня':

• Одно большое решение, содержа проект приложения и все проекты блока зависимости
• я сохранил все ссылки проекта с некоторой дополнительной тонкой настройкой ручных зависимостей (щелчок правой кнопкой по проекту) для некоторых динамично инстанцированных блоков.
• у меня есть три папки Solution (_Working, Synchronised и Xternal) - учитывая, что мое управление исходным кодом не интегрируется с VS ( рыдание ), это позволяет мне быстро перетаскивать проекты между _Working и Синхронизируемый, таким образом, я не теряю след изменений. Папка XTernal для блоков, которые 'принадлежат' коллегам.
• я создал меня конфигурация 'WorkingSetOnly' (последняя опция в выпадающей Отладке/Выпуске), который позволяет мне ограничивать проекты, которые восстановлены на F5/F6.
• , Насколько диск затронут, у меня есть все свои папки проектов во всего одной из нескольких папок (поэтому всего один уровень классификации выше проектов)
• Вся сборка проектов (dll, pdb & xml) к той же выходной папке, и имеют ту же папку как ссылочный путь. (И все ссылки установлены не Сделать копии) - это оставляет меня выбором отбрасывания проекта из моего решения и легко переключения на ссылку на файл (у меня есть макрос для этого).
• На том же уровне как моя папка 'Projects', у меня есть папка 'Solutions', где я поддерживаю отдельные решения для некоторых блоков - вместе с Тестовым кодом (например), и документацией/дизайном, и т.д. характерной для блока.

Эта конфигурация, кажется, работает хорошо на меня в данный момент, но большой тест будет пытаться продать ее моим коллегам, и видящий, полетит ли она как установка команды.

В настоящее время неразрешаемые недостатки:

• у меня все еще есть проблема с отдельными решениями для блока, поскольку я не всегда хочу включать все зависимые проекты. Это создает конфликт с 'основным' решением. Я работал вокруг этого со (снова) макросом, который преобразовывает поврежденные ссылки проекта в ссылки на файл и восстанавливает ссылки на файл на ссылки проекта, если проект добавляется назад.
• нет, к сожалению, никакого пути (что я нашел до сих пор) соединения Конфигурации сборки к Папкам Решения - было бы полезно быть в состоянии сказать, 'создают все в этой папке' - как есть, я должен обновить это вручную (болезненный, и легкий забыть). (Можно щелкнуть правой кнопкой по Solution Folder для создания, но это не обрабатывает сценарий F5)
• существует (незначительная) ошибка в реализации папки Solution, что означает, что, когда Вы вновь открыли решение, проекты показывают в порядке, они были добавлены, и не в алфавитном порядке. (Я открылся ошибка с MS, по-видимому, теперь исправленным, но я предполагаю для VS2010)
• , я должен был удалить дополнение CodeRushXPress , потому что это дросселировало на всем этом коде, но это прежде имело, изменил конфигурацию сборки, таким образом, я собираюсь дать ему другую попытку.

Сводка - вещи я не знал прежде, чем задать этот вопрос, которые оказались полезными:

1. Использование папки решения для организации решений, не смешивая с дисковым
2. Созданием конфигураций сборки для исключения некоторых проектов
3. Способность вручную определить зависимости между проектами даже если они используют ссылки на файл

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

Для пары систем, над которыми я работал, у нас были разные решения для разных компонентов. У каждого решения была общая папка вывода (с подпапками Debug и Release)

Мы использовали ссылки на проекты в решении и ссылки на файлы между ними. В каждом проекте использовались пути ссылок для поиска сборок из других решений. Нам пришлось вручную отредактировать файлы .csproj.user, чтобы добавить переменную $ (Configuration) msbuild к ссылочным путям, поскольку VS настаивает на проверке пути.

Для сборок вне VS я написал скрипты msbuild, которые рекурсивно идентифицируют проект зависимости, извлеките их из Subversion и создайте их.