Visual studio копировать локально
Обновлено: 02.07.2024
У меня есть несколько файлов dll в папке \ lib папки моего проекта. На странице свойств dll я выбрал «Действие сборки» как «Содержимое» и «Копировать в выходной каталог» как «Всегда копировать».
После сборки я фактически копирую dll, но они находятся внутри \ bin \ Release \ lib, а не в \ bin \ Release.
Есть ли способ скопировать файлы DLL в \ bin \ Release (а не в \ bin \ Release \ lib) без написания сценария после сборки или использования nant и т. Д.?
Вместо <Content> используйте <ContentWithTargetPath> и укажите целевой путь, например:
Обратите внимание, что эта запись может быть не видна в Visual Studio (2012, 2015, 2017), но после добавления вручную в csproj она появится в Visual Studio. Однако целевой путь нельзя будет редактировать через пользовательский интерфейс.
Добавление записи <None> для файла гарантирует, что он по-прежнему отображается в пользовательском интерфейсе Visual Studio.
Сохраните их в $(ProjectDir)\Lib , но добавьте эти файлы "Как ссылка" на корень вашего .csproj. Теперь они будут скопированы в bin \ Debug (или любую другую папку вывода), не будучи в lib.
РЕДАКТИРОВАТЬ: этот ответ был написан еще тогда, когда ContentWithTargetPath не был доступен в версиях VS / MSBuild, которые я использовал. Оставьте этот ответ здесь для людей, которым, возможно, придется использовать более старую версию VS. Пожалуйста, перестаньте это комментировать, мы все знаем, что теперь есть способы получше.
Если ваша основная цель - включить библиотеки DLL, не загромождая корневой каталог проекта, другое решение - переместить библиотеки DLL в отдельный общий проект и добавить его в качестве ссылки в исходный проект.
(Обратите внимание, что этот пост не дает прямого ответа на этот вопрос, поскольку он не сохраняет структуру папок и проекта, но я нашел этот подход полезным, потому что я смог реструктурировать свой проект в моем случае и потому, что я хотел избежать некоторых из Обратные стороны других подходов здесь.)
В первой строке записано целое число,, количество студентов. Последующие строки описывают каждого ученика поверх строк; первая строка содержит имя ученика, а вторая строка - его оценка.
- Щелкните правой кнопкой мыши Solution -> Add -> New Project -> Shared Project
- Добавьте библиотеки DLL в этот проект (в корневой каталог этого проекта, а не в подпапку "lib")
- (Убедитесь, что свойства файла DLL установлены правильно, например Build Action: Content и Copy to Output Directory: Copy Always )
- Щелкните правой кнопкой мыши исходный проект References -> Add Reference -> Shared Projects
- Выберите общий проект, который вы создали ранее
Настройка выглядит так:
Добавьте dll-файлы в качестве ссылки на проект, а по ссылке установите «Копировать локально» в значение true.
Если вам нужно скопировать файлы из каталога Libs в корневую папку VS2017:
В любую другую папку, включая папку Libs (RecursiveDir)
В VisualStudio 2015 кажется, что если библиотеки DLL, которые вы «добавляете со ссылкой», находятся в подпапке того же проекта , они автоматически помещаются в папку, а вывод также помещается в папку как вы видели.
Если библиотеки DLL находятся в другом проекте или каталоге на диске не в подпапке проекта , вы можете «Добавить со ссылкой», и они будут помещены в корневой каталог.
Чтобы добавить сюда мою шляпу, если вы хотите включить весь каталог с контентом и не хотите отслеживать каждый отдельный файл в Visual Studio, вы можете добавить это в свой файл проекта (для меня это .vcxproj проекта UWP C ++):
Обратите внимание, что каталог Content должен находиться в том же каталоге, что и файл проекта , чтобы сохранить структуру каталогов.
Альтернативный метод - просто оставить элементы типа None . В обозревателе решений щелкните те, которые вы хотите развернуть, и установите для свойства Content значение True .
Примечание. Я делал это в VS2019, и все может меняться от версии к версии.
Чтобы это заработало, щелкните свой проект правой кнопкой мыши и выберите «Выгрузить проект». Затем щелкните правой кнопкой мыши выгруженный проект и выберите «Изменить имя_проекта.vcxproj».
В редакторе пройдите до конца файла и вставьте эту цель прямо перед конечным тегом </Project> :
Теперь щелкните правой кнопкой мыши выгруженный проект и выберите «Перезагрузить проект». Выберите, чтобы сохранить и закрыть, если вам будет предложено.
Я также установил OutputDirectory на:
И IntermediateDirectory для:
На странице "Общие свойства проекта". Это помещает выходные данные в папку «bin», а промежуточные продукты - в папку «obj» в корне вашего решения.
Примечание. $(SolutionDir) не определяется при запуске MSBuild из командной строки. Есть уловка, которую вы можете использовать, чтобы определить это для папки, в которой находится файл .sln, с помощью GetDirectoryNameOfFileAbove. (оставлено в качестве упражнения для читателя). Кроме того, похоже, что в 2019 году они все равно правильно обрабатывают это в командной строке. Да :) $(SolutionDir) содержит обратную косую черту в конце, поэтому после нее нет ни одной. Результат каждого должен иметь обратную косую черту в конце.
Теперь, если у вас есть версия Pro или выше, пожалуйста, не делайте этого каждый раз, когда вам нужно создать проект. Это было бы глупо. Вместо этого, когда ваш проект настроен так, как вам нравится, выберите Project -> Export Template . Вы даете ему имя, и в следующий раз, когда вы захотите создать такой же проект, просто выберите это имя в диалоговом окне «Новый проект». (В более старой версии, я думаю, это было Files -> Export Teamplate. .)
Что касается вашего вопроса, в Visual Studio 2019 у меня сработали следующие шаги:
В редакторе Visual Studio для вашей dll установите для параметра «Действие при сборке» значение «Содержимое» (это может быть необязательно), а для параметра «Копировать в выходной каталог» - значение «Не копировать ".
Затем в файле проекта csproj будет сгенерировано следующее:
Вместо этого измените запись на следующее:
Вы можете установить для параметра CopyToOutputDirectory в файле проекта csproj вручную значение «Всегда» или "PreserveNewest" .
В редакторе Visual Studio для файла «Копировать в выходной каталог» по-прежнему будет отображаться значение «Не копировать» , но файл будет скопирован в корневой выходной каталог. каталог при восстановлении .
Вышеупомянутое изменение не требуется, если вы не хотите копировать файл в корневой выходной каталог, поэтому в этом случае вы можете просто вручную удалить указанное выше изменение в файле csproj проекта, чтобы вернуться к поведению без копирования.
Общие файлы .dll можно поместить в подпапку (как упоминалось выше "\ lib") и в свойствах выбрать:
- Build Action = "HelpFiles"
- Копировать в OutputDirectory = "Если новее"
У меня это сработало именно так, как я хотел - во время сборки .DLL копируются в выходной каталог без подпапки "\ lib".
могу ли я установить параметр по умолчанию "копировать локальный" в Visual Studio в False? В большинстве случаев, когда я добавляю dll как зависимость проекта, Я хочу, чтобы свойство Copy Local имело значение False. По умолчанию, это правда. Есть ли способ изменить поведение Visual Studio по умолчанию? (2008)
No-Visual Studio использует внутренний набор правил для определения того, что нужно установить для локального копирования.
- если ссылка является другим проектом, называемым ссылкой проект-проект, то значение true.
- если сборка находится в глобальном кэше сборок, то значение false.
- в частном случае значение для mscorlib.ссылка dll false.
- если сборка находится в папке Framework SDK, то значение false.
- в противном случае-значение true.
на самом деле, вы можете. Вам нужно пару вещей:
- создать .targets файл, который делает copylocal ( <Private> тег, если быть точным)false по умолчанию.
- импортировать в .csproj файлы. Вы можете добавить его в самую последнюю строку, перед закрытием </Project> - тег, это будет выглядеть как <Import Project="..\Build\yourtarget.targets" /> .
теперь каждый проект с этой целью имеет copylocal отключен по умолчанию.
недостатком является то, что вам нужно изменить каждый и каждый файл csproj, включая новые. Вы можете обойти новую проблему проекта с помощью изменение шаблона проекта VS. Вместо Class.cs описано в статье блога, вам нужно изменить Class.vstemplate (в том же zip-файле).
при таком подходе есть еще одна проблема-сам путь. Если вы используете жестко закодированный относительный путь во вновь созданных файлах csproj, они могут быть неправильными (если у вас нет плоской структуры проекта).
- Make VS генерирует правильный относительный путь. Не знаю, как это сделать и возможно ли это вообще.
- проигнорируйте его и измените путь вручную для каждого нового csproj (в зависимости от количества новых проектов, которые у вас есть, хотя и не идеальны, это может быть терпимо).
- используйте переменную окружения вместо относительного пути. В этом случае каждому разработчику потребуется один и тот же набор переменных.
там должно быть лучшее решение для этого, но пока не нашел.
мы не используем .целевые файлы (как предложено в ответе ya23), поэтому мы просто редактируем .csproj файл проекта вручную в текстовом редакторе и добавьте <Private> элемент ссылки, например:
значение <Private> элемент соответствует значению свойства" копировать локальный". Например, если <Private> имеет значение False, затем" копировать локальный " также false..
натыкаясь на это, потому что кажется, что теперь есть пакет nuget, позволяющий именно это.
еще не пробовал, просто надеюсь, что это поможет.
начиная с msbuild v 15 вы можете скопировать один файл с именем
Что касается решения, опубликованного @herzbube, если вы хотите отключить "копировать локальный" для всех (или большинства) ссылок в вашем .csproj файл файл, вам не нужно устанавливать <Private>False</Private> индивидуально на каждого Reference , вы можете просто поместить следующее непосредственно в .csproj файл:
это не влияет на проекты, на которые ссылается <ProjectReference> , но вы можете сделать то же самое-вместо или, а также-для тех, кто:
если вы хотите оба из них вы можете объединить в одну группу:
убедитесь, что вы поставили эти переопределения до первого фактического <Reference . > или <ProjectReference . > вы хотите повлиять, потому что эти блоки будут применяться только к тем ссылкам, которые появляются под ними. Тогда, если есть несколько, что вы do на самом деле хотите быть скопированы локально, вы можете просто переопределить эти назад индивидуально (т. е. в пределах отдельного тега), на этот раз используя True .
для более сложных случаев вы можете переключать переопределяющее значение между правда и False несколько раз в одном и том же .файл csproj. Другой передовой метод-стратегически разместить некоторые из ваших ссылок ниже этих блоков, а другие выше, чтобы последние не пострадали.
вверху .csproj файл для каждого библиотека классов вставить <ProjectReference> блок показано выше.
Причина: нет необходимости в каких-либо .dll файлы чтобы собрать любую из библиотек, на которые он ссылается, в собственный подкаталог, так как исполняемый файл никогда не запускается из этого местоположения. Такое безудержное копирование бесполезно и может излишне замедлить вашу сборку, возможно, довольно резко.С другой стороны, делать не изменить .csproj для любого из ваших решений приложения.
Причина: исполняемые файлы должны иметь все частные библиотеки, необходимые им в соответствующих подкаталогах, но сборка для каждого приложения должна отвечать за индивидуальный сбор каждой зависимости непосредственно из соответствующего подкаталога в подкаталог приложения.
это работает прекрасно ведь .csproj для библиотеки классов может ссылаться на несколько других библиотек классов, но .csproj для исполняемого файла обычно никогда не ссылается на другой исполняемый файл. Таким образом, для каждой локально построенной библиотеки единственное .dll файлы в своем bin папка будет сама по себе, тогда как каждое локально построенное приложение будет содержать полный набор локально построенных библиотек, на которые оно ссылается.
удобно, ничего не меняется для ссылочных библиотек, которые не построены ваше решение, так как они обычно используют <Reference> вместо <ProjectReference> , и мы вообще не изменили прежний тег. Но обратите внимание на только что упомянутое предположение; если оно нарушается некоторыми из ваших проектов, вам может потребоваться внести некоторые коррективы.
[1.] Повышение надежности может быть связано с коллизиями файлов, которые могут возникать при сборе одной и той же библиотеки из нескольких непересекающихся путей в графе зависимостей, особенно в параллельных сборках.
Я добавил elmah.ДЛЛ ссылка MyBaseProject в Visual studio 2008 по нажмите кнопку " Добавить ссылку. "→Вкладка" Обзор "→ выбор " elmah.файл DLL."
свойства ссылки Elmah являются следующими:
на MyWebProject1 я добавил ссылку на проект MyBaseProject по: - Добавить ссылку. "→Вкладка" проекты "→ выбор"MyBaseProject". Свойства этой ссылки одинаковы, за исключением следующих элементов:
- описание -
- путь - D:websCMSMyBaseProjectbinDebugMyBaseProject.dll файлы
- версия - 1.0.0.0
Если я запускаю сборку в Visual Studio в elmah.dll-файл копируется в my бункер MyWebProject1 каталог, вместе с MyBaseProject.dll файлы!
Я уже убедился, что .csproj MyBaseProject содержит частная элемент со значением "true" (это должен быть псевдоним для"копировать локально " в Visual Studio):
(частный тег не появился в.xml csproj по умолчанию, хотя Visual Studio сказал" копировать локальный " true. Я переключился " копировать local " в false-saved - и снова установите его в true-save!)
Что случилось с MSBuild? Как мне получить (elmah.dll) ссылка скопирована в корзину MyWebProject1?
Я не хочу добавлять действие postbuild copy в команду postbuild каждого проекта! (Представляю, я бы многие проекты зависят от MyBaseProject!)
Я не уверен, почему это отличается при построении между Visual Studio и MsBuild, но вот что я нашел, когда я столкнулся с этой проблемой в MsBuild и Visual Studio.
объяснение
для примера сценария предположим, что у нас есть проект X, сборка A и сборка B. сборка a ссылается на сборку B, поэтому проект X включает ссылку как на A, так и на B. Кроме того, проект X включает код, который ссылается на сборку A (например, A. SomeFunction()). Теперь вы создаете новый проект Y, который ссылается на проект X.
таким образом, цепочка зависимостей выглядит следующим образом:Y => X => A => B
Visual Studio / MSBuild пытается быть умным и только переносить ссылки в проект Y, который он обнаруживает как требуемый проектом X; он делает это, чтобы избежать загрязнения ссылок в проекте Y. проблема в том, что проект X фактически не содержит никакого кода, который явно использует сборку B (например, B. SomeFunction ()), VS / MSBuild не обнаруживает, что B требуется X и, следовательно, не копирует его в каталог bin проекта Y; он копирует только сборки X и A.
решение
у вас есть два варианта решения этой проблемы, оба из которых приведут к копированию сборки B в каталог bin проекта Y:
- добавить ссылку на сборку B в проекте Y.
- добавить фиктивный код в файл в проекте X, который использует сборку B.
лично я предпочитаю вариант 2 пару причин.
- если в будущем вы добавите еще один проект, ссылающийся на проект X, вам не нужно будет также включать ссылку на сборку B (например, вы должны были бы сделать с вариантом 1).
- вы можете иметь явные комментарии, говорящие, почему фиктивный код должен быть там, а не удалять его. Поэтому, если кто-то случайно удаляет код (скажем, с помощью инструмента рефакторинга, который ищет неиспользуемый код), вы можете легко увидеть из системы управления версиями, что код требуется и восстановить его. Если вы используете опцию 1, а кто-то использует инструмент рефакторинга для очистки неиспользуемых ссылок, у вас нет комментариев; вы просто увидите, что ссылка была удалена из .файл csproj.
вот пример "фиктивного кода", который я обычно добавляю, когда сталкиваюсь с этой ситуацией.
Я просто справляюсь с этим так. Перейдите к свойствам вашей ссылки и сделайте следующее:
Visual Studio 2010 изначально не помещается: <private>True</private> в теге ссылки и установка "копировать локальный" в false заставляет его создавать тег. После этого установите его в true и false соответственно.
Если сборка не используется непосредственно в коде, Visual Studio при попытке быть полезной обнаруживает, что она не используется и не включает ее в выходные данные. Я не уверен, почему вы видите различное поведение между Visual Studio и MSBuild. Вы можете попробовать установить вывод сборки для диагностики для обоих и сравнить результаты, чтобы увидеть, где он расходится.
что касается вашего elmah.dll ссылка Если вы не ссылаетесь на него непосредственно в коде, вы можете добавить его в качестве элемента ваш проект и установите действие сборки в Content и копировать в выходной каталог значение Always .
вы найдете мое временное решение / обходное решение есть!
(MyBaseProject нуждается в некотором коде, который ссылается на некоторые классы (независимо) от elmah.dll для elmah.dll копируется в корзину MyWebProject1!)
У меня была та же проблема.
Проверьте, совпадает ли версия фреймворка вашего проекта с версией фреймворка dll, которую вы помещаете в ссылку.
в моем случае мой клиент был скомпилирован с помощью "Framework 4 Client", а DLL-в"Framework 4".
проблема, с которой я столкнулся, заключалась в том, что у меня есть проект, который зависит от проекта библиотеки. Для того, чтобы построить мне следующее:
это, конечно, означало, что мне не хватало dll-файлов моей библиотеки в bin и, самое главное, в zip-файле пакета. Я нашел, что это работает отлично:
Я понятия не имею, почему эта работа или почему это не было в первую очередь. Но надеюсь, это поможет.
как Алекс Бурцев упомянул в комментарии все, что используется только в словаре ресурсов XAML, или в моем случае все, что используется только в XAML, а не в коде позади, не считается "используемым" MSBuild.
таким образом, просто создание фиктивной ссылки на класс / компонент в сборке в некотором коде позади было достаточно, чтобы убедить MSBuild, что сборка фактически используется.
У меня была точно такая же проблема, и это оказалось вызвано тем, что 2 проекта в одном решении ссылались на другую версию библиотеки 3rd party.
Как только я исправил все ссылки, все работало отлично.
У меня была та же проблема, и dll была динамически загруженной ссылкой. Чтобы решить проблему, я добавил "Использование" с пространством имен dll. Теперь dll копируется в выходную папку.
для этого необходимо добавить .targets файл для вашего проекта и установка его для включения в раздел проекта включает.
посмотреть мой ответ здесь для процедуры.
ссылка на сборки, которые не используются во время сборки, не является правильной практикой. Вы должны увеличить файл сборки, чтобы он копировал дополнительные файлы. Либо с помощью события post build, либо путем обновления группы свойств.
некоторые примеры можно найти в другом посте
используя схему deadlydog,
Y => X => A => B,
моя проблема заключалась в том, что когда я построил Y, сборки (A и B, все 15 из них) из X не отображались в папке bin Y.
Я решил это, удалив ссылку X из Y, сохранить, построить, а затем повторно добавить ссылку X (ссылку на проект), и сохранить, построить, и A и B начали появляться в папке bin Y.
другой сценарий, где это появляется, если вы используете более старый тип проекта "веб-сайт" в Visual Studio. Для этого типа проекта, он не может ссылаться .DLL, которые находятся вне собственной структуры каталогов (текущая папка и вниз). Итак, в приведенном выше ответе предположим, что ваша структура каталогов выглядит следующим образом:
где ProjectX и ProjectY являются родительскими / дочерними каталогами и ссылками на ProjectX A.dll который в свою очередь ссылки B.dll, и B.dll находится вне структуры каталогов, например, в пакете Nuget в корне (пакеты), затем A.dll будут включены, но B.dll не будет.
Я только что столкнулся с очень похожей проблемой. При компиляции с помощью Visual Studio 2010 файл DLL был включен в . Но при компиляции с использованием MSBuild сторонний DLL-файл не был включен.
очень неприятно. Кстати я решил включить сюда NuGet для ссылка на пакет в моем веб-проекте, даже если я не использую его непосредственно там.
сегодня у меня была аналогичная проблема, и это, безусловно, не ответ на ваш вопрос. Но я хотел бы проинформировать всех и, возможно, дать искру понимания.
у меня есть два Дженкинс CI скрипты. Для производства и для постановки. Я развернул свое приложение в staging, и все работало нормально. Развернут в производство и отсутствовал DLL-файл, на который была ссылка. Этот DLL-файл был только в корне проекта. Ни в одном хранилище NuGet. DLL была установлена в do not copy .
оказывается, в тестовой ветви я добавил шаг к процессу сборки, чтобы скопировать этот файл DLL в
включение всех ссылочных DLL-файлов из вашего проекта projectreferences в проект веб-сайта не всегда является хорошей идеей, особенно когда вы используете инъекции зависимостей: ваш веб-проект просто хочет добавить ссылку на файл/проект DLL интерфейса, а не какой-либо конкретный файл DLL реализации.
потому что, если вы добавляете ссылку непосредственно на DLL-файл/проект реализации, вы не можете запретить разработчику вызывать "новый" для конкретных классов реализация DLL-файла / проекта вместо интерфейса. Кроме того, вы указали "жесткий код" на своем веб-сайте для использования реализации.
Могу ли я установить для параметра по умолчанию «Копировать локально» в Visual Studio значение False? В большинстве случаев, когда я добавляю dll в качестве зависимости проекта, я хочу, чтобы для свойства Copy Local было установлено значение False. По умолчанию это True. Есть ли способ изменить поведение Visual Studio по умолчанию? (2008)
Нет - Visual Studio использует внутренний набор правил, чтобы определить, для чего нужно установить локальное копирование.
- Если ссылка представляет собой другой проект, называемый ссылкой проекта на проект, то значение равно true .
- Если сборка найдена в глобальном кэше сборок, значение равно false .
- В качестве особого случая ссылка на mscorlib.dll имеет значение false .
- Если сборка найдена в папке SDK Framework, значение равно false .
- В противном случае используется значение true .
Собственно, можете. Вам понадобится пара вещей:
- Создайте файл .targets , который делает copylocal (если быть точным, тег <Private> ) по умолчанию false.
- Импортируйте цель в файлы .csproj . Вы можете добавить его в самую последнюю строку, перед закрытием тега </Project> он будет выглядеть как <Import Project="..\Build\yourtarget.targets" /> .
Теперь для каждого проекта с этой целью copylocal по умолчанию отключен.
Недостатком является то, что вам нужно изменить каждый файл csproj, включая новые. Вы можете обойти новую проблему проекта с помощью изменение шаблона проекта VS. Вместо Class.cs , описанного в статье блога, вам необходимо изменить Class.vstemplate (в том же zip-файле).
При таком подходе возникает еще одна проблема - сам путь. Если вы используете жестко заданный относительный путь во вновь созданных файлах csproj, они могут быть неправильными (если у вас нет плоской структуры проекта).
- Заставить VS генерировать правильный относительный путь. Не знаю, как это сделать и возможно ли это.
- Игнорируйте это и вручную меняйте путь для каждого нового csproj (в зависимости от количества новых проектов, которые у вас есть, хотя и не идеально, но это может быть терпимо).
- Используйте переменную среды вместо относительного пути. В этом случае каждому разработчику потребуется один и тот же набор переменных.
Для этого должно быть лучшее решение, но пока не нашел.
Начиная с msbuild v 15 вы можете скопировать один файл с именем Directory.Build.props в корневую папку, содержащую ваш исходный код:
Больше нечего делать! Это хорошо работает с Visual Studio 2017, а также с vNext Build. Возможно, вам придется закрыть Visual Studio, а затем снова открыть решение, чтобы применить эффект файла.
Мы не используем файлы .targets (как было предложено в ответе ya23), поэтому мы просто редактируем файл проекта .csproj вручную в текстовом редакторе и добавляем элемент <Private> в ссылку, например это:
Значение элемента <Private> соответствует значению свойства «Копировать локальное». Например, если для <Private> задано значение "Ложь", то "Копировать локально" также будет неверно.
Удар, потому что кажется, что теперь есть пакет nuget, позволяющий именно это .
Еще не пробовал, просто надеюсь, что это поможет.
Что касается решения, опубликованного @herzbube, если вы хотите отключить "Копировать локально" для всех (или большинства) ссылок в вашем файле .csproj , вам не нужно устанавливать <Private>False</Private> индивидуально для каждого Reference , вы можете просто поместить следующее прямо в .csproj :
Это не влияет на проекты, на которые ссылается <ProjectReference> , но вы можете сделать то же самое - либо вместо этого, либо также - для тех:
Если вам нужны оба варианта, вы можете объединить их в одну группу:
Убедитесь, что вы поместили эти переопределения до первых фактических <Reference . > или <ProjectReference . > , на которые вы хотите повлиять, потому что эти блоки будут применяться только к тем ссылкам, которые появляются под ними. Затем, если есть несколько из них, которые вы True .
В более сложных случаях можно несколько раз переключать значение переопределения между True и False в одном и том же файле .csproj. Другой продвинутый метод - стратегически разместить одни из ваших ссылок под этими блоками, а другие - над ними, чтобы последние не пострадали.
Вверху .csproj для каждой библиотеки классов вставьте блок <ProjectReference> , показанный выше.
ПРИЧИНА: никакой .dll не нужно собирать какие-либо библиотеки, на которые она ссылается, в собственный подкаталог, поскольку ни один исполняемый файл никогда не запускается из этого места. Такое безудержное копирование является бесполезным занятием и может излишне замедлять вашу сборку, а возможно, и весьма значительно.С другой стороны, не ПРИЧИНА: исполняемые файлы должны иметь все необходимые им частными библиотеками в соответствующих подкаталогах, но сборка для каждого приложения должна отвечать за индивидуальный сбор каждой зависимости непосредственно из соответствующего подкаталога в подкаталог приложения. каталог.
Это отлично работает, потому что .csproj для библиотеки классов может ссылаться на несколько других библиотек классов, но .csproj для исполняемого файла обычно никогда не ссылается на другой исполняемый файл. Таким образом, для каждой локально созданной библиотеки единственной .dll в ее папке bin будет она сама, тогда как каждое локально созданное приложение будет содержать полный набор локальных библиотек, на которые он ссылается.
Для удобства ничего не меняется для библиотек, на которые имеются ссылки, которые не созданы вашим решением, поскольку они обычно используют <Reference> вместо <ProjectReference> , а мы вообще не изменяли первый тег. Но обратите внимание на только что упомянутое предположение; если он нарушается некоторыми вашими проектами, вам может потребоваться внести некоторые коррективы.
[1.] Повышение надежности может быть связано с конфликтами файлов, которые могут возникнуть при сборе одной и той же библиотеки из нескольких непересекающихся путей в графе зависимостей, особенно в параллельных сборках.
Читайте также: