Когда copy-local должен быть установлен в true, а когда нет?

Question

Мне интересно, есть ли какие-нибудь эвристики для того, когда устанавливать copy-local=true для ссылок?

Если ссылочные типы используются только для внутреннего использования, я могу установить copy-local на true, но если ссылочные типы представляются как параметры или возвращаемые значения, я устанавливаю copy-local на false и указываю, что конкретная версия зависимости должна ссылки на мою библиотеку?

Кто-нибудь может уточнить это для меня?

Answer 1

Копировать локально важно для сценариев развертывания и инструментов. Как правило, вы должны использовать CopyLocal = True, если ссылка не содержится в GAC.

Копировать Local по сути означает, что я должен вручную развернуть эту DLL, чтобы мое приложение работало. Когда оно ложно, это, по сути, означает «Я зависим от другого компонента, который должен быть установлен отдельно или соединен, DLL просто будет там».

Answer 2

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

CopyLocal особенно болезнен при построении больших исходных деревьев. Был связанный вопрос о том, как отключить CopyLocal здесь на SO, вы можете увидеть его в Как переопределить параметр CopyLocal (Private) для ссылок в .NET из MSBUILD . А также Лучшие практики для больших решений в Visual Studio (2008).

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

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

Answer 3

Это действительно о целевой среде. Если copy local имеет значение false, вы говорите, что сборка уже будет существовать в целевой среде (обычно в GAC). Если установить значение true, оно будет отображаться в выходных данных вашей сборки, что упрощает развертывание в целевой среде.

Answer 4

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

Проектные ссылки

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

• MainApp.exe
  • MyLibrary.dll
    • ThirdPartyLibrary.dll (если в GAC CopyLocal не будет копироваться в папку bin MainApp)

Это затрудняет развертывание xcopy, если вы не планируете устанавливать стороннюю сборку в GAC на целевой машине.

Answer 5

Эта опция влияет только на фазу сборки. Он просто копирует ссылку на локальный каталог встроенной сборки.

Если другая сборка (T) хочет использовать метод из сборки, которую вы строите (A), который имеет тип возвращаемого значения или параметры из другой ссылочной сборки (R), он (T) должен иметь доступ к этой сборке (R) ). Это может быть в состоянии сделать это, не делая ничего особенного, если указанная сборка (R) установлена ​​в GAC. В противном случае ему нужна локальная копия.

Answer 6

Консервативный способ установить falseLocal Copy состоит в том, чтобы проверить, что ссылка найдена в выходном пути проекта. Это должно позволить вам избежать некоторых неприятных проблем во время выполнения, при этом уменьшая количество операций ввода-вывода.

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

Answer 7

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

Мой опыт установки CopyLocal = false не был успешным. См. За и против в моем сообщении в блоге " НЕ ЗАМЕНЯТЬ" Копировать локальные "ссылки на проект на ложные, если не понимать подпоследовательности ."