Какова наилучшая практика для «Копировать локальный» и со ссылками на проект?

Question

У меня большой файл решения c # (~ 100 проектов), и я пытаюсь сократить время сборки. Я думаю, что «Копировать Локальный» во многих случаях для нас бесполезен, но меня интересуют лучшие практики.

В нашем .sln у нас есть приложение A, зависящее от сборки B, которое зависит от сборки C. В нашем случае есть десятки «B» и несколько «C». Поскольку все они включены в .sln, мы используем ссылки на проекты. Все сборки в настоящее время встроены в $ (SolutionDir) / Debug (или Release).

По умолчанию Visual Studio помечает эти ссылки на проекты как «Копировать локально», что приводит к тому, что каждый «C» копируется в $ (SolutionDir) / Debug один раз для каждого «B», который собирается. Это кажется расточительным. Что может пойти не так, если я просто отключу «Копировать локальный»? Что делают другие люди с большими системами?

Followup:

Множество ответов предлагают разбить сборку на более мелкие файлы .sln ... В приведенном выше примере я сначала собрал бы базовые классы "C", а затем большую часть модулей "B", а затем несколько приложения, «А». В этой модели мне нужно иметь не-проектные ссылки на C из B. Проблема, с которой я сталкиваюсь, заключается в том, что «Debug» или «Release» запекаются на пути подсказки, и я заканчиваю сборку выпусков сборки «B» против отладочных сборок "C".

Как справиться с этой проблемой для тех из вас, кто разбил сборку на несколько файлов .sln?

Answer 1

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

<developmentMode developerInstallation="true" />

в файл machine.config на каждой рабочей станции разработчика. Единственное, что вам нужно сделать, это скопировать любую новую версию в вашу папку, куда указывает переменная DEVPATH.

Также разделите ваше решение на несколько небольших решений, если это возможно.

Answer 2

Возможно, это не лучшая практика, но так я работаю.

Я заметил, что Managed C ++ выгружает все свои двоичные файлы в $ (SolutionDir) / 'DebugOrRelease'. Таким образом, я также выбросил все свои проекты на C #. Я также отключил «Копировать локальные» всех ссылок на проекты в решении. У меня было заметное улучшение времени сборки в моем маленьком 10 проектном решении. Это решение представляет собой смесь C #, управляемого C ++, нативного C ++, C # webservice и проектов установщика.

Может быть, что-то сломано, но так как я работаю только так, я не замечаю этого.

Было бы интересно узнать, что я ломаю.

Answer 3

Я склонен создавать общий каталог (например, \ bin), поэтому я могу создавать небольшие тестовые решения.

Answer 4

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

• c: \ папка решений \ bin -> ramdisk r: \ папка решений \ bin \

• c: \ папка решения \ obj -> виртуальный диск r: \ папка решения \ obj \

• Вы также можете дополнительно указать Visual Studio, какой временный каталог он может использовать для сборки.

На самом деле это было не все, что было сделано. Но это действительно поразило мое понимание производительности.
100% использование процессора и огромный проект за 3 минуты со всеми зависимостями.

Answer 5

Если ссылка не содержится в GAC, мы должны установить для параметра Local Local значение true, чтобы приложение работало. Если мы уверены, что ссылка будет предварительно установлена ​​в GAC, тогда для нее можно установить значение false.

Answer 6

Обычно вам нужно только копировать локально, если вы хотите, чтобы ваш проект использовал библиотеку DLL, которая находится в вашей корзине, и то, что находится где-то еще (GAC, другие проекты и т. Д.)

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

Вы также можете использовать Configuration Manager для создания различных конфигураций сборки в рамках одного решения, которое будет создавать только определенные наборы проектов.

Было бы странно, если бы все 100 проектов опирались друг на друга, поэтому вы можете разбить его или использовать Configuration Manager, чтобы помочь себе.

Answer 7

Если вы хотите иметь центральное место для ссылки на библиотеку DLL, используя локальное копирование, произойдет сбой без GAC, если вы не сделаете это.

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

Answer 8

У вас могут быть ссылки на ваши проекты, указывающие на отладочные версии dll. Чем в вашем сценарии msbuild, вы можете установить /p:Configuration=Release, таким образом, у вас будет версия выпуска вашего приложения и всех спутниковых сборок.