Пакет Nuget не копирует собственные библиотеки DLL при сборке - PullRequest
Новая
       17

Пакет Nuget не копирует собственные библиотеки DLL при сборке

1 голос
/ 15 мая 2019

Я пытаюсь создать управляемую библиотеку и упаковать ее с помощью Nuget.Управляемая библиотека использует другую DLL, написанную на C, и выполняет вызовы через вызовы [DllImport] P / Invoke.В корне проекта у меня есть структура папок, такая как:

  • root / runtimes / win-x86 / native / file.dll
  • root / runtimes / win-x64 / native/file.dll

Я не использую файл .nuspec, а вместо этого генерирую пакет Nuget из файла .csproj из проекта .NET STandard 2.0.Я включил эти файлы в файл .csproj. 

<ItemGroup>
    <Content Include="runtimes\**" PackagePath="runtimes" Visible="true" />
</ItemGroup>

Пакет nuget содержит управляемую DLL в каталоге lib / netstandard2.0 и даже содержит неуправляемую DLL в root / runtimes / RID/ родной каталог.Проект, который использует этот пакет nuget, отлично устанавливается и собирается без ошибок.

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

[DllImport("file_name.dll")]
private static extern IntPtr CscanHOpen(string connectionString);
//...
public void Open(string connectionString, int port) {
    _handle = CscanHOpen(connectionString, port);
}

I'mполучение ошибки «файл не найден» из проекта, устанавливающего пакет nuget, и когда я смотрю в каталог сборки, я не вижу там неуправляемой DLL.Я пытался использовать целевой файл для копирования неуправляемой DLL в выходной каталог потребляющего проекта, но он никогда не появляется.

1 Ответ

1 голос
/ 17 мая 2019

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

Функция NuGet runtimes работает только для проектов, использующих ваш пакет.с PackageReference, а не packages.config.На самом деле, несмотря на то, что я работаю в клиентской команде NuGet, на самом деле я не уверен, является ли runtimes функцией проекта в стиле SDK или она также работает с традиционными проектами.Честно говоря, я ожидаю, что он работает только с проектами в стиле SDK, потому что остальная часть системы сборки должна знать, как использовать эти ресурсы.

Поэтому ответ на ваш вопрос - протестировать ваш пакет с SDK-проект стиля.Все приложения .NET Core имеют стиль SDK, но вы также можете отредактировать проект и изменить <TargetFramework>netcoreapp2.2</TargetFramework> на `net48, или сделать множественное число тега xml и значение списка TFM, разделенных точкой с запятой.

Такжеобратите внимание, что библиотеки классов не имеют хоста, следовательно, не имеют RID.Поэтому вы можете не видеть dll во время выполнения.Вам нужно убедиться, что ваш тестовый проект, использующий пакет, имеет нечто вроде хоста и точки входа, например консольное приложение.

Для поддержки packages.config проектов (и, возможно, традиционных проектов, использующих PackageReference), вывам нужно будет связать ваш собственный файл с реквизитами и целями в пакет .Вы сказали, что попробовали, но это не сработало, что, к сожалению, означает, что вы делали это неправильно.NuGet имеет соглашение о том, как вы должны назвать свои файлы реквизита и целей.Если вы поняли это правильно, то способ, которым вы реализовали копирование файлов, не сработал.Вы можете использовать расширенную многословность MSBuild или msbuild -bl в сочетании с MSBuild просмотрщиком структурированных журналов для отладки файла ваших целей.

Использование функции runtimes настолько редко, что я не оченьИмею опыт работы с ним и не знаю, как поддерживать оба традиционных проекта, используя встроенную поддержку runtimes в проектах в стиле SDK.Я предлагаю вам убедиться, что у ваших целей есть условие для выполнения, только когда это не проект в стиле SDK, но я не знаю, как вы это обнаружите.

...