Ускорение компиляции Visual Studio Solution методом "Copy Local = False".

Обычное исключение из компиляции не изменяемых проектов через Build -> Configuration Manager (колонка Build напротив каждого проекта) не единственный подход для ускорения компиляции в Visual Studio (VS).
Другой способ, строится на том, что нужно отключить поведение Visual Studio по умолчанию, когда VS копирует сборки проектов, в проекты которые ссылаются на первые.

Почему и как:
Если проект A ссылается на проект B, то проект B компилируется первым.
По умолчанию, сборка проекта B дублируется и кладется вместе со сборкой проекта A.
Подход предлагает отключить копирование сборок проектов в Solution с помощью установки свойства референса на сборку Copy Local равным False, а также помещать все сборки в общую папку.

Когда применять:
Я бы использовал только для крайне больших солюшенов, когда более 5 - 10 проектов. Думаю, не стоить без нужды запутывать разработку.

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

Внимание!
Не приступайте к реализации, не изучив пункт Исключения после этих шагов.

1. Если вам надо будет добавлять референсы на другие проекты внутри solution, то не важно через что вы будете это делать в окне Add Reference, через вкладку Projects или через вкладку Browse. Только не забывайте пройти все пункты этой инструкции для каждого нового проекта.


2. Настройте общую папку(и) для сборок внутри Solution.В свойствах каждого проекта выберите вкладку Build.
   Далее зададим путь до общей папки через поле Output path, но сначала обратите внимание, что вверху вкладки Build есть выпадающий список Configuration, где выбирается конфигурация компиляции (обычно Release или Debug или какая-то ваша кастомная, если была создана).Если вы хотите задать одинаковую папку для всех конфигураций компиляции, то выберите в этом списке "All configurations" и задайте значение в поле Output path, например такое "..\bin\", тогда в корне проекта у вас появится папка bin.Если же вам для каждой конфигурации нужно задать отдельную папку, то задайте путь в поле Output path для каждой конфигурации в списке Configurations, кроме значения "All configurations". Например для Release можно задать "..\bin\Release\", а для Debug "..\bin\Debug\".Внимание!
   У Web-проектов ASP.NET папка bin может находиться только внутри корневой папки Web-проекта.
   
   Внимание!
   Если у вас есть проекты, расположены не в корне папки солюшена, то соответственно, поправьте путь для таких проектов.
   Например может понадобится написать не "..\bin\", а "..\..\bin\".


3. Проверьте и настройте, если понадобится, вручную порядок компиляции.
   Мне еще не приходилось воспользоваться этим пунктом, но по мнению Patrick Smacchia (см. в конце) это может понадобится.
   Будьте предельно внимательны, иначе вы можете получать неприятные ошибки.
   Порядок компиляции можно посмотреть из Solution Explorer вызвав из контекстного меню любого проекта или солюшена пункт Project Build Order.
   Настроить порядок можно там же через пункт Project Dependencies.


4. Задайте Copy Local равным False!
   Во всех проектах, в свойствах каждого референса на проект внутри Solution задайте Copy Local = False.
   Для этого в Solution Explorer выберите проект, разверните в нем вкладку References, там и лежат референсы.


5. В конце, чтоб подхватились новые референсы (сборки) в зависимых проектах, выполните Rebuild Solution!
   При ошибке отсутствия dll выполните ребуилд еще раз.


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

Исключения.

1. Случай, когда у вас Solution, в котором несколько корневых проектов!
   Смысл тут такой - для каждого звена (tier) нужна своя общая папка.
   Т.е. для каждого "корневого" проекта должна быть своя общая папка.
   Например, у вас в солюшене, помимо проектов относящихся к Silverlight, есть и другие проекты (обычно ASP.NET), в этом случае для Silverlight создавайте свою отдельную общую папку.
   Понятно, что нет смысла перемешивать в одной папке DLL от ASP.NET и Silverlight.


2. Случай, когда у вас несколько корневых проектов, но они используют общую сборку одного проекта в вашем Solution.
   Лучше сразу попытаться избавиться от этой ситуации или призадуматься, стоит ли применять описанный в статье подход, если общих сборок много. Например такое можно встретить, если у вас в проекте несколько сайтов ASP.NET.К этому случаю не относится Solution в котором одновременно Silverlight и ASP.NET, т.к. у них разные версии .NET Framework и они обычно не пересекаются по сборкам (ну или делайте кросс-компиляционные проекты).
   В случае WCF этого, обычно, тоже можно избежать.Тут вы должны подойти творчески.
   Во первых теперь только для одного "корневого" проекта можно оставить Copy Local равным False в свойствах референса на разделяемый проект (сборку).
   Делайте с расчетом на то, что те проекты, в которых пришлось оставить Copy Local равным True, больше подходят под категорию проектов, которые можно исключить из компиляции (Build -> Configuration Manager, колонка Build напротив каждого проекта).
   Либо можно закрыть глаза на наличие не нужных сборок и exe и запихать таки всё в одну папку. Тогда при развертывании, у вас будут на звеньях (tier) не относящиеся к звену компоненты. Фу какая гадость :) . Хотя это решается скриптом подготовки релиза в Post Build Event. Но это уже муторно.

Какие дополнительные требования
 к разработчику навязывает это решение:
Нужно вручную настраивать каждый новый проект.
Нужно перебрать все существующие в Solution проекты.
Если заняться передвижкой проектов по папкам, то все надо настраивать сначала.

В статье Patrick Smacchia Partitioning Your Code Base Through .NET Assemblies and Visual Studio Projects, где я это подсмотрел, говорится о подходе к ускорению в целом, а не только с использованием метода Copy Local False.