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

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

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

FWIW, мы используем ссылки проекта для решений, и хотя самородок является, вероятно, лучшим выбором в эти дни, нашли, что svn:externals работает хорошо на третью сторону и на (тип платформы) собственная сборка. Просто выработайте привычку использования определенного числа пересмотра вместо ГОЛОВЫ при ссылке svn:externals (виновный, как заряжено:)

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

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

С точки зрения упрощения боли здания можно использовать опцию "Configuration Manager..." для сборок, чтобы включить или отключить здание определенных проектов. У Вас может быть "Сборка проекта [n]", которая могла исключить определенные проекты и использование это, когда Вы нацелены на определенные проекты.

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

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

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

Примечание:

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

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

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

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

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

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

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

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

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

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

2. Должен ли "copy local" быть включен или выключен?

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

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]

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

I think with solutions this large the best practice should be to break them up. You can think of the "solution" as a place to bring together the necessary projects and perhaps other pieces to work on a solution to a problem. By breaking the 100+ projects into multiple solutions specialized to developing solutions for only a part of the overall problem you can deal with less at a given time there by speeding your interactions with the required projects and simplifying the problem domain.

Each solution would produce the output which it is responsible for. This output should have version information which can be set in an automated process. When the output is stable you can updated the references in dependent projects and solutions with the latest internal distribution. If you still want to step into the code and access the source you can actually do this with the Microsoft symbol server which Visual Studio can use to allow you to step into referenced assemblies and even fetch the source code.

Simultaneous development can be done by specifying interfaces upfront and mocking out the assemblies under development while you are waiting for dependencies that are not complete but you wish to develop against.

I find this to be a best practice because there is no limit to how complex the overall effort can get when you break down it down physically in this manner. Putting all the projects into a single solution will eventually hit an upper limit.

Hope this information helps.

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

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

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

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

Я не планировал отвечать на этот вопрос, поскольку я не уверен на 100% в своих знаниях об этом. Но поскольку не похоже, что вы получаете много отклика ...

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

Итак, если вы уверены, что ваши данные чистые (без повторяющихся данных PK), я бы сказал вставить, затем добавьте PK.

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

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