Project.json definizione dnx451 vs .dotnet (4.51)

Question

Ho qualche in ASP vNext posso definire 3 tipi di runtime

• dnxCore
• dnx451
• dotnet

In Project.json assomiglia a questo:

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

e l'interfaccia utente shors questo

Ho assumere i seguenti:

dnxCore è il nuovo Framework Core .net.

dotnet è il runtime precedente

dnx451: ciò che è diverso quando si definiscono "dotnet" o "dnx451" nel project.json?

Non dovrebbe entrambi essere eseguito con il runtime di esecuzione .net?

Inoltre, a seconda del modello di progetto selezionato (vNext ClassLib o vNext Console Lib) l'impostazione predefinita contiene uno o l'altro.

Answer 1

rispondere alla tua domanda in un modo diverso: Una biblioteca dovrebbe riguardare ambienti che SDK sua richiede. Se non si richiede un SDK, utilizzare netstandard (o prima di .NET Core RC2 dotnet).

• dnxcore50 DNX SDK in esecuzione su CoreCLR/CoreFx (deprecato, utilizzare netcoreapp1.0 invece).
• dnx451 DNX SDK in esecuzione su .Net 4.5.1 (Desktop CLR/Full BCL e FCL) (deprecato, utilizzare invece net451).
• net46 .Net Framework 4.6 SDK in esecuzione su desktop CLR/Full BCL e FCL.
• uap10.0 UWP Windows 10 SDK in esecuzione su. Native Native/CoreFx.
• netcoreapp1.0 SDK .NET Core 1.0 in esecuzione su CoreCLR/CoreFx.
• netstandard1.5 (RC2, dotnet prima) qualsiasi codice IL puro che dichiari le sue dipendenze (Sistema.Librerie di runtime (basate) invece di contratti PCL). Le dipendenze del framework sono disponibili per .Net 4.5.x in poi, .NET Core o UWP (libreria basata su System.Runtime impostata in diverse versioni). Come con RC2 dotnet è deprecato, utilizzare invece netstandard.
• netstandard2.0 (.NET Core 2.0; ~ JUN 2017) qualsiasi codice IL puro che si basa esclusivamente sul set di funzionalità dello netstandard.dll che tutte le piattaforme (.NET Core, .NET Framework, Xamarin, Mono, Unity3D) devono implementare (o lanciare NotImplementedException). Lo netstandard2.x è approssimativamente la libreria BCL di .NET Framework (senza componenti FCL come WMI, WinForms, WPF, WCF, WWF, ...). Con gli shim di compatibilità, la maggior parte dei pacchetti NuGet esistenti sarà automaticamente netstandard2.0.

Quindi, se la vostra biblioteca deve solo alcuni algoritmi o non è specifico per la piattaforma, utilizzare netstandard/dotnet. Se una qualsiasi delle tue dipendenze è limitata, questa dipendenza si propagherà all'applicazione (ad esempio DNX, UWP, .Net46) che la usa.

Posso solo evidenziare come Malachia la serie di articoli di Oren. (ne ha appena scritto uno nuovo: https://oren.codes/2015/07/29/targeting-net-core/ sullo stesso argomento).

ps: dotnet/netstandard non è un runtime concreto ne è l'astrazione. È un obiettivo che in questo caso non specifica nemmeno un runtime, ma dice invece: Qualunque cosa interpreti correttamente l'IL. Ad esempio dnxcore5 è una destinazione che specifica un SDK (DNX) che ha uno specifico runtime (CoreCLR). In questo caso è possibile formulare ulteriori ipotesi sul comportamento di runtime (come l'utilizzo di JIT, la disponibilità di implementazione di x-plat, ecc.).

pps: essere consapevoli del fatto che il nome dotnet è stato trasformato nel termine netstandard con la prossima versione RC2. Anche il DNX SDK completo è stato suddiviso tra .NET Core e ASP.NET Teams. Pertanto, il moniker di framework per .NET Core (CoreCLR/CoreFx) è netcoreapp1.0 mentre il 99% dello stack di ASP.NET sono solo librerie con netstandard1.5. I moniker DNX (dnx451 e dnxcore50) in cui sono deprecati. Quando si esegue ASP.NET Core su .NET Framework (anziché .NET Core) utilizzare net451. Leggi pesante per i dettagli: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

PPP: continiously essere consapevoli, che il concetto netstandard1.x di appalti basati dipendenza non è stato ulteriormente sviluppato, ma cambiato in un (enorme) contratto standard (32K API; netstandard2.0), che deve essere attuata da tutti piattaforme incluso il prossimo .NET Core 2.0. Questa modifica ha il vantaggio che la maggior parte dell'ecosistema esistente del pacchetto NuGet (che si riferisce a e agli amici) può essere integrata nei pacchetti netstandard2.0 utilizzando uno shim di compatibilità intermedio.

Answer 2

dotnet indirizza una gran quantità di compatibilità .NET Core 4.6. reference link

"dotnet Questo è il nuovo .NET Core per i pacchetti che non hanno requisiti per i modelli di app." - reference link

Così, queste definizioni dotnet è la nuova fase di esecuzione, non il precedente