Зависимая DLL не копируется в выходную папку сборки в Visual Studio

У меня есть визуальное решение для студии. У меня много проектов в решении. Существует один основной проект, который выступает в качестве запуска и использует другие проекты. Есть один проект, скажем "ProjectX". Его ссылка добавлена ​​в основной проект. ProjectX ссылается на другую .NET DLL (скажем, abc.dll), которая не является частью решения.

Теперь эту abc.dll нужно скопировать в папку bin / debug основного проекта, но она там не копируется. Почему это не копируется по каким-либо известным причинам?

Я обнаружил, что если ProjectX ссылается на abc.dll, но напрямую не использует какой-либо из типов DEFINED в abc.dll, то abc.dll НЕ будет скопирован в основную выходную папку. (Это будет скопировано в выходную папку ProjectX, чтобы сделать его более запутанным.)

Итак, если вы явно не используете какой-либо из типов из abc.dll где-либо в ProjectX, поместите фиктивное объявление где-нибудь в один из файлов в ProjectX.

AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied

Вам не нужно делать это для каждого класса - достаточно одного раза, чтобы сделать копию DLL, и все будет работать как положено.

Приложение: Обратите внимание, что это может работать для режима отладки, но НЕ для выпуска. Подробности смотрите в ответе @ nvirth.

Просто знаком с ответом Повелителя Зурга.

Я добавил фиктивную ссылку таким образом, и она работала в режиме отладки:

public class DummyClass
{
    private static void Dummy()
    {
        var dummy = typeof(AbcDll.AnyClass);
    }
}

Но в режиме Release зависимая DLL все равно не была скопирована.
Это сработало однако:

public class DummyClass
{
    private static void Dummy()
    {
        Action<Type> noop = _ => {};
        var dummy = typeof(AbcDll.AnyClass);
        noop(dummy);
    }
}

Эта информация фактически стоила мне часов, чтобы понять, поэтому я решил поделиться ею.

Да, вам нужно установить Copy Localна true. Тем не менее, я почти уверен, что вам также нужно сослаться на эту сборку из основного проекта и установить Copy Localее true- она ​​не просто копируется из зависимой сборки.

Вы можете добраться до Copy Localсобственности, нажав на сборку под Referencesи нажав F4.

Это выглядит гладко, когда вы делаете его атрибутом сборки

[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{        
    public ForceAssemblyReference(Type forcedType)
    {
        //not sure if these two lines are required since 
        //the type is passed to constructor as parameter, 
        //thus effectively being used
        Action<Type> noop = _ => { };
        noop(forcedType);
    }
}

Использование будет:

[assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]

Столкнулся с этой же проблемой. Справочная информация: перед сборкой я добавил новый проект X в решение. Проект Y зависел от проекта X, а проект A, B, C зависел от проекта Y.

Ошибки сборки были в том, что dll проектов A, B, C, Y и X не могли быть найдены.

Основная причина заключалась в том, что недавно созданный Project X был нацелен на .NET 4.5, а остальные проекты решений нацелены на .NET 4.5.1. Проект X не создавался, в результате чего остальные проекты тоже не создавались.

Убедитесь, что все новые добавленные проекты нацелены на ту же версию .NET, что и остальная часть решения.

Не уверен, что это поможет, но для меня, много раз я ссылаюсь на DLL (которая автоматически добавляет ее в папку bin). Однако эта DLL может потребоваться дополнительные библиотеки DLL (в зависимости от того, какие функции я использую). Я НЕ хочу ссылаться на них в моем проекте, потому что они просто должны оказаться в той же папке, что и библиотека, которую я на самом деле использую.

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

Затем измените свойства этого файла на ...

Build Action = None (если этот параметр установлен на что-то вроде Content, фактически копируется «корневая» версия в корень плюс копия в корзине).

Копировать в выходную папку = Копировать, если новее (в основном помещает его в папку BIN, только если он отсутствует, но не делает этого после этого)

Когда я публикую .. мои добавленные DLL существуют только в папке BIN и больше нигде в месте публикации (что я и хочу).

Вы также можете убедиться, что искомые DLL не включены в GAC. Я считаю, что Visual Studio умело не копирует эти файлы, если они уже существуют в GAC на компьютере сборки.

Недавно я столкнулся с такой ситуацией, когда я тестировал пакет служб SSIS, для которого нужны сборки в GAC. С тех пор я забыл об этом и удивлялся, почему эти библиотеки не появлялись во время сборки.

Чтобы проверить, что находится в GAC (из командной строки разработчика Visual Studio):

gacutil -l

Или вывод в файл, чтобы его было легче читать:

gacutil -l > output.txt
notepad.exe output.txt

Чтобы удалить сборку:

gacutil -u MyProjectAssemblyName

Следует также отметить, что после удаления файлов из GAC они правильно выводились в каталог \ bin после сборки (даже для сборок, на которые нет прямой ссылки в корневом проекте). Это было в Visual Studio 2013, обновление 5.

В моем случае это была самая глупая вещь, вызванная поведением TFS / VS по умолчанию, с которым я не согласен.

Поскольку добавление dll в качестве ссылки на основной проект не сработало, я решил добавить его в качестве «Существующего элемента» с Copy Local = Always. Даже тогда файла там не было.

Оказывается, что, хотя файл присутствует в решении VS и все скомпилировано как локально, так и на сервере, VS / TFS фактически не добавлял файл в систему контроля версий. Он не был включен в «Ожидающие изменения» вообще. Мне пришлось вручную перейти в Source Control Explorer и явно нажать на значок «Добавить элементы в папку».

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

Надеюсь, это сэкономит кому-то время, так как я потерял 2 дня своей жизни на это.

Это небольшой твик на примере nvirth

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}

