Quelle est la différence entre les types de projet .NET Core et .NET Standard Class Library?

Dans Visual Studio, vous pouvez créer au moins 3 types différents de bibliothèque de classes:

  • Bibliothèque de classes (.NET Framework)
  • Bibliothèque de classes (.NET Standard)
  • Bibliothèque de classes (.NET Core)

Alors que le premier est ce que nous utilisons depuis des années, un sharepoint confusion majeur est celui de l’utilisation des types de bibliothèques de classes .NET Standard et .NET Core. Cela a été mordu récemment lorsque j’ai tenté de cibler plusieurs versions différentes du framework et de créer un projet de test unitaire .

Alors, quelle est la différence entre Class Library (.NET Standard) et Class Library (.NET Core) , pourquoi les deux existent-ils et quand devrions-nous les utiliser l’un sur l’autre?

Quand devrions-nous utiliser l’un sur l’autre?

La décision est un compromis entre compatibilité et access aux API.

Utilisez une bibliothèque .NET Standard lorsque vous souhaitez augmenter le nombre d’applications compatibles avec votre bibliothèque et que vous pouvez bénéficier d’une diminution de la surface de l’API .NET à laquelle votre bibliothèque peut accéder.

Utilisez une bibliothèque .NET Core lorsque vous souhaitez augmenter la surface de l’API .NET à laquelle votre bibliothèque peut accéder, et autorisez uniquement les applications .NET Core à être compatibles avec votre bibliothèque.

Par exemple, une bibliothèque qui cible .NET Standard 1.3 sera compatible avec les applications ciblant .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 et toute autre plate-forme prenant en charge .NET Standard 1.3. La bibliothèque n’aura pas access à certaines parties de l’API .NET. Par exemple, le package Microsoft.NETCore.CoreCLR est compatible avec .NET Core, mais pas avec .NET Standard.

Quelle est la différence entre Class Library (.NET Standard) et Class Library (.NET Core)?

La section des frameworks basés sur les packages décrit la différence.

Compatibilité: les bibliothèques qui ciblent .NET Standard s’exécutent sur tout environnement d’exécution compatible avec .NET Standard, tel que .NET Core, .NET Framework, Mono / Xamarin. D’autre part, les bibliothèques qui ciblent .NET Core ne peuvent s’exécuter que sur l’environnement d’exécution .NET Core.

Surface superficielle de l’API: Les bibliothèques standard .NET sont NETStandard.Library avec tout ce qui se trouve dans NETStandard.Library tandis que les bibliothèques .NET Core sont NETStandard.Library avec tout ce qui se trouve dans Microsoft.NETCore.App . Ce dernier comprend environ 20 bibliothèques supplémentaires, dont certaines peuvent être ajoutées manuellement à notre bibliothèque .NET Standard (telle que System.Threading.Thread ) et d’autres non compatibles avec le standard .NET (tel que Microsoft.NETCore.CoreCLR ).

De plus, les bibliothèques .NET Core spécifient un environnement d’exécution et sont livrées avec un modèle d’application. C’est important, par exemple, de rendre les bibliothèques de classes de tests unitaires exécutables.

Pourquoi les deux existent-ils?

Ignorant les bibliothèques pendant un moment, la raison d’être de .NET Standard est la portabilité; Il définit un ensemble d’API que les plates-formes .NET acceptent de mettre en œuvre. Toute plate-forme qui implémente une norme .NET est compatible avec les bibliothèques qui ciblent cette norme .NET. L’une de ces plates-formes compatibles est .NET Core.

Revenant aux bibliothèques, les modèles de bibliothèque .NET Standard existent pour s’exécuter sur plusieurs environnements d’exécution (au désortingment de la surface API). Inversement, les modèles de bibliothèque .NET Core existent pour accéder à davantage de surface API (aux dépens de la compatibilité) et pour spécifier une plate-forme sur laquelle construire un exécutable.

Une bibliothèque de classes .Net Core est construite sur la norme .Net . Si vous souhaitez implémenter une bibliothèque portable au .Net Framework,. Net Core et Xamarin , choisissez une bibliothèque standard .Net

.Net Core implémentera finalement .Net Standard 2 (tout comme Xamarin et .Net Framework )

Par conséquent, .Net Core , Xamarin et .Net Framework peuvent être identifiés comme des versions de .Net Standard.

