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





Наличие слишком большого количества файлов DLL может стоить вам во время выполнения, поэтому я бы рекомендовал вам попытаться минимизировать количество проектов. Создание нескольких решений также является вариантом, но постарайтесь сделать решения независимыми друг от друга, чтобы вам не приходилось отлаживать и реализовывать новые функции в нескольких решениях - это может быть обременительным.
Взгляните на эту статью: Антишаблон проекта: множество проектов в файле решения Visual Studio.
Я бы сказал, что это стоит вам во время сборки, а не во время выполнения. И чем меньше, тем быстрее, но, возможно, вы не всегда создаете их все. В этом случае вам следует уменьшить сумму. иначе разделите их на разные решения. Тогда только серверу сборки нужно будет собрать их все, а у ежедневной сборки будет вся ночь на сборку ;-)
Есть ли цепочка зависимости между всеми 25 проектами? Если одни проекты не зависят от других, включите их в собственное решение.
Не компилируйте все решение, если в этом нет необходимости, а обычно этого не происходит. Обычно вы можете щелкнуть правой кнопкой мыши только что измененный проект и скомпилировать его. VS выяснит, какие зависимые проекты нужно перекомпилировать.
Используйте «запуск без отладки», если вы не планируете достичь точки останова.
Некоторые библиотеки DLL стабильны и давно не менялись? Их тоже не обязательно должно быть в вашем решении.
Не ищите решение целиком, если в этом нет необходимости.
Настоящее ограничение - это человеческий разум. Сколько файлов в одном проекте можно обрабатывать? Кроме того, если вы не используете ndepends для отслеживания зависимостей, размещение нескольких классов в одном проекте может привести к слишком большому количеству классов в зависимости от других классов, что сделает изменения более сложными и рискованными.
Обычно мы стараемся, чтобы количество проектов в решении не превышало 10. После 10 вы начинаете иметь медленное время компиляции и медленное время «перезагрузки проекта».
Но главный вопрос - почему у вас 26 проектов? На простом веб-сайте может быть только 1 проект, в то время как уровень данных, бизнес-уровень и уровень представления останутся внутри одного проекта.
Если вы разделяете проекты только на эти 3 уровня, я предлагаю вам пересмотреть это. Например, у нас есть 3 проекта для 3 уровня. Причина, по которой у нас есть 3 уровня в отдельной сборке, заключается в том, что мы запускаем другое программное обеспечение для использования уровня данных позже в нашем проекте. Сохранение нашего бизнес-уровня за пределами основного проекта презентации позволяет нам легко проводить модульное тестирование нашего бизнес-уровня, сохраняя при этом бесполезные зависимости за пределами уровня презентации.
Итак, в целом старайтесь не превышать 10 проектов и проверьте, можете ли вы объединить несколько проектов вместе. Это сэкономит ваше время как во время компиляции, так и во время сборки. Так же будет проще управлять этими библиотеками DLL.