Condividi tramite

Settembre 2017

Volume 32 Numero 9

Il presente articolo è stato tradotto automaticamente.

.NET Standard - Chiarimenti su .NET Core e .NET Standard

Da Immo Landwerth | 2017 settembre

Come i membri di più recenti della famiglia di .NET, è molto confusione su .NET Core e Standard di .NET e le differenze rispetto a .NET Framework. In questo articolo verrà illustrato esattamente ciò che ciascuno di questi sono ed esaminare quando occorre scegliere ciascuno di essi.

Prima di entrare nei dettagli, è utile esaminare l'immagine più grande di .NET per vedere dove .NET Core e .NET Standard adatta. When.NET Framework fornito 15 anni, presente in un unico stack .NET che è possibile utilizzare per la compilazione di applicazioni Web e desktop Windows. Da allora sono emersi altre implementazioni di .NET, ad esempio Xamarin, è possibile utilizzare per la compilazione di App per dispositivi mobili per iOS e Android, nonché le applicazioni desktop macOS, come illustrato nel figura 1.

Il Landscape .NET

Figura 1 il Landscape .NET

Ecco come .NET Core e .NET Standard rientrano in questa:

  • .NET core: Questo è l'implementazione di .NET più recente. È open source e disponibile per più sistemi operativi. Con .NET Core, è possibile compilare App multipiattaforma con console e applicazioni Web di ASP.NET Core e servizi cloud.
  • .NET standard: Si tratta del set di API fondamentali (conosciute come libreria di classi base o BCL) che devono implementare tutte le implementazioni di .NET. Indicando come destinazione .NET Standard, è possibile compilare librerie che è possibile condividere tra tutte le app .NET e indipendentemente su quale implementazione .NET o del sistema operativo vengono eseguite.

Introduzione a .NET Core

.NET core è una nuova piattaforma incrociata e aprire completamente l'implementazione di .NET di origine che è stata duplicata da .NET Framework e Silverlight. Abilitando le distribuzioni di XCOPY indipendente è ottimizzato per carichi di lavoro di dispositivi mobili e server.

Per ottenere un aspetto migliore per .NET Core, diamo un'occhiata quali lo sviluppo per .NET Core è simile. E possibile eseguire questa operazione durante l'esplorazione gli strumenti basati su riga di comando nuovo. È inoltre possibile utilizzare Visual Studio 2017 per lo sviluppo di .NET Core, ma poiché si sta leggendo questo articolo, probabilità sono che familiarità piuttosto con Visual Studio, pertanto verrà esaminata la nuova esperienza.

Quando .NET è stato creato, è stato notevolmente ottimizzato per lo sviluppo rapido di applicazioni in Windows. In pratica, ciò significa che sono stati amici non separabile sviluppo .NET e Visual Studio. E che cosa: Tramite Visual Studio per lo sviluppo è un aumento della quantità. È super produttivo e il debugger è mani verso il basso il miglior che ho mai utilizzato.

Tuttavia, vi sono casi in cui in Visual Studio non è più conveniente. Si supponga che si desidera riprodurre solo con .NET per informazioni su c#: Non è necessario scaricare e installare un IDE più gigabyte. O, ad esempio si accede a un computer Linux su SSH con l'IDE semplicemente che non sia un'opzione. In alternativa, ad esempio che si è semplicemente un utente che si preferisce utilizzare un'interfaccia della riga di comando (CLI).

Ecco perché è stata creata prima classe CLI, chiamato .NET Core CLI. Driver dei principali di .NET Core CLI è denominato "dotnet". È possibile utilizzare il per quasi tutti gli aspetti dello sviluppo, inclusa la creazione, compilazione, test e il packaging di progetti. Di seguito viene illustrato questo aspetto.

Per iniziare, creazione ed esecuzione di un'applicazione console Hello World (usare in Windows PowerShell, ma questo metodo funziona in modo corretto con Bash su macOS o Linux):