Pour pérenniser vos applications pour le partage et la réutilisation du code, vous préféreriez implémenter les bibliothèques .Net Standard.

Microsoft vous recommande également d’utiliser .NET Standard au lieu de bibliothèques de classes portables .

Pour citer MSDN en tant que source faisant autorité, la norme .Net se veut une seule bibliothèque pour les gouverner toutes . Comme les images valent mille mots, les choses suivantes seront claires:

1. Votre scénario d’application actuel (fragmenté)

Comme la plupart d’entre nous, vous êtes probablement dans la situation ci-dessous: (.Net Framework, Xamarin et maintenant les applications aromatisées .Net Core)

entrer la description de l'image ici

2. Qu’est-ce que la bibliothèque .Net Standard vous permettra (compatibilité inter-framework)

L’implémentation d’une bibliothèque .Net standard permet le partage de code entre ces différentes versions:

Une bibliothèque pour les gouverner tous

Pour les impatients:

  1. .NET Standard résout le problème de partage de code pour les développeurs .NET sur toutes les plates-formes en apportant toutes les API que vous attendez de vos environnements: applications de bureau, applications et jeux mobiles et services cloud:
  2. .NET Standard est un ensemble d’API que toutes les plates formes .NET doivent implémenter . Cela unifie les platesformes .NET et empêche la fragmentation future .
  3. .NET Standard 2.0 sera implémenté par .NET Framework,. NET Core et Xamarin . Pour .NET Core , cela appenda plusieurs des API existantes qui ont été demandées.
  4. .NET Standard 2.0 inclut une cale de compatibilité pour les fichiers binarys .NET Framework , ce qui augmente considérablement le nombre de bibliothèques que vous pouvez référencer à partir de vos bibliothèques .NET Standard.
  5. .NET Standard remplacera les bibliothèques de classes portables (PCL) en tant qu’histoire d’outillage pour la création de bibliothèques .NET multi-plateformes.

Pour un tableau permettant de comprendre la version la plus élevée de .NET Standard que vous pouvez cibler, en fonction des plates-formes .NET sur lesquelles vous souhaitez exécuter, rendez-vous ici .

Sources: MSDN: Présentation de .Net Standard

Donc, la réponse courte serait:

 IAnimal == .NetStandard (General) ICat == .NetCore (Less General) IDog == .NetFramework (Specific / oldest and has the most features) 

.Net Framework et .Net Core sont deux implémentations différentes du runtime .Net. Core et Framework (mais surtout Framework) ont des profils différents qui incluent des sélections plus ou moins grandes (ou simplement différentes) des nombreuses API et assemblages créés par Microsoft pour .Net, en fonction de leur installation et de leur profil. Par exemple, il existe différentes API disponibles dans les applications Windows universelles que dans le profil Windows “normal”. Même sous Windows, vous pouvez avoir le profil “Client” par rapport au profil “Complet”. De plus, il existe d’autres implémentations (comme Mono) qui ont leurs propres ensembles de bibliothèques.

.Net Standard est une spécification pour laquelle des ensembles de bibliothèques et d’assemblages d’API doivent être disponibles. Une application écrite pour .Net Standard 1.0 devrait pouvoir être compilée et exécutée avec toute version de Framework, Core, Mono, etc., qui annonce la prise en charge de la collection de bibliothèques .Net Standard 1.0. La même chose est vraie pour .Net Standard 1.1, 1.5, 1.6, 2.0, etc. Tant que le moteur d’exécution prend en charge cette version de Standard, vous pouvez y comstackr et l’exécuter.

Un projet ciblé sur une version de Standard ne pourra pas utiliser les fonctionnalités qui ne sont pas incluses dans cette révision de la norme. Cela ne signifie pas que vous ne pouvez pas prendre de dépendances sur d’autres assemblys ou API publiées par d’autres fournisseurs (à savoir: des éléments sur NuGet). Mais cela signifie que toutes les dépendances que vous prenez doivent également inclure la prise en charge de votre version de .Net Standard. .Net Standard évolue rapidement, mais il est encore assez récent et se préoccupe suffisamment de certains des plus petits profils d’exécution, que cette limitation peut sembler étouffante.

D’un autre côté, une application ciblant Standard devrait pouvoir être utilisée dans d’autres situations de déploiement, car en théorie, elle peut fonctionner avec Core, Framework, Mono, etc. . Pour un projet de bibliothèque de classe utilisé principalement à des fins internes, il peut ne pas être aussi préoccupant.

