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

Ответ 1

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

MSBuild: лучшие практики для создания надежных сборок, часть 1

MSBuild: лучшие практики для создания надежных сборщиков, часть 2

В частности, в части 2 есть раздел Создание больших деревьев источников, которые вы можете посмотреть.

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

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

Сказал Ибрагим Хашими

Моя книга: Внутри Microsoft Build Engine: использование MSBuild и Team Foundation Build

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

У нас есть аналогичная проблема, так как у нас есть 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]

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

Примечание

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

Ответ 8

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

Ответ 9

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

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

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

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

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

Ответ 10

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

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

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

Мы используем это уже несколько лет и не имеем никаких жалоб.

Ответ 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/

Ответ 12

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

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

Мой опыт установки CopyLocal = false не был успешным. См. Резюме pro и cons в своем сообщении в блоге "НЕ ИЗМЕНЯЙТЕ" Копировать локальные "ссылки на проект на false, если не понимать подпоследовательности" .