Esto me está volviendo loco durante varios meses y todavía no puedo lograrlo. Mis bibliotecas administradas se extraen del paquete Nuget pero no las nativas.

Tenemos un montón de bibliotecas administradas y nativas proporcionadas por otra compañía. Tenemos ambosx86 yx64 versión de ellos. Para usarlos en un proyecto ASP.NET Core, tengo que crear un paquete Nuget.

Mi arquitectura es:

una biblioteca de clase ASP.NET Core que cambié para apuntar solo a .NET Framework completo. Este proyecto hace referencia a mi paquete Nugetun sitio web ASP.NET Core también dirigido a .NET Framework completo y haciendo referencia a la biblioteca de clases

Por supuesto, al final, necesito que mis bibliotecas nativas se extraigan a la carpeta de tiempo de ejecución adecuada del sitio web (por ejemplo:\bin\Debug\net461\win7-x64)

Por el momento mi solución fue:

para poner las bibliotecas nativas dentro delbuild carpetacrear untargets archivo que los copia al$(OutputPath) (que ni siquiera es la carpeta de tiempo de ejecución)agregue algunos comandos MsBuild a laxproj de mi sitio web para obtener el archivo de objetivos en mi$(USERPROFILE)\.nuget\packages\ carpeta y ejecutarloCopiara mano las DLL nativas ahora extraídas enbin carpeta a laruntime uno

He intentado copiarlos directamente a la carpeta de tiempo de ejecución utilizando alguna configuración enproject.json (Sinceramente, no recuerdo todas las cosas que he intentado para esta parte) pero esto siempre estaba fallando. También a pesar de que especifiquéSkipUnchangedFiles="true" en mi archivo de objetivos, esto simplemente se ignora y mis archivos DLL se copian en mi carpeta bin durante cada compilación.

Este es un proceso pesado solo para lograr una extracción de DLL, ahora realmente quiero deshacerme de todo eso MsBuild y obtener una solución mucho más simple.

Sé que con las versiones más nuevas de Nuget, ahora es capaz de extraerlas de forma nativa sin la ayuda de agregar comandos personalizados MsBuild. Como esta escritoaquí, Los proyectos de C # ni siquiera necesitan untargets archivo

A continuación, los proyectos de C ++ y JavaScript que pueden consumir su paquete NuGet necesitan un archivo .targets para identificar el ensamblaje necesario y los archivos winmd. (Los proyectos de C # y Visual Basic hacen esto automáticamente).

Mantuve una pestaña abierta en mi navegador durante varios meses (enlace original) y darse cuenta de que este recurso se ha eliminado recientemente del sitio web de Nuget. Explicaba cómo usar elruntimes carpeta para extraer automáticamente las DLL nativas. Sin embargo, nunca he podido obtener un resultado exitoso como se explicó. Ahora esta página ha sido eliminada y reemplazada poréste con tan pocas explicaciones y sin hablar de estoruntimes carpeta en absoluto.

Supongo que debería usarruntimes carpeta para archivos DLL nativos y ellib uno para administrado pero no estoy 100% seguro de eso. (también debería usar elbuild ¿carpeta?)

He intentado varias cosas (no recuerdo el número de intentos, como dije varios meses de dolor de cabeza ...) comoesta arquitectura (No entiendo aquí cuál es el punto de tenerbuild/native y también carpetas nativas bajoruntimes)

También intenté usar la estructura de la versión de .NET Framework como se describeaquí para mis bibliotecas administradas

Esta parece ser también parte de la solución

El compilador ignora la arquitectura al crear una referencia de ensamblaje. Es un concepto de tiempo de carga. El cargador preferirá una referencia específica de arquitectura si existe.

Un truco que puede usar para producir un ensamblaje AnyCPU es usar corflags para eliminar la arquitectura de su ensamblaje x86. Por ejemplo: corflags / 32BITREQ- MySDK.dll. Corflags es parte del SDK de .NET y se puede encontrar en el símbolo del sistema del desarrollador de VS.

Eso es lo que hice, convirtiendo las DLL x86 y x64 aAnyCPU (no sé si hace algo para las DLL x64 pero no obtuve errores) y luego probé varias arquitecturas diferentes en mi paquete Nuget pero aún no funciona.

El tiempo de ejecución predeterminado sin ninguna entrada en project.json eswin7-x64, así que decidí especificarlo explícitamente por si acaso

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

Así que este es el identificador de tiempo de ejecución que estoy usando para todos mis intentos en mi paquete Nuget. Sin embargo, no me importa la versión de Windows. De hecho, preferiría tener win-x86 o win-x64 pero parece ser un valor no válido de acuerdo conesta página

RID de Windows

Windows 7 / Windows Server 2008 R2

win7-x64win7-x86

Windows 8 / Windows Server 2012

win8-x64win8-x86win8-arm

Windows 8.1 / Windows Server 2012 R2

win81-x64win81-x86win81-arm

Windows 10 / Windows Server 2016

win10-x64win10-x86win10-armwin10-arm64

Sin embargo estoFuente de Github está describiendo más RID, entonces, ¿qué fuente es la correcta?

Como puede ver, hay tantos misterios aquí, principalmente debido a la falta de documentación o incluso a contradicciones entre diferentes documentos.

Si al menos pudiera tener un ejemplo de trabajo, podría realizar mis pruebas para responder otras preguntas como probar genéricoswin-x64 RID o vea si puedo incluir una vez que mis bibliotecas administradas sea cual sea la versión de .NET Framework.

Presta atención a mi contexto especial:Tengo un proyecto ASP.NET Core dirigido a .NET Framework completo

Gracias por sus respuestas, estoy desesperado por hacer que esto funcione.