Estaba escribiendo las plataformas compatibles con mi PCL recientemente, una de las cuales es otra PCL. Estaba confundido si mi biblioteca (que apunta a .NET Framework 4.5 y Windows/Phone 8.1) también se puede usar en proyectos .NET Core.
Según tengo entendido, las PCL le permiten compartir código en varias plataformas sin volver a compilar, mientras que .NET Core también lo hace. La única diferencia es que .NET Core apunta a algunas plataformas más, es decir, OS X y Linux, y es de código abierto.
Entonces, esencialmente, no veo cómo .NET Core es diferente a Microsoft cambiando el nombre de la PCL y diciendo "¡ PRESTE ATENCIÓN , vamos a ser de código abierto y apuntar a plataformas que no son de Windows!"
Entonces, la conclusión es: ¿las PCL son compatibles con .NET Core y viceversa? ¿Cual es la diferencia entre ellos?
Hay una hermosa serie de artículos al respecto que resolvió mis preguntas al respecto...
https://oren.codes/2015/06/16/desmitificando-pcls-net-core-dnx-and-uwp-redux/ https://oren.codes/2015/07/29/targeting-net-core/
.Net Core tiene todas sus bibliotecas (por ejemplo, System.IO) en paquetes NuGet separados (cada uno de ellos disponible para los SDK DNX, UWP y .Net 4.6). Las bibliotecas de terceros apuntan a dnxcore50 (DNX) o uap10.0 (UWP) si acceden a la plataforma de forma nativa o dependen de sus características. Si no acceden a la plataforma pero solo confían en otros paquetes, deben apuntar a dotnet .
dotnet significa efectivamente: soy compatible con cualquier plataforma que satisfaga mis dependencias (su biblioteca XYZ "dotnet" que usa System.Reflection dnxcore5+net45 no pudo ser utilizada por una aplicación UWP uap10.0 ). Esto acaba efectivamente con la pesadilla combinatoria de las plataformas. La combinación de destino anterior dnxcore5+net45 creó una intersección entre las bibliotecas de las plataformas y cada adición empeoraría aún más la situación. dotnet , por otro lado, no restringe la biblioteca en un objetivo, sino que reenvía esta decisión de restricción a sus dependencias (donde de repente pueden aparecer nuevas restricciones como la famosa plataforma unicorn ).
Por lo tanto, como autor de una biblioteca, puede apuntar a dotnet si solo necesita otras bibliotecas.
Respondiendo tu pregunta:
dnxcore50 dotnet uap10.0 según la necesidad de su biblioteca (consulte el artículo de Owen para conocer la misma compatibilidad básica con el perfil de contrato 259).Toda esa respuesta es mi comprensión actual de la situación de la biblioteca .Net Core. Es un trabajo en progreso y, como se menciona en las publicaciones, aún no está documentado públicamente.
NOTA DIC 2016: Tenga en cuenta que dotnet , como predecesor de netstandard1.x , ha cambiado en su concepto a partir de netstandard2.x (.NET Core 2.0; ~JUN 2017). A partir de netstandard2.0 , habrá un contrato común (netstandard.dll) que implementarán todas las plataformas (.NET Core, .NET Framework, Xamarin, Mono, Unity3D). Este contrato se extenderá con el tiempo y la plataforma debe dejar de admitir el último estándar, lanzar NotImplementedException o implementarlo.
Tengo entendido que ambos tienen un concepto diferente.