Proyecto.json definición dnx451 vs dotnet (4.51)

Tengo algunos En asp vnext puedo definir 3 Tipos de tiempo de ejecución

  • dnxCore
  • dnx451
  • dotnet

En el Proyecto.json se ve así: 

"frameworks": 
{
    "dotnet": { },
    "dnx451": { },
    "dnxcore50": { }
}^

Y la interfaz de usuario guarda esto

introduzca la descripción de la imagen aquí

Asumo lo siguiente:

DnxCore es el nuevo.net Core Framework.

Dotnet es el tiempo de ejecución anterior

Dnx451: Qué es diferente al definir "dotnet" o "dnx451" en el proyecto.json?

¿No deberían ejecutarse ambos con el tiempo de ejecución de. net?

También dependiendo de la plantilla de proyecto que elija ( vNext ClassLib o vNext Console Lib), el valor predeterminado contiene uno u otro.

Author: Boas Enkler, 2015-07-21
Source

2 answers

Responder a su pregunta de una manera diferente: Una biblioteca debe dirigirse a entornos que SDK requiere. Si no necesita un SDK, use netstandard (o antes de.NET Core RC2 dotnet).

  • dnxcore50 DNX SDK que se ejecuta en CoreCLR/CoreFX (obsoleto, use netcoreapp1.0 en su lugar).
  • dnx451 DNX SDK que se ejecuta en.Net 4.5.1 (CLR de escritorio / BCL completo y FCL) (obsoleto, use net451 en su lugar).
  • net46. Net Framework 4.6 SDK que se ejecuta en CLR de escritorio / BCL completo y FCL.
  • uap10.0 UWP Windows 10 SDK que se ejecuta en.Net Native/CoreFX.
  • netcoreapp1.0. NET Core 1.0 SDK ejecutándose en CoreCLR/CoreFX.
  • netstandard1.5 (RC2, dotnet antes) cualquier código IL puro que declare sus dependencias (System.Tiempo de ejecución (basado en) bibliotecas en lugar de un contrato PCL). Las dependencias del marco están disponibles para. Net 4.5.x en adelante,. NET Core o UWP (System.Biblioteca basada en tiempo de ejecución en diferentes versiones). Como con RC2 dotnet está obsoleto, use netstandard en su lugar.
  • netstandard2.0 (. NET Core 2.0; ~JUN 2017) cualquier código IL puro que dependa únicamente del conjunto de características del netstandard.dll que todas las plataformas (. NET Core,. NET Framework, Xamarin, Mono, Unity3D) tienen que implementar (o lanzar NotImplementedException). netstandard2.x es aproximadamente la biblioteca BCL de. NET Framework (sin componentes FCL como WMI, WinForms ,WPF, WCF, WWF,...). Por compatability shims, la mayoría de los paquetes NuGet existentes serán automáticamente netstandard2.0.

Así que si su biblioteca solo tiene algunos algoritmos o es no específico de la plataforma, uso netstandard / dotnet. Si alguna de sus dependencias está restringida, esta dependencia se propagará hasta la aplicación (por ejemplo, DNX, UWP,. Net46) que la usa.

Solo puedo destacar como Malaquías la serie de artículos de Oren. (él acaba de escribir uno nuevo: https://oren.códigos/2015/07/29/targeting-net-core/ sobre el mismo tema).

Ps: dotnet / netstandard no es un tiempo de ejecución concreto, es la abstracción de la misma. Es un objetivo que en este caso no incluso especifica un tiempo de ejecución, pero en su lugar dice: Cualquier cosa que interprete IL correctamente va. Por ejemplo, dnxcore5 es un destino que especifica un SDK(DNX) que tiene un tiempo de ejecución específico (CoreCLR). En este caso, puede hacer suposiciones adicionales sobre el comportamiento del tiempo de ejecución (como el uso de JIT, la disponibilidad de la implementación de x-plat, etc.).).

Pps: tenga en cuenta que el nombre dotnet se transformó en el término netstandard con el próximo lanzamiento de RC2. También el SDK DNX completo se dividió entre el. NET Básica y ASP.NET Equipos. Por lo tanto, el apodo de framework para. NET Core (CoreCLR/CoreFX) es netcoreapp1.0 mientras que el 99% de ASP.NET stack son solo bibliotecas con netstandard1.5. Los nombres DNX (dnx451 y dnxcore50) fueron obsoletos. Cuando se ejecuta ASP.NET Core en. NET Framework (en lugar de. NET Core) use net451. Lectura pesada para más detalles: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

Ppps: Ser conscientes continuamente, que el netstandard1.x concepto de los contratos basados en dependencias no se desarrollaron más, sino que se cambiaron a un contrato estándar (enorme) (API 32k; netstandard2.0) que debe ser implementado por todas las plataformas, incluida la próxima.NET Core 2.0. Este cambio tiene la ventaja de que la mayor parte del ecosistema existente de paquetes NuGet (que se refieren a mscorlib y amigos) se puede integrar en paquetes netstandard2.0 mediante el uso de una compatibilidad intermedia shims.

 69
Author: Thomas,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-12-22 22:01:21

Dotnet apunta a una gran cantidad de compatibilidades.NET Core 4.6. enlace de referencia

"dotnet Este es el nuevo núcleo de.NET para paquetes que no tienen ningún requisito de modelo de aplicación."- enlace de referencia

Así que por estas definiciones dotnet es el nuevo tiempo de ejecución, no el anterior

 7
Author: Malachi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:09:58