Копирование нативных библиотек в выходную папку

#c_sharp #visual_studio #nuget

Есть решение (solution) с двумя проектами: первый — библиотека, второй — запускаемое
приложение.

Во второй проект добавлена ссылка на первый.

В первый проект добавлен nuget-пакет, в котором есть какие-то нативные библиотеки.

Проблема: при сборке проекта, эти нативные библиотеки не копируются в выходную папку
ВТОРОГО проекта.

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

Как сделать так, чтобы все библиотеки копировались автоматически?
    

Ответы

Ответ 1

Тут есть две проблемы, и первая из них - кривые руки автора пакета. Частенько в подобных
пакетах копирование файлов в выходную папку делается каким-то велосипедом, который,
конечно же, стандартным тулчейном не распознается.

Вам нужно найти внутри nuget-пакета targets-файл, изучить его структуру и написать
свой патч. Стандартную цель придется отключить, и написать свою.

Идея в том, что любой файл, копируемый в выходную папку, должен копироваться стандартным
тулчейном. Для этого требуется "повеситься" на AssignTargetPaths и создать по элементу
ContentWithTargetPath на каждый копируемый файл:



    
        
            PreserveNewest
            foo.dll
        
    



Все элементы, добавленные таким образом, будут копироваться в зависимые проекты (точно
так же, как копируются файлы, отмеченные как CopyToOutputDirectory=PreserveNewest).

Отмечу на всякий случай, что загруженные через nuget файлы редактировать не имеет
смысла, все изменения должны вноситься непосредственно в ваш файл проекта (.csproj).
Подробное описание синтаксиса выходит за рамки ответа, ищите информацию по ключевому
слову "msbuild".



Отдельного упоминания заслуживают пакеты, которые вовсе вместо расширения сборки
при установке просто добавляют команды xcopy в PostBuildEvent.

Эти команды xcopy следует оттуда вычистить, и заменить на особый Target.

Как вариант, вы можете просто добавить все нужные файлы в проект как ссылки - хуже
уже не будет.



Вторая проблема - в транзитивных зависимостях. Если проект А зависит от Б, а Б зависит
от С - то файлы из проекта А не попадут в проект С. Эту проблему MS решать даже не
пытались (более того, у меня есть подозрение что так сделано намеренно - потому что
компилятор C# тоже не поддерживает транзитивные зависимости!).

Проблема возникает из-за того, что цель _SplitProjectReferencesByFileExistence, ответственная
за получение списка зависимых проектов, ожидает элементов, определенных целью AssignProjectConfiguration
- но никогда явно не требует её.

Так давайте это исправим!




Сам я так ни разу не делал, так что всех последствий такого решения не скажу.