Установите значение "Скопировать местное" в значение "Ложно" по умолчанию?

Ответ 1

Нет. Visual Studio использует внутренний набор правил, чтобы определить, что нужно установить для копирования Local в.

От MSDN:

• Если ссылка - это другой проект, называемый ссылкой на проект, то значение true.
• Если сборка найдена в кеше глобальной сборки, значение false.
• В качестве специального случая значение ссылки mscorlib.dll false.
• Если сборка найдена в папке Framework SDK, значение false.
• В противном случае значение true.

Ответ 2

Собственно, ты можешь. Вам нужно пару вещей:

1. Создайте файл .targets который делает copylocal (<Private> tag, если быть точным) false по умолчанию.
2. Импортируйте цель в файлы .csproj. Вы можете добавить его в последнюю строку, прежде чем закрыть </Project>, он будет выглядеть как <Import Project="..\Build\yourtarget.targets"/>.

Теперь каждый проект с этой целью по умолчанию отключил copylocal.

Недостатком является то, что вам нужно изменить каждый файл csproj, включая новые. Вы можете обойти новую проблему проекта, изменив шаблон проекта VS. Вместо Class.cs описанных в статье в блоге, вам нужно изменить Class.vstemplate (в том же zip файле).

При таком подходе возникает еще одна проблема - сам путь. Если вы используете hardcoded относительный путь в вновь созданных файлах csproj, они могут быть неправильными (если у вас нет плоской структуры проекта).

Ты можешь:

• Сделайте VS генерировать правильный относительный путь. Не знаете, как это сделать, и если это возможно.
• Игнорируйте его и измените путь вручную для каждого нового csproj (в зависимости от количества нового проекта, который у вас есть, хотя и не идеальный, что может быть допустимым).
• Используйте переменную окружения вместо относительного пути. В этом случае каждому разработчику понадобится один и тот же набор переменных.

Для этого должно быть лучшее решение, но еще не нашли его.

Ответ 3

Мы не используем файлы .targets(как указано в ответе ya23), поэтому мы просто редактируем файл проекта .csproj вручную в текстовом редакторе и добавляем элемент <Private> к ссылке, например

<Reference Include="[...]">
  <Private>False</Private>
  [...]
</Reference>

Значение элемента <Private> соответствует значению свойства "Копировать локальное". Например, если для параметра <Private> установлено значение False, тогда "Копировать локальное" также неверно.

Ответ 4

Наверное, потому что кажется, что теперь пакет nuget позволяет именно это...

https://nuget.org/packages/CopyLocalFalse

Еще не пробовал, просто надеясь, что это поможет.

Ответ 5

Начиная с msbuild v 15, вы можете скопировать один файл с именем Directory.Build.props в корневую папку, содержащую ваш источник:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
     <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>
</Project>

Больше нечего делать! Это хорошо работает с Visual Studio 2017, а также с vNext Build. Возможно, вам придется закрыть Visual Studio, а затем снова открыть свое решение, чтобы применить эффект файла.

https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-and-directorybuildtargets

Ответ 6

Что касается решения, опубликованного @herzbube, если вы хотите отключить "Копировать локально" для всех (или большинства) ссылок в вашем файле .csproj, вам не нужно отдельно устанавливать <Private>False</Private> Для каждой Reference вы можете просто поместить следующее непосредственно в .csproj:

<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
</ItemDefinitionGroup>

Это не влияет на проекты, на которые ссылается <ProjectReference>, но вы можете сделать то же самое - либо вместо, либо также - для них:

<ItemDefinitionGroup>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>

Если вы хотите оба из них, вы можете объединить их в одну группу:

<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>

Убедитесь, что вы поместили эти переопределения до первого фактического <Reference...> или <ProjectReference...> вы хотите повлиять, потому что эти блоки будут применяться только к тем ссылкам, которые появляются под ними. Тогда, если есть несколько, которые вы на самом деле хотите быть локально скопированы, вы можете просто переопределить их обратно по отдельности (то есть внутри самого индивидуального тега), на этот раз используя True.

В более сложных случаях вы можете переключать переопределяющее значение назад и вперед между True и False несколько раз в одном и том же файле .csproj. Другим продвинутым методом было бы стратегически разместить некоторые из ваших ссылок под этими блоками, а другие выше, чтобы на них не влияли.

Все это должно сделать XML в вашем .csproj намного чище и проще для чтения. Но есть еще больше хороших новостей, так что читайте дальше...

Что касается выбора, какие проекты должны быть помечены как <Private>False</Private> это обычно зависит от конкретной ситуации, но есть кое-что фундаментальное, что каждый может и должен сделать для начинающих. Это такой базовый, простой и эффективный шаг, который обеспечивает такие огромные улучшения надежности MSBuild ^1. и ускорение времени сборки - и с небольшим недостатком - что каждое крупное решение, которое использует стандартные (то есть локальные для проекта) места вывода С# должны почти всегда делать эту корректировку:

В любом решении Visual Studio, которое создает несколько библиотек классов С# с любым нетривиальным числом взаимозависимостей <ProjectReference> и которое завершается созданием еще одного приложения (т.е. исполняемых файлов):

1. В верхней части .csproj для каждой библиотеки классов вставьте блок <ProjectReference> показанный выше.
   ПРИЧИНА: Нет необходимости в том, чтобы какой-либо .dll собирал какие-либо библиотеки, на которые он ссылается, в свой собственный подкаталог, так как из этого расположения никогда не запускался исполняемый файл. Такое безудержное копирование является бесполезной занятой работой и может излишне замедлять вашу сборку, возможно, весьма радикально.

2. С другой стороны, не изменяет .csproj для любого из ваших приложений решений.
   ПРИЧИНА: Исполняемые файлы должны иметь все необходимые частные библиотеки в своих соответствующих подкаталогах, но сборка для каждого отдельного приложения должна отвечать за индивидуальный сбор каждой зависимости непосредственно из соответствующего подкаталога в подкаталог приложения. каталог.

Это прекрасно работает, потому что .csproj для библиотеки классов может ссылаться на несколько других библиотек классов, но .csproj для исполняемого файла обычно никогда не ссылается на другой исполняемый файл. Таким образом, для каждой локально созданной библиотеки единственный .dll в ее папке bin будет сам по себе, тогда как каждое локально созданное приложение будет содержать полный набор локально собранных библиотек, на которые оно ссылается.

Удобно, что ничего не меняется для ссылочных библиотек, которые не созданы вашим решением, так как они обычно используют <Reference> вместо <ProjectReference>, и мы вообще не изменяли прежний тег. Но обратите внимание на только что упомянутое предположение; если он нарушается некоторыми вашими проектами, возможно, вам придется внести некоторые коррективы.

_{[1.] Повышение надежности может быть связано с коллизиями файлов, которые могут возникать при сборе одной и той же библиотеки из нескольких непересекающихся путей в графе зависимостей, особенно в параллельных сборках.}