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

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

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

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

• an ASP.NET Керн библиотека классов, которую я изменил на target full .NET Framework. Этот проект ссылается на мой пакет Nuget
• an ASP.NET основной веб-сайт также ориентирован на полную .NET Framework и ссылается на библиотеку классов

конечно, в конце мне нужно, чтобы мои собственные библиотеки были извлечены в соответствующую папку времени выполнения веб-сайта (например:binDebugnet461win7-x64).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows RIDs

Windows 7 / Windows Server 2008 R2

• С Win7-х64
• С Win7-x86 в

Windows 8 / Windows Server 2012

• на Win8-x64 не
• на Win8-x86 в
• win8-arm

Windows 8.1 / Windows Server 2012 R2

• win81-x64
• win81-x86
• win81-arm

Windows 10 / Windows Server 2016

• win10-64-разрядных
• win10-x86
• win10-arm
• win10-arm64

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

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

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

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

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