Набор "копировать локально" в false по умолчанию?

на самом деле, вы можете. Вам нужно пару вещей:

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

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

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

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

вы может:

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

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

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

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

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

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

https://nuget.org/packages/CopyLocalFalse

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

начиная с msbuild v 15 вы можете скопировать один файл с именем

Что касается решения, опубликованного @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 ...> вы хотите повлиять, потому что эти блоки будут применяться только к тем ссылкам, которые появляются под ними. Тогда, если есть несколько, что вы do на самом деле хотите быть скопированы локально, вы можете просто переопределить эти назад индивидуально (т. е. в пределах отдельного тега), на этот раз используя True.

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

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

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

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

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

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

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

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

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