Я бы добавил его в события Postbuild, чтобы скопировать необходимые библиотеки в выходные каталоги. Что-то вроде директории путевых библиотек XCopy

Вы можете найти их в свойствах проекта -> Build Events.

Выпуск:

Обнаружена похожая проблема для библиотеки DLL пакета NuGet (Newtonsoft.json.dll), в которой выходные данные сборки не содержат ссылочную библиотеку DLL. Но сборка идет хорошо.

Fix:

Просматривайте свои проекты в текстовом редакторе и ищите ссылки с тегами в них. Как Истина или Ложь. «Private» - это синоним «Copy Local». Где-то в действиях MSBuild пытается найти зависимости, он находит вашу зависимость где-то еще и решает не копировать ее.

Итак, просмотрите каждый файл .csproj / .vbproj и удалите теги вручную. Перестройте, и все работает как в Visual Studio, так и в MSBuild. Как только у вас это заработает, вы можете вернуться и обновить то, что, по вашему мнению, должно быть.

Ссылка:

https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/

НЕТ НЕОБХОДИМОСТИ манекена КОДА
Just:

добавить ссылку на исполняемый проект

или / и убедитесь, что ссылка в исполняемом проекте "Copy Local"установлена TRUE(что было моей « ошибкой »), похоже, что это «перезаписало» настройку в базовом ссылочном проекте библиотеки ...

Если вы щелкнете правой кнопкой мыши по указанной сборке, вы увидите свойство с именем Copy Local . Если для параметра Копировать локально задано значение true, сборка должна быть включена в корзину. Тем не менее , есть проблемы с Visual Studio, которые иногда не включают DLL-библиотеку, на которую ссылаются, в папке bin ... Это обходной путь, который работал для меня:

TLDR; Visual Studio 2019 может просто потребоваться перезагрузка.

Я столкнулся с этой ситуацией, используя проекты на основе проекта Microsoft.NET.Sdk.

<Project Sdk="Microsoft.NET.Sdk">

В частности:

• Project1: цели .netstandard2.1
  • ссылки Microsoft.Extensions.Logging.Consoleчерез Nuget
• Project2: цели .netstandard2.1
  • ссылки Project1через ссылку проекта
• Project2Tests: цели .netcoreapp3.1
  • ссылки Project2через ссылку проекта

При выполнении теста я получил сообщение об ошибке, указывающее, что Microsoft.Extensions.Logging.Consoleне может быть найдено, и оно действительно не было в выходном каталоге.

Я решил обойти эту проблему, добавив Microsoft.Extensions.Logging.Consoleв Project2, только чтобы обнаружить, что диспетчер Nuget в Visual Studio не выводит список Microsoft.Extensions.Logging.Consoleустановленных в нем Project1, несмотря на то, что он присутствует в Project1.csprojфайле.

Простое завершение работы и перезапуск Visual Studio решили проблему без необходимости добавления дополнительной ссылки. Возможно, это сэкономит кому-то 45 минут потерянной производительности :-)

Вы можете установить как основной проект, так и путь вывода сборки ProjectX в одну и ту же папку, затем вы можете получить все необходимые библиотеки в этой папке.

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

Вы можете проверить это, выбрав свой проект, затем нажмите ALT + ENTER, затем выберите Приложение слева и затем выберите Target Framework вашего проекта.

Предположим, что зависимая целевая платформа dll = 4.0 и целевая платформа приложения dll = 3.5, затем измените ее на 4.0

Спасибо!

Помимо общих вышеупомянутых, у меня было многопроектное решение для публикации. Видимо, некоторые файлы предназначены для разных структур.

Итак, мое решение: Свойства> Конкретная версия (False)

Добавьте DLL как существующий элемент в один из проектов, и он должен быть отсортирован

VS2019 V16.6.3

Для меня проблема заключалась в том, что основной файл .proj заканчивался такой записью для проекта, DLL которого не копировалась в папку bin родительского проекта:

<ProjectReference Include="Project B.csproj">
  <Project>{blah blah}</Project>
  <Name>Project B</Name>
  <Private>True</Private>
</ProjectReference>

Я вручную удалил строку, <Private>True</Private>а затем DLL была скопирована в папку bin основного проекта при каждой сборке основного проекта.

Если вы перейдете к ссылке на проблемный проект в папке ссылок основного проекта, щелкните по ней и просмотрите свойства, там есть параметр «Копировать локальный». Закрытый тег соответствует этому параметру, но для меня по какой-то причине изменение локальной копии не оказало влияния на закрытый тег в файле .proj.

Досадно, что я не изменил локальное значение копии для ссылки, понятия не имею, как он был настроен таким образом, и потратил еще один день на поиск глупой проблемы с VS.

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

НТН