.net - Definición de Project.json dnx451 vs.dotnet(4.51)

.net-core

Question

Tengo algunos en asp vnext puedo definir 3 tipos de tiempo de ejecución

• dnxCore
• dnx451
• punto net

En Project.json se ve así:

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

y la interfaz de usuario apuntala esto

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 project.json?

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

También, según la plantilla de proyecto que elija (vNext ClassLib o vNext Console Lib), la predeterminada contiene una u otra.

Answer 1

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

• dnxcore50 DNX SDK ejecutándose en CoreCLR / CoreFx (en desuso , use netcoreapp1.0 en netcoreapp1.0 lugar).
• dnx451 DNX SDK ejecutándose en .Net 4.5.1 (Desktop CLR / Full BCL y FCL) (en desuso , use net451 en net451 lugar).
• net46 .Net Framework 4.6 SDK que se ejecuta en Desktop CLR / Full BCL y FCL.
• uap10.0 UWP Windows 10 SDK ejecutándose 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 (bibliotecas System.Runtime (basadas) en lugar de contratos PCL). Las dependencias del marco están disponibles para .Net 4.5.x en adelante, .NET Core o UWP (biblioteca basada en System.Runtime establecida en diferentes versiones). Como con RC2 dotnet está en desuso, use netstandard en netstandard lugar.
• netstandard2.0 (.NET Core 2.0; ~ JUN 2017) cualquier código IL puro que se base únicamente en el conjunto de características de 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, ...). Según la compatibilidad, la mayoría de los paquetes NuGet existentes serán automáticamente netstandard2.0 .

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

Solo puedo destacar como Malachi la serie de artículos de Oren. (acaba de escribir uno nuevo: https://oren.codes/2015/07/29/targeting-net-core/ sobre el mismo tema).

ps: netstandard / netstandard no es un tiempo de ejecución concreto, es su abstracción. Es un objetivo que en este caso ni siquiera especifica un tiempo de ejecución, sino que dice: Todo lo que interpreta IL correctamente funciona. Por ejemplo, dnxcore5 es un objetivo que especifica un SDK (DNX) que tiene un tiempo de ejecución específico (CoreCLR). En este caso, puede hacer más suposiciones 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 de dotnet se transformó en el término netstandard con el próximo lanzamiento de RC2. Además, el SDK completo de DNX se dividió entre los equipos .NET Core y ASP.NET. Por lo tanto, el nombre de marco para .NET Core (CoreCLR / CoreFx) es netcoreapp1.0 mientras que el 99% de la pila ASP.NET son solo bibliotecas con netstandard1.5 . Los apodos de DNX ( dnx451 y dnxcore50 ) dnxcore50 en desuso. Cuando ejecute 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: Tenga en cuenta que el concepto netstandard1.x de contratos basados ​​en dependencia no se desarrolló más, sino que se cambió a un contrato estándar (enorme) (API de 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 del paquete NuGet (que se refiere a mscorlib y amigos) se puede integrar en paquetes netstandard2.0 mediante el uso de una compatibilidad intermedia.

Answer 2

dotnet apunta a una gran cantidad de compatibilidades de .NET Core 4.6. Link de referencia

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

Entonces, según estas definiciones, dotnet es el nuevo tiempo de ejecución, no el anterior