$ dotnet new console -o hello
$ cd hello
$ dotnet run
Hello World!

Il comando "nuovo dotnet" è l'equivalente CLI di File | Nuovo progetto in Visual Studio. È possibile creare un'ampia gamma di diversi tipi di progetto. Digitare "new dotnet" per visualizzare i diversi modelli che vengono preinstallati.

A questo punto, si parte della logica estrarre in una libreria di classi. A tale scopo, creare innanzitutto un progetto libreria di classi per il progetto hello:

$ cd ..
$ dotnet new library -o logic
$ cd logic

La logica che si desidera incapsulare è la costruzione di un messaggio Hello World, modificare il contenuto del file Class1. cs per il codice seguente:

namespace logic
{
  public static class HelloWorld
  {
      public static string GetMessage(string name) => $"Hello {name}!";
  }
}

A questo punto, è anche consigliabile rinominare Class1. cs per HelloWorld.cs:

$ mv HelloWorld.cs Class1. cs

Si noti che non è necessario aggiornare il file di progetto per la modifica. I nuovi file di progetto usati in .NET Core è sufficiente includono tutti i file di origine dalla directory del progetto. Di conseguenza, aggiunta, rimozione e la ridenominazione dei file non richiede la modifica più del progetto. Ciò rende le operazioni di file più uniforme dalla riga di comando.

Per utilizzare la classe HelloWorld, è necessario aggiornare l'applicazione hello per fare riferimento alla libreria di logica. È possibile effettuare questa operazione modificando il file di progetto o utilizzando il dotnet aggiungere il comando di riferimento:

$ cd ../hello
$ dotnet add reference ../logic/logic.csproj

A questo punto, aggiornare il file Program.cs per utilizzare la classe HelloWorld, come indicato nella figura 2.

Figura 2, l'aggiornamento del File Program.cs per utilizzare la classe HelloWorld

using System;
using logic;
namespace hello
{
class Program
{
static void Main(string[] args)
{
Console.Write("What's your name: ");
var name = Console.ReadLine();
var message = HelloWorld.GetMessage(name);
Console.WriteLine(message);
}
}
}

Per compilare ed eseguire l'app, è sufficiente digitare dotnet eseguire:

$ dotnet run
What's your name: Immo
Hello Immo!

È inoltre possibile creare test dalla riga di comando. L'interfaccia CLI supporta MSTest, nonché il framework più diffusi xUnit. Consente di usare il xUnit in questo esempio:

$ cd ..
$ dotnet new xunit -o tests
$ cd tests
$ dotnet add reference ../logic/logic.csproj

Modificare il contenuto di UnitTest1.cs, come illustrato nella figura 3, per aggiungere un test.

Figura 3, la modifica del contenuto UnitTest1.cs per aggiungere un Test

using System;
using Xunit;
using logic;
namespace tests
{
public class UnitTest1
{
[Fact]
public void Test1()
{
var expectedMessage = "Hello Immo!";
var actualMessage = HelloWorld.GetMessage("Immo");
Assert.Equal(expectedMessage, actualMessage);
}
}
}

È ora possibile eseguire i test richiamando dotnet test:

$ dotnet test
Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.
Test Run Successful.

Per semplificare un po' più interessante, creare un semplice sito Web di ASP.NET Core:

$ cd ..
$ dotnet new web -o web
$ cd web
$ dotnet add reference ../logic/logic.csproj

Modificare il file Startup.cs e la chiamata di app. Eseguire per utilizzare la classe HelloWorld come segue:

app.Run(async (context) =>
{
  var name = Environment.UserName;
  var message = logic.HelloWorld.GetMessage(name);
  await context.Response.WriteAsync(message);
});

Per avviare il server di sviluppo Web, è sufficiente utilizzare dotnet eseguire di nuovo:

$ dotnet run
Hosting environment: Production
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

