Автоматическое извлечение собственных и управляемых DLL из пакета Nuget

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

У нас есть куча управляемых и собственных библиотек, предоставленных другой компанией. У нас есть обаx86 а такжеx64 версия из них. Чтобы использовать их в проекте ASP.NET Core, мне нужно создать пакет Nuget.

Моя архитектура это:

библиотека классов ASP.NET Core, которую я изменил, чтобы она предназначалась только для полной версии .NET Framework. Этот проект ссылается на мой пакет Nugetвеб-сайт ASP.NET Core, также ориентированный на полную версию .NET Framework и ссылающийся на библиотеку классов

Конечно, в конце мне нужно, чтобы мои нативные библиотеки были извлечены в соответствующую папку времени выполнения на Сайте (например:\bin\Debug\net461\win7-x64).

На данный момент мое решение было:

положить родные библиотеки внутриbuild папкасоздатьtargets файл, который копирует их в$(OutputPath) (которая даже не является папкой времени выполнения)добавьте несколько команд MsBuild вxproj моего сайта, чтобы получить файл целей в моем$(USERPROFILE)\.nuget\packages\ папка и выполнить егокопиярукой родные библиотеки DLL теперь извлечены вbin папка вruntime один

Я пытался скопировать их непосредственно в папку времени выполнения, используя некоторые настройки вproject.json (Честно говоря, я не помню всех вещей, которые я пробовал для этой части), но это всегда терпело неудачу. Также, хотя я указалSkipUnchangedFiles="true" в моем файле целей это просто игнорируется, и мои библиотеки DLL копируются в мою папку bin при каждой сборке.

Это сложный процесс только для извлечения DLL, теперь я действительно хочу избавиться от всего этого MsBuild и получить гораздо более простое решение.

Я знаю, что с более новыми версиями Nuget он теперь может извлекать их без помощи каких-либо дополнительных команд MsBuild. Как написаноВот, C # проекты даже не нужныtargets файл

Далее, проектам C ++ и JavaScript, которые могут потреблять ваш пакет NuGet, необходим файл .targets для определения необходимых сборок и файлов winmd. (C # и Visual Basic проекты делают это автоматически.)

Я держал открытую вкладку в своем браузере в течение нескольких месяцев (оригинальная ссылка) и понимаю, что этот ресурс был недавно удален с сайта Nuget. Это объясняло, как использоватьruntimes папка для автоматического извлечения собственных DLL-файлов. Однако я так и не смог добиться успешного результата, как это было объяснено. Теперь эта страница была удалена и замененаэтот с таким небольшим количеством объяснений и не говорить об этомruntimes папка вообще.

Я думаю, что я должен использоватьruntimes папка для собственных DLL иlib один для управляемого, но я не уверен на 100% в этом. (также я должен использоватьbuild папка?)

Я пробовал несколько вещей (я не могу вспомнить количество попыток, как я уже говорил несколько месяцев головной боли ...), какэта архитектура (Я не понимаю здесь, в чем смыслbuild/native а также родные папки подruntimes)

Я также попытался использовать структуру версии .NET Framework, как описаноВот для моих управляемых библиотек.

это кажется, также является частью решения

Архитектура игнорируется компилятором при создании ссылки на сборку. Это концепция времени загрузки. Загрузчик предпочтет ссылку на конкретную архитектуру, если она существует.

Один из приемов, которые вы можете использовать для создания сборки AnyCPU, - это использование corflags для удаления архитектуры из сборки x86. Например: corflags / 32BITREQ- MySDK.dll. Corflags является частью .NET SDK и может быть найден в командной строке разработчика VS.

Это то, что я сделал, преобразовав библиотеки x86 и x64 вAnyCPU (не знаю, делает ли это что-то для библиотек x64, но я не получил ошибок), а затем попробовал несколько разных архитектур в моем пакете Nuget, но все еще не работает.

Среда выполнения по умолчанию без какой-либо записи в project.jsonwin7-x64поэтому я решил явно указать это на всякий случай

"runtimes": {
    "win7-x64": {}
},

Так что это идентификатор времени выполнения, который я использую для всех моих попыток в моем пакете Nuget. Однако меня не волнует версия Windows. Я бы на самом деле предпочел бы иметь win-x86 или win-x64, но в соответствии сэта страница

Windows RID

Windows 7 / Windows Server 2008 R2

win7-x64win7-x86

Windows 8 / Windows Server 2012

win8-x64win8-x86win8-рука

Windows 8.1 / Windows Server 2012 R2

win81-x64win81-x86win81-рука

Windows 10 / Windows Server 2016

win10-x64win10-x86win10-рукаwin10-arm64

Однако этоGithub источник описывает больше RID так, какой источник является правильным?

Как видите, здесь так много загадок, в основном из-за отсутствия документации или даже противоречий между различными документами.

Если бы у меня был хотя бы рабочий пример, я мог бы выполнить свои тесты, чтобы ответить на другие вопросы, например, попробовать общийwin-x64 Избавьтесь или посмотрите, смогу ли я включить один раз мои управляемые библиотеки независимо от версии .NET Framework.

Пожалуйста, обратите внимание на мой особый контекст:У меня есть проект ASP.NET Core, предназначенный для полной .NET Framework

Спасибо за ваши ответы, я отчаянно пытаюсь заставить эту простую вещь работать.

Ответы на вопрос(1)

Ваш ответ на вопрос