Лучшие практики для крупных решений в Visual Studio (2008)

Question

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

• как вы лучшие ссылки рукояток между проектами
  • должен «копию локального» быть включен или выключен?

• должен каждый проект создания своей собственной папке или все должны они строить в ту же папку вывода (все они являются частью одного и того же приложения)

• ли папки Решений хороший способ организации материал?

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

Answer 1

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

Что касается времени открытия и создания времени, это будет трудно исправить, не разбираясь на более мелкие решения. Вы можете исследовать параллелизацию сборки (Google Parallel MS Build) для того, чтобы сделать это и интегрироваться в пользовательский интерфейс), чтобы улучшить скорость здесь. Кроме того, посмотрите на дизайн и посмотрите, поможет ли рефакторинг некоторым из ваших проектов, чтобы добиться меньшего общего объема.

Answer 2

Что касается облегчения боли в здании, вы можете использовать опцию «Configuration Manager ...» для построения, чтобы включить или отключить создание конкретных проектов. У вас может быть «Project [n] Build», который может исключать определенные проекты и использовать их при ориентации на определенные проекты.

Что касается проектов на 100+, я знаю, что вы не хотите забивать этот вопрос о преимуществах сокращения размера вашего решения, но я думаю, что у вас нет другого выбора, когда дело доходит до ускорения время загрузки (и использование памяти) devenv.

Answer 3

+1 для щас использование папок с решениями, чтобы помочь организовать материал.

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

FWIW, мы используем ссылки на проекты для решений, и хотя nuget, вероятно, лучший выбор в наши дни, нашел svn: externals, чтобы хорошо работать как для сторонних, так и для встроенных сборок. Просто привыкните использовать определенный номер ревизии вместо HEAD, когда ссылаетесь на svn: externals (виновен как заряженный :)

Answer 4

Что я обычно делаю с этим, это немного зависит от того, как происходит процесс «отладки». Обычно, хотя я НЕ устанавливаю локальную копию, чтобы быть правдой. Я настраиваю каталог сборки для каждого проекта, чтобы вывести все в нужную конечную точку.

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

Примечание

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

Answer 5

У нас есть аналогичная проблема. Мы решаем его с помощью небольших решений. У нас есть главное решение, которое открывает все. Но перфекционист. это плохо. Таким образом, мы сегментируем более мелкие решения по типу разработчика. Таким образом, разработчики БД имеют решение, которое загружает проекты, о которых они заботятся, разработчикам сервисов и разработчикам пользовательского интерфейса то же самое. Это редкость, когда кто-то должен открыть все решение, чтобы получить то, что им нужно делать изо дня в день. Это не панацея - у нее есть свои плюсы и минусы. См. «Модель с несколькими решениями» in this article (игнорируйте часть об использовании VSS :)

Answer 6

У нас есть аналогичная проблема, так как у нас есть 109 отдельных проектов. Для того, чтобы ответить на оригинальные вопросы, основанные на нашем опыте:

1. Как вам лучшие ссылки ручки между проектами

Мы используем опцию контекстного меню «Добавить ссылку». Если выбран «проект», то зависимость по умолчанию добавляется к нашему одиночному глобальному файлу решения.

2. Следует ли включать или отключать «копировать локальные»?

В нашем опыте. Дополнительное копирование просто добавляет к времени сборки.

3. Если каждый проект создания своей собственной папке или все должны они строить в ту же папку вывода (все они являются частью одного и того же приложения)

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

4. Есть ли папки решений, способные организовать материал?

Нет в нашем опыте. Структура папок одного человека - это чужой кошмар. Глубоко вложенные папки просто увеличивают время, необходимое для поиска чего-либо. Мы имеем абсолютно плоскую структуру, но называем наши файлы проектов, сборки и пространства имен одинаковыми.

---

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

Неполный пример нашего макета решения:

\bin 

OurStuff.SLN 

OurStuff.App.Administrator 
OurStuff.App.Common 
OurStuff.App.Installer.Database 
OurStuff.App.MediaPlayer 
OurStuff.App.Operator 
OurStuff.App.Service.Gateway 
OurStuff.App.Service.CollectionStation 
OurStuff.App.ServiceLocalLauncher 
OurStuff.App.StackTester 
OurStuff.Auditing 
OurStuff.Data 
OurStuff.Database 
OurStuff.Database.Constants 
OurStuff.Database.ObjectModel 
OurStuff.Device 
OurStuff.Device.Messaging 
OurStuff.Diagnostics 
... 
[etc] 