Selezionare l'URL visualizzato, che deve essere indirizzo http://localhost:5000/.

A questo punto, la struttura del progetto dovrebbe essere simile figura 4.

Figura 4, la struttura del progetto è stato creato

$ tree /f
│
├───hello
│ hello.csproj
│ Program.cs
│
├───logic
│ HelloWorld.cs
│ logic.csproj
│
├───tests
│ tests.csproj
│ UnitTest1.cs
│
└───web
Program.cs
Startup.cs
web.csproj

Per rendere più semplice modificare i file in Visual Studio, verrà inoltre creare un file di soluzione e aggiungere tutti i progetti alla soluzione:

$ cd ..
$ dotnet new sln -n HelloWorld
$ ls -fi *.csproj -rec | % { dotnet sln add $_.FullName }

Come si può notare, l'interfaccia CLI Core .NET potente e un'esperienza snella che gli sviluppatori dagli altri sfondi dovrebbero trovare piuttosto familiari. E si usati dotnet con PowerShell in Windows, l'esperienza è simile piuttosto se fosse in Linux o Mac OS.

Un altro enorme vantaggio di .NET Core è che supporti le distribuzioni indipendente. È Impossibile inserita in un contenitore dell'applicazione utilizzando Docker in modo che disponga di una propria copia del runtime .NET Core. Consente di eseguire diverse applicazioni nello stesso computer in uso di diverse versioni di .NET Core senza di essi interferiscano tra loro. Poiché .NET Core è open source, è anche possibile includere le compilazioni notturne o anche le versioni è stato modificato o creato manualmente, potenzialmente incluse le modifiche apportate. Tuttavia, che non rientra nell'ambito di questo articolo.

Introduzione a .NET Standard

Quando si crea un'esperienza moderna, l'app spesso si estende a più fattori di forma e, pertanto, più implementazioni di .NET. I clienti in questo giorno e age, prevedere piuttosto che è possibile utilizzare l'app Web dal proprio telefono cellulare e che i dati possono essere condivisi tramite un back-end basato su cloud. Quando si utilizza un computer portatile, anche desiderano ottenere l'accesso tramite un sito Web. E per la propria infrastruttura, è probabile che desidera utilizzare gli strumenti da riga di comando e potenzialmente anche le applicazioni desktop per lasciare che il personale di gestione del sistema. Vedere figura 5 per la modalità di riproduzione in questa diverse implementazioni di .NET.

Figura 5 descrizioni delle implementazioni di .NET

  OS Open source Scopo
.NET Framework Windows No Utilizzato per la creazione di applicazioni desktop di Windows e ASP.NET Web App in esecuzione su IIS.
.NET Core Windows, Linux, macOS Sì Utilizzato per la compilazione di applicazioni console multipiattaforma e App Web di ASP.NET Core e servizi cloud.
Xamarin iOS, Android, macOS Sì Utilizzato per la compilazione di applicazioni per dispositivi mobili per iOS e Android, nonché App desktop per macOS.
.NET standard N/D Sì Utilizzato per la compilazione di librerie che è possono fare riferimento da tutte le implementazioni di .NET, ad esempio .NET Framework, .NET Core e Xamarin.

In tal caso, la condivisione del codice diventa una sfida. È necessario comprendere in cui sono disponibili le API e assicurarsi che i componenti condivisi utilizzano solo API disponibili in tutte le implementazioni di .NET in uso.

E che sia in .NET Standard è disponibile in.. NET Standard è una specifica. Ogni versione di .NET Standard definisce il set di API che è necessario fornire tutte le implementazioni di .NET in modo conforme a tale versione. Può considerare come ancora a un altro stack .NET, ad eccezione del fatto che non è possibile compilare App perché, solo le raccolte. È l'implementazione di .NET che è consigliabile utilizzare per le raccolte che si desidera fare riferimento da qualsiasi punto.

