Что касается решения, опубликованного @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 ...>, на который вы хотите повлиять, потому что эти блоки будут применяться только к тем ссылкам, которые появляются под ними. Затем, если есть некоторые из них, которые вы делаете на самом деле хотите скопировать локально, вы можете просто переопределить эти back индивидуально (т.е. внутри самого отдельного тега ), на этот раз используя True.
Для более сложных случаев вы можете переключать значение переопределения вперед и назад между True и False несколько раз в одном и том же файле .csproj. Другим продвинутым методом было бы стратегически разместить некоторые из ваших ссылок под этими блоками, а другие выше, чтобы на них не влияли.
Все это должно сделать XML в вашем .csproj намного чище и легче для чтения. Но есть и другие хорошие новости, так что читайте дальше ...
Что касается выбора, какие проекты должны быть отмечены <Private>False</Private>, это обычно зависит от конкретной ситуации, но есть что-то фундаментальное каждый может и должен сделать для начинающих. Это настолько простой, простой и эффективный шаг, который обеспечивает такие огромные MSBuild улучшения надежности 1. и ускорение во время сборки - и с небольшими недостатками - что каждое крупное решение, которое использует по умолчанию (т. е. локальный для проекта) C # выходные местоположения почти всегда должны делать эту настройку:
В любом решении Visual Studio, которое создает несколько библиотек классов C # с любым нетривиальным числом <ProjectReference> взаимозависимостей и которое завершается созданием еще одного приложений (т.е. исполняемые файлы):
В верхней части .csproj для каждой библиотеки классов , вставьте блок <ProjectReference>, показанный выше.
ПРИЧИНА: Нет необходимости для .dll собирать какие-либо библиотеки, на которые он ссылается, в свой собственный подкаталог, поскольку из этого расположения никогда не запускается ни один исполняемый файл. Такое безудержное копирование является бесполезной занятой работой и может излишне замедлять вашу сборку, возможно, весьма радикально.
С другой стороны, не измените .csproj для любого из приложений вашего решения .
ПРИЧИНА: Исполняемые файлы должны иметь все необходимые частные библиотеки в своих соответствующих подкаталогах, но сборка для каждого отдельного приложения должна отвечать за индивидуальный сбор каждой зависимости непосредственно из соответствующего подкаталога в подкаталог приложения. каталог.
Это прекрасно работает, потому что .csproj для библиотеки классов может ссылаться на несколько других библиотек классов, но .csproj для исполняемого файла обычно никогда не ссылается на другой исполняемый файл. Таким образом, для каждой локальной библиотеки только .dll в ее папке bin будет сам по себе, тогда как каждое локально созданное приложение будет содержать полный набор локально собранных библиотек, на которые оно ссылается.
Удобно, что ничего не меняется для ссылочных библиотек, которые не созданы вашим решением, так как они обычно используют <Reference> вместо <ProjectReference>, и мы вообще не изменяли прежний тег. Но обратите внимание на только что упомянутое предположение; если он нарушается некоторыми вашими проектами, возможно, вам придется внести некоторые коррективы.
[1.] Повышение надежности может быть связано с коллизиями файлов, которые могут возникать при сборе одной и той же библиотеки из нескольких непересекающихся путей в графе зависимостей, особенно в параллельных сборках.