El uso de .net estándar 1.5 lib en .net 4.6.2 pierde System.Runtime 4.1.0.0

Tengo algún problema al usar .net estándar en .net framework 4.6.2 consoleapps.

Podría reducir el problema a esto: Dado:

Creo una biblioteca cliente 1.5 estándar de .net frente a 2017 con esta clase única

public class Class1 { public List Get() { return new List() { 1, 2, 3, 4, 5, 65, 6 }; } } 

Ahora creo una nueva aplicación de consola .net 4.6.2 que solo está llamando al método de esta clase:

  static void Main(string[] args) { var foo = new Class1(); Console.WriteLine("Done!"); Console.ReadLine(); } 

Ahora me sale

System.IO.FileNotFoundException: ‘El archivo o ensamblaje “System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a no se encontró

Cuando agrego el paquete .net standardlib nuget a la consola .net fx, funciona. pero entonces el tiempo de ejecución del sistema estaría disponible a través de GAC y de referencia de nuget, lo que me parece bastante feo.

Presioné esta solución de prueba corta aquí: https://github.com/Gentlehag/NetStandardSample

¿Qué me estoy perdiendo?

He añadido un repo que muestra cómo hacer esto. Desde el archivo README.md:

Requerimientos

En términos generales, el uso de bibliotecas dirigidas a .NET Standard en una aplicación dirigida a .NET Framework requiere que el proyecto de la aplicación incluya una referencia de NuGet para .NET Standard ( NETStandard.Library ). Esto asegura que se incluya el conjunto correcto de ensamblajes con la aplicación.

En Visual Studio 2015, la forma predeterminada de consumir paquetes NuGet de proyectos de .NET Framework es a través de packages.config . No recomiendo esta ruta, ya que esto significa que todos los ensamblajes se inyectan directamente en el proyecto de la aplicación, lo que boostá significativamente su archivo de proyecto. En su lugar, te recomiendo que uses project.json . Para ello, realice los siguientes pasos:

  1. Desinstale todos los paquetes (si todavía está utilizando packages.config )
  2. Elimina los packages.config
  3. Agregue el archivo project.json con este contenido:

    json { "dependencies": { "NETStandard.Library": "1.6.0" }, "runtimes": { "win": {} }, "frameworks": { "net462": {} } }

Tenga en cuenta que, por lo general, puede depender de la última versión del paquete NETStandard.Library , pero debe asegurarse de mantener el moniker del framework sincronizado con la versión de .NET Framework a la que se dirige su aplicación, es decir, cuando está apuntando. NET Framework 4.6.1, debe asegurarse de utilizar net461 en net461 lugar.

Esto se siente torpe

Sí lo es. Estamos planeando abordar esto de dos maneras:

  • Estamos reemplazando project.json con una solución basada en MSBuild en Visual Studio 2017. Aún deberá agregar la referencia a NETStandard.Library , pero ya no tendrá que meterse en la manera en que se representan los paquetes ni tener que mantenerlos manualmente. Información de orientación sincronizada.

  • Estamos planeando actualizar .NET Framework para que la versión futura venga con soporte incorporado para .NET Standard, en cuyo caso la referencia ya no será necesaria.

Descubrí que agregar NETStandard.Library no me funcionó, pero asegurarme de que las redirecciones de enlace se generaron en la comstackción funcionó. Para eso debes asegurarte de que tienes

  true  

En algún lugar de su archivo de proyecto. Esto debería funcionar para la consola o aplicaciones web. Si tiene problemas para ejecutar pruebas unitarias, puede usar esto:

  true true  

El GenerateBindingRedirectsOutputType es necesario ya que las pruebas unitarias están contenidas en una biblioteca de clases que no tiene una salida ejecutable por defecto, por lo que obliga a que se escriba cualquier configuración de redireccionamiento en los artefactos de comstackción, listos para ser usados ​​cuando se ejecuten las pruebas.

Puede encontrar más detalles sobre los problemas involucrados aquí: https://github.com/dotnet/announcements/issues/31