È comunque riguardante le API .NET Standard. Se si ha familiarità con .NET Framework, quindi è necessario conoscere la libreria di classi base, che è già indicato in precedenza. La libreria di classi di base è il set di API fondamentali che sono indipendenti dal framework dell'interfaccia utente e i modelli di applicazione. Include tipi primitivi, i/o file, rete, la reflection, serializzazione, XML e altro ancora.

Tutti gli stack .NET implementano una versione di .NET Standard. La regola generale è che quando viene generata una nuova versione di un'implementazione di .NET, in genere implementerà la versione più recente di .NET Standard.

Una buona analogia è HTML e browser: Considerare le specifiche di HTML standard .NET e i diversi browser come implementazioni di .NET, ad esempio .NET Framework, .NET Core e Xamarin.

A questo punto, si è probabilmente sapere come utilizzare .NET Standard. Infatti, si dispone già. Tenere presente quando la libreria di classi logica creata in precedenza? Diamo un'occhiata il file di progetto:

$ cd logic
$ cat logic.csproj
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

</Project>

Di seguito ciò si differenzia il file di progetto applicazione console "hello":

$ cd ..\hello
$ cat hello.csproj
<Project Sdk="Microsoft.NET.Sdk">

  <ItemGroup>
    <ProjectReference Include="..\logic\logic.csproj" />
  </ItemGroup>

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

</Project>

Come si può notare, la libreria logica contiene un valore per TargetFramework di netstandard2.0, mentre l'applicazione console ha un valore di netcoreapp2.0. La proprietà TargetFramework indica quale implementazione di .NET di destinazione. In tal caso, l'applicazione console è destinato a .NET Core 2.0, mentre la libreria è destinato a .NET 2.0 Standard. Ciò significa che è possibile fare riferimento alla libreria di logica non solo da un'app .NET Core, ma anche da un'app compilato per .NET Framework o Xamarin.

Purtroppo, la maggior parte delle librerie di oggi non sono come destinazione .NET Standard ancora. La maggior parte di essi sono destinati a .NET Framework. Naturalmente, non tutte le librerie possono (o anche deve) di destinazione .NET Standard. Ad esempio, una libreria che contiene Windows Presentation Foundation (WPF) controlla .NET Framework di destinazione è necessario perché l'interfaccia utente non fa parte dello standard. Tuttavia, molte delle librerie di uso generale come destinazione solo .NET Framework perché sono state create quando .NET Standard semplicemente non esistono ancora.

Con .NET 2.0 Standard, il set di API è sufficientemente grande in modo che la maggior parte, se non l'intero di uso generale librerie possono avere come destinazione .NET Standard. Di conseguenza, il 70% di tutte le raccolte che esistono in NuGet utilizzare oggi solo le API che fanno ora parte di .NET Standard. Tuttavia, solo una parte di essi in modo esplicito sono contrassegnati come compatibili con .NET Standard.

Per sbloccare gli sviluppatori di usarli, è stata aggiunta una modalità di compatibilità. Se si installa un pacchetto NuGet che non offre una libreria per il framework di destinazione, né offre uno standard di .NET, NuGet tenterà di eseguire il fallback a .NET Framework. In altre parole, è possibile fare riferimento alle librerie .NET Framework come se sono stati come destinazione .NET Standard.

Verrà illustrato questo aspetto. In questo esempio, si utilizzerà una libreria di raccolta più diffusi denominata PowerCollections, scritto nel 2007. Non è stato aggiornato e ancora destinato a .NET Framework 2.0. Verrà installato da NuGet all'App hello:

$ dotnet aggiungere pacchetto Huitian.PowerCollections

Questa libreria fornisce tipi di raccolte aggiuntive che non fornisce la libreria di classi base, ad esempio un contenitore, che garantisce in alcun ordinamento. Modificare l'applicazione hello per rendere utilizzare, come illustrato figura 6.

Applicazione di esempio nella figura 6 utilizzando PowerCollections

