NuGet: ссылки на сборки в папке времени выполнения не добавлены

Question

У меня есть проект, нацеленный на две разные операционные системы / платформы:

1. net461 в Windows и
2. netcoreapp2.0 в OSX

Я пытаюсь выяснить, как правильно упаковать это для NuGet.Согласно этой записи я должен иметь возможность упаковать их следующим образом:

/runtimes/win/lib/net461/myassembly.dll
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll

Когда я добавляю пакет NuGet в другой проект, упакованные сборки не добавляются как ссылки нацелевой проект.

Затем я где-то прочитал, что вам также необходимо добавить справочные библиотеки в папку /ref, поэтому я попытался это сделать:

/runtimes/win/lib/net461/myassembly.dll
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll
/ref/net461/myassembly.dll
/ref/netcoreapp2.0/myassembly.dll

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

Документация по всему этому крайне расплывчата, и я довольно потерян.

Что мне не хватает?

---

Связанная проблема NuGet: https://github.com/NuGet/Home/issues/7316

---

Обновление: я собрал пример проекта , который демонстрируетчего я пытаюсь достичьВ частности, смотрите нижнюю часть файла readme под названием «Упаковка NuGet».

Answer 1

Я пытаюсь решить ту же проблему.Предложенное вами решение отлично работает, но есть один вопрос ... Случай с Win и net46 понятен.А теперь мне нужно добавить ссылку на сборку в проекте для netcoreapp для Win и для Linux.Проблема в том, что это РАЗЛИЧНАЯ сборка с ЖЕ именем.Те, что мой пакет выглядит следующим образом:

/lib/net461/myassembly1.dll                       (net461/Windows Compile and Runtime)
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll   (netcore/Ubuntu Runtime)
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll   (netcore/Win Runtime)
/ref/netcoreapp2.0/???

Обновление: На самом деле, myassembly1.dll и myassembly2.dll оба называются myassembly.dll.Но чтобы показать, что один собран для Windows, а второй для Linux, я оставлю здесь такое имя.

Самое интересное, что я попытался поместить любую сборку в папку ref, и этоработает как на Windows, так и на Linux.Эта версия работает на обеих системах

/lib/net461/myassembly1.dll   
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll 
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll  
/ref/netcoreapp2.0/myassembly1.dll

И это тоже

/lib/net461/myassembly1.dll   
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll 
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll  
/ref/netcoreapp2.0/myassembly2.dll

Но я думаю, что это неправильно, и я где-то был не прав.

Answer 2

Это то, что я наконец-то понял / догадался (потому что, насколько я могу судить, для некоторых из них нет официальной документации)

• Файлы, добавляемые в папку / runtime, не автоматическидобавлены как ссылки на целевой проект.
• Папки / ref и / runtime следует использовать вместе друг с другом и только для цели .NET Core.Насколько я могу, цели .NET Framework, очевидно, не поддерживают эти папки.
• Папка / ref предназначена для ссылок на время компиляции, и все, что здесь добавлено, будет добавлено как ссылка на целевой проект.
• Сборки в папке / ref не должны иметь реализацию - каждый публичный API может просто генерировать не реализованное исключение.Однако на практике вы обычно просто берете копию одной из сборок реализации и объявляете ее как API времени компиляции.
• Я прочитал (но сам не проверял), что сборки в папке / ref должныбыть "Любой процессор" строит.При необходимости вы можете использовать утилиту CorFlags для исправления сборки реализации.
• Папка / runtimes используется для предоставления сборок реализации для любых ссылок, включенных в папку / ref.Эти сборки используются во время выполнения и во время развертывания.
• Папка / runtimes может содержать дополнительные сборки, которые требуются только во время выполнения и не должны просматриваться клиентским проектом.Эти дополнительные сборки не будут включены в качестве ссылок в целевой проект, но будут доступны для запуска / развертывания.
• Как упоминалось другими, файлы в папке / runtime не копируются в выходную папкусборка.Вместо этого там находятся файлы конфигурации, которые сообщают среде выполнения, как найти файлы / runtimes из кэша NuGet.
• Для целей .NET Framework (т. Е. Net461) просто используйте папку / lib, поскольку других сред выполнения дляВ любом случае .NET помимо Windows.

Собирая все это вместе, мой оригинальный пример должен был выглядеть так:

/lib/net461/myassembly.dll                       (net461/Windows Compile and Runtime)
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll   (netcore/OSX Runtime)
/runtimes/win/lib/netcoreapp2.0/myassembly.dll   (netcore/Win Runtime)
/ref/netcoreapp2.0/myassembly.dll                (netcore/* Compile Time)

Answer 3

.NET Core и .NETSTANDARD не копируют зависимости в выходной каталог, они отображаются с помощью deps.json, который указывает на относительные пути из локального кэша NuGet.

Answer 4

Вы используете новый формат csproj?В этом случае встроенная поддержка нескольких целевых структур.

Например, запуск dotnet pack для файла .csproj с таким содержимым:

<Project Sdk="Microsoft.NET.Sdk">    
  <PropertyGroup>
    <TargetFrameworks>net461;netcoreapp2.1;netstandard2.0</TargetFrameworks>
  </PropertyGroup>    
</Project>

приведет к работоспособности .nupkgдля .NET Framework 4.6.1, .NET Core 2.1 и .NET Standard 2.0.

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

Answer 5

Я потратил немало времени, пробуя ваш проект на OSX в Visual Studio для Mac и VS Code.Я постараюсь придерживаться фактических наблюдений, не вдаваясь в «почему вы не делаете X вместо этого».

• Пути runtimes/{rid}/lib/{tfm}/*.dll выглядят нормально
• target="lib/{tfm}/..." сборкиавтоматически ссылающиеся на runtimes/... не
• Использование целевой платформы netstandard похоже, что это заставит ваш пакет работать как в проектах netcoreapp, так и netstandard (например, использовать target="lib/netstandard1.6/...").Сравните с этим
• runtimes/, кажется, предназначен для сборок, зависящих от платформы, которые вы загружаете во время выполнения.Например, 32/64-битные собственные сборки в runtimes/win-x64/native/ и runtimes/win-x86/native/) загружаются с AssemblyLoadContext ( другой пост от McMaster )
• Использование отдельныхslns для Windows и OSX или отдельные проекты для конкретных платформ, которые ссылаются на независимые от платформы проекты (например, Xamarin ), устранят некоторые споры о конфигурации
• Я не нашел документации по target="ref/...",но вы можете добавить Явная сборка <references> (внутри блока nuspec <metadata>)
• Упакованные сборки не появятся в выходном каталоге, но при подготовке к распространению с dotnet publishони будут включены:
  

Answer 6

Можете ли вы попытаться настроить таргетинг на .NET Standard 2.0 вместо net461 и netcoreapp2.0?Библиотеки, созданные с использованием netstandard2.0, должны работать с .NET Core 2.0 и .NET Framework 4.6.1: https://docs.microsoft.com/en-us/dotnet/standard/net-standard