Answer 7

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

Каждое решение будет выдавать результат, за который он несет ответственность. Этот вывод должен содержать информацию о версии, которая может быть установлена ​​в автоматическом процессе. Когда выход стабилен, вы можете обновлять ссылки в зависимых проектах и ​​решениях с последним внутренним распределением. Если вы все еще хотите войти в код и получить доступ к источнику, вы можете это сделать с помощью сервера символов Microsoft, который Visual Studio может использовать, чтобы вы могли входить в ссылочные сборки и даже извлекать исходный код.

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

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

Надеюсь, эта информация поможет.

Answer 8

У нас есть около 60 проектов, и мы не используем файлы решений. У нас есть сочетание проектов C# и VB.Net. Производительность всегда была проблемой. В то же время мы не работаем над всеми проектами. Каждый разработчик создает свои собственные файлы решений на основе проектов, над которыми они работают. Файлы решений не проверяются в нашем исходном элементе управления.

Все проекты библиотеки классов будут построены в папке CommonBin в корневой директории источника. Исполняемые/веб-проекты создаются в их отдельной папке.

Мы не используем ссылки на проекты, а ссылаемся на файлы из папки CommonBin. Я написал пользовательскую задачу MSBuild, которая будет проверять проекты и определять порядок сборки.

Мы использовали это в течение нескольких лет и не имеем никаких претензий.

Answer 9

Возможно, вас заинтересуют эти две статьи MSBuild, которые я написал.

MSBuild: Best Practices For Creating Reliable Builds, Part 1

MSBuild: Best Practices For Creating Reliable Builds, Part 2

Specificially в части 2 есть раздел Построение больших исходных деревьев, которые вы можете взглянуть на.

Чтобы кратко ответить на ваши вопросы, хотя здесь:

• CopyLocal? Обязательно отключите это устройство
• Построить одну или несколько выходных папок? Построить в одну папку вывода
• Пакеты решений? Это вопрос вкуса.

Сайед Ибрагим Хашими

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

Answer 10

Разгрузка проекты, которые вы не используете часто и покупают SSD. SSD не улучшает время компиляции, но Visual Studio становится в два раза быстрее, чтобы открывать/закрывать/строить.

Answer 11

Все это связано с вашим определением и представлением о том, что такое решение и проект. На мой взгляд, решение - это просто логическая группировка проектов, которые решают очень специфические требования. Мы разрабатываем большое приложение для интрасети. Каждое приложение внутри этой Интранет имеет свое собственное решение, которое также может содержать проекты для служб exes или windows. И тогда у нас есть централизованная структура с такими вещами, как базовые классы и помощники и httphandlers/httpmodules. Базовая структура довольно большая и используется всеми приложениями. Разбивая многие решения таким образом, вы уменьшаете количество проектов, требуемых решением, так как большинство из них не имеют ничего общего друг с другом.

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

Мой совет заключается в том, чтобы сделать это и разработать централизованную структуру (ваша собственная реализация Enterprise Library, если хотите). Вы можете использовать GAC для совместного использования, или вы можете напрямую ссылаться на местоположение файла, чтобы у вас был центральный магазин. Вы можете использовать ту же тактику для централизованных бизнес-объектов.

Если вы хотите напрямую обратиться к DLL, вам нужно будет ссылаться на него в своем проекте с копией local false (где-то вроде c: \ mycompany \ bin \ mycompany.dll). Во время выполнения вам нужно будет добавить некоторые параметры в ваш app.config или web.config, чтобы он ссылался на файл, не содержащийся в GAC или bin. Во всей действительности не имеет значения, скопирован ли он локально или нет, или если dll попадает в корзину или даже находится в GAC, потому что config переопределит оба этих параметра. Я думаю, что это плохая практика, чтобы скопировать местную и иметь грязную систему. Скорее всего, вам придется временно копировать локально, если вам нужно отлаживать одну из этих сборок.

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

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

Answer 12

Set CopyLocal = ложь сократит время сборки, но может вызвать различные проблемы во время развертывания.

Существует много сценариев, когда вам нужно, чтобы Копировать Локаль оставил на True, например. Проекты верхнего уровня, Зависимости второго уровня, DLL, вызываемые отражением.

Мой опыт с настройкой CopyLocal = false не был успешным. См. Резюме pro и cons в своем сообщении в блоге "Do NOT Change "Copy Local” project references to false, unless understand subsequences."