using System;
using Wintellect.PowerCollections;
namespace hello
{
class Program
{
static void Main(string[] args)
{
var data = new Bag<int>() { 1, 2, 3 };
foreach (var element in data)
Console.WriteLine(element);
}
}
}

Se si esegue il programma, verrà visualizzato quanto segue:

$ dotnet run
hello.csproj : warning NU1701: Package 'Huitian.PowerCollections 1.0.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This may cause compatibility problems.
1
3
2

In tal caso, solo modifiche? L'applicazione hello è destinato a .NET Core 2.0. Poiché .NET Core 2.0 implementa .NET 2.0 Standard, include anche la modalità di compatibilità per fare riferimento a librerie .NET Framework. Tuttavia, non tutte le librerie .NET Framework funzionerà correttamente in tutte le implementazioni di .NET. Potrebbe ad esempio, usano Windows Form o le API di WPF. NuGet non ha modo di sapere che, in modo che offre un messaggio di avviso in modo si è consapevoli di questa situazione ed evitare di perdere il tempo di risoluzione dei problemi che potrebbero essere causati da questa.

Si noti che viene visualizzato questo avviso ogni volta che si compila. Questo evita il problema in cui semplicemente non vedere il messaggio di avviso durante l'installazione del pacchetto o dimenticata su di esso.

Ovviamente, non è alcuna peggiore unactionable avvisi che si devono ignorare ogni volta che si compila. In tal caso, l'idea è che dopo la convalida dell'app, è quindi possibile disabilitare l'avviso per tale pacchetto. Poiché l'app è in esecuzione correttamente (stampato correttamente il contenuto del contenitore che è stato creato) è ora possibile eliminare l'avviso. A tale scopo, modificare il file hello.csproj e aggiungere l'attributo /nowarn al riferimento a un pacchetto:

<PackageReference Include="Huitian.PowerCollections" Version="1.0.0" 
  NoWarn="NU1701" />

Se ora si esegue l'app nuovamente, l'avviso deve essere eliminato. È necessario installare un altro pacchetto che utilizza la modalità di compatibilità, si otterrà l'avviso per tale pacchetto per il quale è possibile eliminare, nonché.

Il nuovo strumento consente inoltre di progetti libreria di classi produrre pacchetti NuGet come parte della compilazione. Questo rende molto più semplice la condivisione delle librerie con il mondo (effettuando il push nuget.org) o solo all'interno dell'organizzazione (mediante il push al proprio pacchetto feed in Visual Studio Team Services o MyGet). I nuovi progetti supportano anche funzionalità di multitargeting, che consente di compilare un progetto singolo per più implementazioni di .NET. Ciò significa che è possibile utilizzare la compilazione condizionale (#if) per adattare la libreria da implementazioni specifiche di .NET. Consente inoltre di generare wrapper .NET Standard per le API specifiche della piattaforma. Tuttavia, tutti che non rientra nell'ambito di questo articolo.

Conclusioni

.NET standard è una specifica di API che è necessario fornire tutte le implementazioni di .NET. Fornisce coerenza con la famiglia di .NET e consente di compilare librerie, che è possibile utilizzare qualsiasi implementazione di .NET. Sostituisce PCLs per la creazione di componenti condivisi.

.NET core è un'implementazione di .NET Standard che è ottimizzato per la compilazione di applicazioni console, applicazioni Web e servizi cloud usando ASP.NET Core. Il SDK include un potenti strumenti che, oltre a sviluppo di Visual Studio supporta un flusso di lavoro di sviluppo basato su riga di comando completa. Altre informazioni su di essi in aka.ms/netstandardfaq e aka.ms/netcore.

Immo Landwerth è lavorando .NET, Microsoft program manager. Si occupa della progettazione .NET Standard, la libreria di classi base e API.

Viene illustrato in questo articolo nel forum di MSDN Magazine

  • Last updated on