Почему нативные библиотеки DLL из зависимых библиотек не включены в выходные данные сборки? - PullRequest
Новая
       18

Почему нативные библиотеки DLL из зависимых библиотек не включены в выходные данные сборки?

0 голосов
/ 16 мая 2019

Мы обращаемся к DB2 из C #, используя библиотеки DB2 IBM https://www.nuget.org/packages/IBM.Data.DB2.Core/

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

Проблема в том, что библиотека IBM основана на нативных библиотеках DLL, которые включены в их пакет. Однако эти собственные dll не копируются для создания выходной папки, когда на библиотеку IBM только косвенно ссылаются через нашу собственную библиотеку оболочки DB2

Я подозреваю, что мне нужно включить нативный DLL в нашу собственную библиотеку. Только я не уверен, как это сделать.

Пакет nuget, который мы создаем для нашей библиотеки-оболочки, создается из файла csproj 

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

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <Version>1.0.0</Version>
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="IBM.Data.DB2.Core" Version="1.3.0.100" />
  </ItemGroup>

</Project>

1 Ответ

0 голосов
/ 16 мая 2019

Это сложно. У NuGet есть два способа использования пакетов, и эти два способа работают несколько по-разному. Оригинальный способ был с packages.config (ПК), а новый - PackageReference (PR).

NuGet с ПК не имеет понятия времени выполнения, поэтому они часто используются, и, посмотрев на пакет, кажется, что это тот случай, когда автор пакета связывает реквизиты MSBuild и / или целевые файлы в пакете, и эти цели изменяют сборку для копирования собственных файлов при сборке. В проекте с использованием ПК, когда пакет установлен, все зависимости также установлены, поэтому все пакеты являются прямыми зависимостями проекта, и все цели сборки в пакетах импортируются в проект.

Проекты, использующие NuGet с PR, с другой стороны, могут ссылаться только на свои прямые зависимости, но зависимости пакетов приходят транзитивно. NuGet говорит MSBuild только импортировать цели сборки из прямых зависимостей, а не транзитивных зависимостей. Так что это объясняет поведение, которое вы видите.

В NuGet 5.0 (выпущенной с Visual Studio 2019, и я не могу вспомнить, какие версии .NET Core SDK) мы добавили функцию buildTransitive, которая будет извлекать реквизиты / цели сборки из транзитивных пакетов. Однако для его использования требуется, чтобы автор пакета повторно авторизовал свои пакеты.

...