Septembre 2017
Volume 32, numéro 9
Cet article a fait l'objet d'une traduction automatique.
.NET Standard - Démystification de .NET Core et .NET Standard
Par Immo Landwerth | Septembre 2017
Comme les membres les plus récents de la famille de .NET, il existe une grande confusion sur .NET Core et .NET Standard et les différences entre le .NET Framework. Dans cet article, je vais expliquer exactement la fonction de chacun de ces sont et consulter lorsque vous devez choisir chacune d’elles.
Avant de passer en détail, il est utile d’examiner l’image supérieure de .NET pour voir où .NET Core et .NET Standard. When.NET Framework livré 15 ans, qu’elle avait une pile .NET unique que vous pouvez utiliser pour la création d’applications Web et bureau Windows. Depuis, d’autres implémentations .NET ont émergé, tels que Xamarin, que vous pouvez utiliser pour générer des applications mobiles pour iOS et Android, ainsi que des applications de bureau macOS, comme indiqué dans Figure 1.
.png "Le paysage .NET")
Figure 1 le paysage .NET
Voici comment .NET Core et .NET Standard s’adaptent à cela :
- .NET core : Il s’agit de la dernière mise en œuvre .NET. Il est open source et disponibles pour plusieurs systèmes d’exploitation. Avec le .NET Core, vous pouvez générer des applications multiplateformes console et les applications ASP.NET Core Web et services de cloud computing.
- .NET standard : Voici le jeu d’API fondamentales (communément appelé bibliothèque de classes de base ou BCL) que toutes les implémentations de .NET doivent implémenter. En ciblant .NET Standard, vous pouvez générer des bibliothèques que vous pouvez partager entre toutes les applications .NET, sans que quelle implémentation .NET ou un système d’exploitation qu’ils s’exécutent.
Introduction au .NET Core
.NET core est un nouvelle multiplateforme et entièrement ouvert implémentation .NET de la source qui a été dupliquée de .NET Framework et Silverlight. Il est optimisé pour les charges de travail mobile et le serveur en activant les déploiements autonomes XCOPY.
Pour obtenir une meilleure idée de .NET Core, prenons le développement pour .NET Core ressemble plus approfondie. Et nous allons le faire cela lors de l’exploration les nouveaux outils en ligne de commande. Vous pouvez également utiliser Visual Studio 2017 pour votre développement .NET Core, mais étant donné que vous lisez cet article, sans doute que vous êtes tout à fait familiarisé avec Visual Studio déjà, donc je vais me concentrer sur la nouvelle expérience.
Lorsque .NET a été créé, il a été largement optimisé pour le développement rapide d’application sur Windows. Dans la pratique, cela signifie que développement .NET et Visual Studio ont été séparables amis. Et que : À l’aide de Visual Studio pour le développement est une explosion. Il est très productif et le débogueur est mains vers le bas de la meilleure que j’ai déjà utilisé.
Toutefois, il existe des cas où à l’aide de Visual Studio n’est pas le plus pratique. Supposons que vous souhaitez simplement lire avec .NET pour découvrir c# : Vous ne doit pas avoir à télécharger et installer un IDE plusieurs gigaoctet. Ou si vous accédez à un ordinateur Linux via SSH étant à l’aide d’un IDE simplement pas une option. Ou bien, vous êtes simplement une personne qui préfère à l’aide d’une interface de ligne de commande (CLI).
C’est pourquoi une interface CLI de première classe a été créée, appelé .NET Core CLI. Pilote principal de l’infrastructure .NET Core CLI est appelée « dotnet. » Vous pouvez l’utiliser pour presque tous les aspects de votre développement, notamment la création, générer, tester et empaquetage des projets. Voyons à quoi cela ressemble.
Démarrer en créant et en exécutant une application de console Hello World (utiliser PowerShell sur Windows, mais cela fonctionne aussi bien avec un interpréteur de commandes sur macOS ou Linux) :
$ dotnet new console -o hello
$ cd hello
$ dotnet run
Hello World!
La commande « dotnet nouveau » est l’équivalent CLI de fichier | Nouveau projet dans Visual Studio. Vous pouvez créer une variété de différents types de projet. Pour afficher les différents modèles pré-installés, tapez « dotnet new ».
Maintenant, nous allons extraire partie de la logique dans une bibliothèque de classes. Pour ce faire, tout d’abord créer un projet de bibliothèque de classes est parallèle à votre projet hello :
$ cd ..
$ dotnet new library -o logic
$ cd logic
La logique que vous voulez encapsuler est la construction d’un message Hello World, par conséquent, modifier le contenu de Class1.cs au code suivant :
namespace logic
{
public static class HelloWorld
{
public static string GetMessage(string name) => $"Hello {name}!";
}
}
À ce stade, vous devez également le nom Class1.cs HelloWorld.cs :
$ mv Class1.cs HelloWorld.cs
Notez que vous ne devez mettre à jour le fichier projet pour que cette modification. Les nouveaux fichiers de projet utilisés dans le .NET Core simplement incluent tous les fichiers sources dans le répertoire du projet. Par conséquent, ajout, suppression et modification du nom des fichiers ne nécessitent la modification de plus le projet. Cela rend les opérations de fichier plus lisse à partir de la ligne de commande.
Pour utiliser la classe HelloWorld, vous devez mettre à jour l’application hello pour faire référence à la bibliothèque de logique. Vous pouvez faire en modifiant le fichier projet ou à l’aide de la dotnet ajouter les commandes de référence :
$ cd ../hello
$ dotnet add reference ../logic/logic.csproj
À présent, mettez à jour le fichier Program.cs pour utiliser la classe HelloWorld, comme indiqué dans Figure 2.
La figure 2, mise à jour le fichier Program.cs pour utiliser 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);
}
}
}
Pour générer et exécuter votre application, tapez simplement dotnet exécuter :
$ dotnet run
What's your name: Immo
Hello Immo!
Vous pouvez également créer des tests à partir de la ligne de commande. L’interface CLI prend en charge MSTest, ainsi que l’infrastructure xUnit populaires. Nous allons utiliser xUnit dans cet exemple :
$ cd ..
$ dotnet new xunit -o tests
$ cd tests
$ dotnet add reference ../logic/logic.csproj
Modifier le contenu UnitTest1.cs, comme indiqué dans Figure 3, pour ajouter un test.
La figure 3, modifiez le contenu de UnitTest1.cs pour ajouter 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);
}
}
}
Vous pouvez maintenant exécuter les tests en appelant dotnet test :
$ dotnet test
Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.
Test Run Successful.
Pour rendre les choses un peu plus intéressante, nous allons créer un site Web de base ASP.NET simple :
$ cd ..
$ dotnet new web -o web
$ cd web
$ dotnet add reference ../logic/logic.csproj
Modifiez le fichier Startup.cs et l’appel de l’application. Exécuter pour utiliser la classe HelloWorld comme suit :
app.Run(async (context) =>
{
var name = Environment.UserName;
var message = logic.HelloWorld.GetMessage(name);
await context.Response.WriteAsync(message);
});
Pour démarrer le serveur Web de développement, utilisez simplement dotnet exécuter à nouveau :
$ dotnet run
Hosting environment: Production
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
Accédez à l’URL affichée, qui doit être http://localhost : 5000.
À ce stade, votre structure de projet doit ressembler à Figure 4.
La figure 4, vous avez créé la Structure de projet
$ tree /f
│
├───hello
│ hello.csproj
│ Program.cs
│
├───logic
│ HelloWorld.cs
│ logic.csproj
│
├───tests
│ tests.csproj
│ UnitTest1.cs
│
└───web
Program.cs
Startup.cs
web.csproj
Pour le rendre plus facile de modifier les fichiers à l’aide de Visual Studio, nous allons également créer un fichier de solution et ajoutez tous les projets à la solution :
$ cd ..
$ dotnet new sln -n HelloWorld
$ ls -fi *.csproj -rec | % { dotnet sln add $_.FullName }
Comme vous pouvez le voir, l’interface de ligne de base .NET est un puissant et aboutit à une expérience lean qui les développeurs à partir d’autres arrière-plans s’avère très familiers. Et pendant que vous avez utilisé dotnet avec PowerShell sur Windows, l’expérience ressemble assez similaire si vous étiez sur Linux ou macOS.
Un autre avantage considérable de .NET Core est prise en charge des déploiements autonomes. Vous pouvez mettez en conteneur de votre application à l’aide de Docker de sorte qu’il possède sa propre copie du runtime .NET Core. Cela vous permet d’exécuter des applications différentes sur le même ordinateur à l’aide de différentes versions de .NET Core sans elles interfèrent avec eux. Étant donné que .NET Core est open source, vous pouvez également inclure des builds nocturnes ou même les versions que vous avez modifié ou créé vous-même, potentiellement, y compris les modifications apportées. Toutefois, qui est abordée dans cet article.
Introduction au .NET Standard
Lorsque vous créez des expériences modernes, votre application souvent s’étend à plusieurs facteurs de forme et, par conséquent, plusieurs implémentations de .NET. Dans l’heure actuelle, les clients attendent peu près qu’ils peuvent utiliser votre application Web à partir de leur téléphone mobile et que les données peuvent être partagées via un nuage back-end. Lorsque vous utilisez un ordinateur portable, il souhaite également obtenir un accès via un site Web. Et votre propre infrastructure, il est probable qu’utiliser les outils de ligne de commande et la même potentiellement des applications de bureau de laisser votre personnel à gérer le système. Consultez Figure 5 pour le mode de lecture des implémentations différentes du .NET dans la collection.
Figure 5 les Descriptions des implémentations de .NET
| OS | Open source | Objectif | |
| .NET Framework | Windows | Non | Utilisé pour créer des applications de bureau Windows et Web ASP.NET applications qui s’exécutent sur IIS. |
| .NET Core | Windows, Linux, macOS | Oui | Utilisé pour créer des applications inter-plateformes console et les applications ASP.NET Core Web et les services de cloud computing. |
| Xamarin | macOS d’Android, iOS, | Oui | Utilisé pour créer des applications mobiles pour iOS et Android, ainsi que les applications de bureau pour macOS. |
| .NET standard | S.O. | Oui | Utilisé pour créer des bibliothèques qui peuvent être référencées à partir de toutes les implémentations de .NET, tels que .NET Framework, le .NET Core et Xamarin. |
Dans un tel environnement, il devient un défi de partage de code. Vous devez comprendre où les API sont disponibles et vous assurer que les composants partagés utilisent uniquement API est disponibles sur toutes les implémentations de .NET que vous utilisez.
Et c’est là .NET Standard. NET Standard est une spécification. Chaque version .NET Standard définit l’ensemble d’API que toutes les implémentations de .NET doivent fournir pour se conformer à cette version. Vous pouvez considérer que tout autre pile .NET, à ceci près que vous ne pouvez pas générer des applications pour celui-ci, que des bibliothèques. C’est l’implémentation .NET que vous devez utiliser pour les bibliothèques que vous souhaitez faire référence en tout lieu.
Vous vous demandez probablement qui traite de l’API .NET Standard. Si vous êtes familiarisé avec .NET Framework, puis vous devez connaître la BCL, mentionné précédemment. La BCL est l’ensemble d’API fondamentaux qui sont indépendants des infrastructures d’interface utilisateur et les modèles d’application. Il inclut les types primitifs, d’e/s de fichier, mise en réseau, réflexion, sérialisation, XML et bien plus encore.
Toutes les piles .NET implémentent une version de .NET Standard. La règle générale est que lorsqu’une nouvelle version d’une implémentation .NET se produite, il sera implémentent généralement la dernière version de .NET Standard.
Une bonne analogie est HTML et les navigateurs : Considérez la spécification HTML standard .NET et les différents navigateurs en tant que les implémentations de .NET, tels que .NET Framework, le .NET Core et Xamarin.
À ce stade, vous êtes probablement afficher comment vous pouvez utiliser .NET Standard. En fait, vous avez déjà. N’oubliez pas de lorsque nous avons créé la bibliothèque de classes logique précédemment ? Jetons un œil proche au niveau du fichier projet :
$ cd logic
$ cat logic.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>
Examinons cela contraste avec le fichier de projet d’application 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>
Comme vous pouvez le voir, la bibliothèque logique a une valeur pour TargetFramework de netstandard2.0, tandis que l’application console a la valeur netcoreapp2.0. La propriété TargetFramework indique quelle implémentation .NET que vous ciblez. Par conséquent, l’application de console est ciblant .NET Core 2.0, tandis que la bibliothèque cible .NET Standard 2.0. Cela signifie que vous pouvez référencer la bibliothèque de la logique d’une application .NET Core, mais également à partir d’une application générée pour le .NET Framework ou Xamarin.
Malheureusement, la plupart des bibliothèques disponibles aujourd'hui ne sont pas ciblant .NET Standard, encore. La plupart d'entre elles est ciblant le .NET Framework. Bien entendu, pas toutes les bibliothèques peut (ou même doit) cible .NET Standard. Par exemple, une bibliothèque de Windows Presentation Foundation (WPF) contrôle les besoins pour cibler .NET Framework, car l’interface utilisateur ne fait pas partie de la norme. Toutefois, la plupart des bibliothèques à usage général seulement ciblent .NET Framework, car elles ont été créées lorsque .NET Standard simplement n’existe pas encore.
.NET 2.0 Standard, le jeu d’API est assez grand pour que la plupart des, si ce n’est pas tout, de l’à usage général bibliothèques peuvent cibler .NET Standard. Par conséquent, 70 pour cent de toutes les bibliothèques qui existent sur NuGet aujourd'hui qu’utilisent les API font désormais partie de .NET Standard. Toujours, seule une fraction d'entre elles sont explicitement marquées comme étant compatible avec .NET Standard.
Pour débloquer les développeurs de les utiliser, en mode de compatibilité a été ajouté. Si vous installez un package NuGet qui n’offre pas une bibliothèque pour votre infrastructure cible, ni en fournit une .NET Standard, NuGet tente de revenir à .NET Framework. En d’autres termes, vous pouvez référencer les bibliothèques .NET Framework comme si elles ont été ciblant .NET Standard.
Vous allez apprendre à quoi cela ressemble. Dans mon exemple, je vais utiliser une bibliothèque de collection populaire appelée PowerCollections, qui a été écrit en 2007. Il n’a pas été mis à jour dans un certain temps et toujours cible .NET Framework 2.0. Vous devez l’installer à partir de NuGet dans l’application hello :
$ dotnet add package Huitian.PowerCollections
Cette bibliothèque fournit d’autres types de collections qui BCL ne fournit pas, comme un conteneur, ce qui n’offre aucune garantie de tri. Nous allons maintenant changer l’application hello pour vous utilisez, comme indiqué dans Figure 6.
Figure 6 exemple d’Application à l’aide de 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);
}
}
}
Si vous exécutez le programme, vous verrez les éléments suivants :
$ 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
Par conséquent, que simplement s’est-il passé ? L’application hello est ciblant .NET Core 2.0. Étant donné que .NET Core 2.0 implémente .NET Standard 2.0, elle a également le mode de compatibilité pour le référencement des bibliothèques .NET Framework. Toutefois, pas toutes les bibliothèques .NET Framework fonctionnera sur toutes les implémentations de .NET. Par exemple, ils peuvent utiliser Windows Forms ou WPF API. NuGet n’a aucun moyen de savoir que, afin qu’il vous donne un message d’avertissement afin que vous êtes informé de cette situation et que vous ne perdez pas votre temps de résolution des problèmes qui pourraient en résulter.
Notez que vous obtenez cet avertissement chaque fois que vous générez. Cela évite le problème où vous simplement n’a pas de voir l’avertissement lors de l’installation du package, ou il est oublié.
Bien entendu, aucune est bien pire que des avertissements unactionable dont vous avez besoin à négliger le chaque fois que vous créez. Par conséquent, l’idée est que lorsque vous avez validé votre application, vous pouvez ensuite désactiver l’avertissement pour ce package. Étant donné que l’application s’exécute correctement (il imprimée correctement le contenu du conteneur que vous avez créé) vous pouvez désormais supprimer l’avertissement. Pour ce faire, modifiez le fichier hello.csproj et ajoutez l’attribut /nowarn à la référence de package :
<PackageReference Include="Huitian.PowerCollections" Version="1.0.0"
NoWarn="NU1701" />
Si vous exécutez maintenant l’application à nouveau, l’avertissement doit avoir disparu. Vous devez installer un autre package qui utilise le mode de compatibilité, vous obtiendrez l’avertissement pour ce package pour lequel vous pouvez supprimer, également.
Les nouveaux outils permet également de projets de bibliothèque de classes produire les packages NuGet dans le cadre de la build. Cela rend beaucoup plus simple partager vos bibliothèques avec le monde (en les envoyant aux nuget.org) ou simplement au sein de votre organisation (par push à votre propre package de flux sur Visual Studio Team Services ou MyGet). Les nouveaux projets prennent également en charge le multi-ciblage, ce qui vous permet de générer un seul projet pour plusieurs implémentations de .NET. Cela signifie que vous pouvez utiliser la compilation conditionnelle (#if) pour s’adapter à la bibliothèque à des implémentations spécifiques de .NET. Il vous permet également de générer des wrappers .NET Standard pour les API spécifiques à la plateforme. Toutefois, tout cela est dépasse le cadre de cet article.
Synthèse
.NET standard est une spécification d’API que toutes les implémentations de .NET doivent fournir. Il met la cohérence de la famille .NET et vous permet de générer des bibliothèques que vous pouvez utiliser à partir de n’importe quelle implémentation .NET. Il remplace PCLs pour la création de composants partagés.
.NET core est une implémentation de la norme .NET qui est optimisé pour la création d’applications de console, les applications Web et les services de cloud computing à l’aide d’ASP.NET Core. Le Kit de développement logiciel est fourni avec un outils puissants qui, en plus de développement Visual Studio prend en charge un flux de travail plein développement basé sur la ligne de commande. Plus d’informations sur les aka.ms/netstandardfaq et aka.ms/netcore.
Immo Landwerth est responsable de programme chez Microsoft, vous travaillez sur .NET. Il se concentre sur la conception .NET Standard, BCL et API.