.Net Standard peut également être utile dans les situations où l’équipe SysAdmin souhaite passer d’ASP.Net sous Windows à ASP.Net pour .Net Core sous Linux pour des raisons philosophiques ou de coûts, mais l’équipe de développement souhaite continuer à travailler contre .Net. Framework dans Visual Studio sous Windows.

.NET Standard: Considérez-le comme une grande bibliothèque standard. Lorsque vous utilisez ceci comme une dépendance, vous ne pouvez créer que des bibliothèques (.DLL), pas des exécutables. Une bibliothèque créée avec le standard .NET en tant que dépendance peut être ajoutée à un Xamarin.Android, un projet Xamarin.iOS, .NET Core Windows / OSX / Linux.

.NET Core: Pensez-y comme étant la continuation de l’ancien framework .NET, il n’y a que opensource et certaines choses ne sont pas encore implémentées et d’autres sont devenues obsolètes. Il étend la norme .NET avec des fonctions supplémentaires, mais ne fonctionne que sur les ordinateurs de bureau. Lorsque vous ajoutez cela en tant que dépendance, vous pouvez créer des applications exécutables sur Windows, Linux et OSX. (Bien que la console uniquement pour l’instant, pas d’interface graphique). Donc, .NET Core = .NET spécifiques.
UWP l’utilise également et le nouveau kernel ASP.NET l’utilise également comme dépendance.

La norme .Net existe principalement pour améliorer le partage de code et rendre les API disponibles dans chaque implémentation .Net plus cohérentes.

Lors de la création de bibliothèques, nous pouvons avoir pour cible as.Net Standard 2.0 afin que la bibliothèque créée soit compatible avec différentes versions de .Net Framework, y compris .Net Core, Mono ..

.NET Framework et .NET Core sont les deux frameworks.

La norme .NET est standard (autrement dit, la spécification).

Vous pouvez créer un projet exécutable (comme une application console ou une application ASP.NET) avec .NET Framework et .NET Core, mais pas avec .NET Standard.

Avec .NET Standard, vous pouvez uniquement créer un projet de bibliothèque de classes qui ne peut pas être exécuté de manière autonome et qui doit être référencé par un autre projet exécutable .NET Core ou .NET Framework.

J’espère que cela aidera à comprendre la relation entre la surface de l’API .NET Standard et d’autres plates-formes .NET . Chaque interface représente un framework cible et les méthodes représentent des groupes d’API disponibles sur ce framework cible.

 namespace Analogy { // .NET Standard interface INetStandard10 { void Primitives(); void Reflection(); void Tasks(); void Xml(); void Collections(); void Linq(); } interface INetStandard11 : INetStandard10 { void ConcurrentCollections(); void LinqParallel(); void Compression(); void HttpClient(); } interface INetStandard12 : INetStandard11 { void ThreadingTimer(); } interface INetStandard13 : INetStandard12 { //.NET Standard 1.3 specific APIs } // And so on ... // .NET Framework interface INetFramework45 : INetStandard11 { void FileSystem(); void Console(); void ThreadPool(); void Crypto(); void WebSockets(); void Process(); void Drawing(); void SystemWeb(); void WPF(); void WindowsForms(); void WCF(); } interface INetFramework451 : INetFramework45, INetStandard12 { // .NET Framework 4.5.1 specific APIs } interface INetFramework452 : INetFramework451, INetStandard12 { // .NET Framework 4.5.2 specific APIs } interface INetFramework46 : INetFramework452, INetStandard13 { // .NET Framework 4.6 specific APIs } interface INetFramework461 : INetFramework46, INetStandard14 { // .NET Framework 4.6.1 specific APIs } interface INetFramework462 : INetFramework461, INetStandard15 { // .NET Framework 4.6.2 specific APIs } // .NET Core interface INetCoreApp10 : INetStandard15 { // TODO: .NET Core 1.0 specific APIs } // Windows Universal Platform interface IWindowsUniversalPlatform : INetStandard13 { void GPS(); void Xaml(); } // Xamarin interface IXamarinIOS : INetStandard15 { void AppleAPIs(); } interface IXamarinAndroid : INetStandard15 { void GoogleAPIs(); } // Future platform interface ISomeFuturePlatform : INetStandard13 { // A future platform chooses to implement a specific .NET Standard version. // All libraries that target that version are instantly compatible with this new // platform } } 

La source