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

Question

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

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

Alors que la première est celle que nous utilisons depuis des années, un point de confusion majeur que j'ai rencontré est de savoir quand utiliser les types de bibliothèque de classe .NET Standard et .NET Core. J'ai été confronté à ce problème récemment lorsque j'ai essayé de Cibler plusieurs versions de cadres différents et création d'un projet de test unitaire .

Alors, quelle est la différence entre Bibliothèque de classes (.NET Standard) y Bibliothèque de classes (.NET Core) pourquoi les deux existent-ils, et quand faut-il utiliser l'un plutôt que l'autre ?

Answer 1

Quand faut-il utiliser l'un plutôt que l'autre ?

La décision est un compromis entre la compatibilité et l'accès aux API.

Utilisez une bibliothèque .NET Standard lorsque vous souhaitez augmenter le nombre d'applications compatibles avec votre bibliothèque et que vous acceptez 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 que vous acceptez que seules les applications .NET Core soient compatibles avec votre bibliothèque.

Par exemple, une bibliothèque qui cible la norme .NET 1.3 sera compatible avec qui ciblent .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 et toute autre plateforme prenant en charge la norme .NET 1.3. La bibliothèque n'aura cependant pas accès à certaines parties de l'API .NET. Par exemple, la bibliothèque 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 sur les cadres basés sur des paquets décrit la différence.

Compatibilité : Les bibliothèques qui ciblent la norme .NET s'exécuteront sur tout moteur d'exécution conforme à la norme .NET, comme .NET Core, .NET Framework, Mono/Xamarin. En revanche, les bibliothèques qui ciblent .NET Core ne peuvent s'exécuter que sur le moteur d'exécution .NET Core.

Surface de l'API : les bibliothèques .NET standard sont livrées avec tout ce qu'il faut dans le cadre de l'API. NETStandard.Library alors que les bibliothèques .NET Core sont livrées avec tout ce qu'il faut dans Microsoft.NETCore.App . Cette dernière comprend environ 20 bibliothèques supplémentaires, dont certaines peuvent être ajoutées manuellement à notre bibliothèque standard .NET (telles que System.Threading.Thread ) et dont certaines ne sont pas compatibles avec la norme .NET (telles que Microsoft.NETCore.CoreCLR ).

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

Pourquoi les deux existent-ils ?

Si l'on ignore un instant les bibliothèques, la raison d'être de la norme .NET est la portabilité ; elle définit un ensemble d'API que les plateformes .NET acceptent de mettre en œuvre. Toute plateforme qui met en œuvre une norme .NET est compatible avec les bibliothèques qui ciblent cette norme .NET. L'une de ces plateformes compatibles est .NET Core.

Pour en revenir aux bibliothèques, les modèles de bibliothèque .NET Standard existent pour s'exécuter sur plusieurs runtimes (au détriment de la surface de l'API). À l'inverse, les modèles de bibliothèque .NET Core permettent d'accéder à une plus grande surface d'API (au détriment de la compatibilité) et de spécifier une plate-forme sur laquelle construire un exécutable.

Answer 2

A Bibliothèque de classes de base .Net s'appuie sur le .Net Standard . Si vous souhaitez mettre en œuvre une bibliothèque qui soit portable sur le site de l Cadre .Net , . Net Core y Xamarin choisissez une Bibliothèque standard .Net

.Net Core mettra finalement en œuvre la norme .Net Standard 2 (comme le fera Xamarin y Cadre .Net )

.Net Core , Xamarin y Cadre .Net peut, par conséquent, être identifié comme saveurs de .Net Standard

Pour assurer l'avenir de vos applications en matière de partage et de réutilisation du code, il est préférable d'utiliser les bibliothèques standard .Net.

Microsoft recommande également d'utiliser Norme .NET au lieu de Bibliothèques de classes portables .

Pour citer MSDN comme une source faisant autorité, .Net Standard est destiné à être Une bibliothèque pour les gouverner toutes . Comme les images valent mille mots, ce qui suit rendra les choses très claires :

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

Comme la plupart d'entre nous, vous vous trouvez probablement dans la situation ci-dessous : (applications à la sauce .Net Framework, Xamarin et maintenant .Net Core)

2. Ce que la bibliothèque standard .Net vous permettra de faire (compatibilité inter-frames)

La mise en œuvre d'une bibliothèque standard .Net permet de partager le code entre toutes ces différentes versions :

Pour les impatients :

1. Norme .NET résout le problème du partage du code pour les développeurs .NET sur toutes les plateformes en apportant toutes les API que vous attendez et que vous appréciez dans les environnements dont vous avez besoin : applications de bureau, applications et jeux mobiles et services en nuage :
2. Norme .NET est un ensemble d'API que tous Plateformes .NET doivent mettre en œuvre . Ce site unifie les plateformes .NET y empêche toute fragmentation future .
3. .NET Standard 2.0 sera mis en œuvre par Cadre .NET , . NET Core , et Xamarin . Pour .NET Core cela permettra d'ajouter de nombreuses API existantes existantes qui ont été demandées.
4. .NET Standard 2.0 comprend une cale de compatibilité pour Cadre .NET ce qui augmente considérablement l'ensemble des bibliothèques que vous pouvez référencer à partir de vos bibliothèques standard .NET.
5. Norme .NET remplacera les bibliothèques de classe portables (PCL) comme la histoire d'outils pour la création de bibliothèques .NET multiplateformes.

Ce tableau vous aidera à comprendre quelle est la version la plus élevée de .NET Standard que vous pouvez cibler, en fonction des plateformes .NET sur lesquelles vous avez l'intention de travailler, rendez-vous ici .

Sources : MSDN : Introduction à la norme .Net

Answer 3

Donc la réponse courte serait :

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

Answer 4

Cadre .Net y .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 tout simplement différentes) des nombreuses API et assemblages créés par Microsoft pour .Net, en fonction de l'endroit où ils sont installés et du profil. Par exemple, les API disponibles dans les applications Windows universelles sont différentes de celles du profil Windows "normal". Même sous Windows, vous pouvez avoir le profil "Client" ou le profil "Complet". En outre, il existe d'autres implémentations (comme Mono) qui possèdent 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 n'importe quelle version de Framework, Core, Mono, etc., qui annonce la prise en charge de la collection de bibliothèques .Net Standard 1.0. Il en va de même pour .Net Standard 1.1, 1.5, 1.6, 2.0, etc. Tant que le moteur d'exécution prend en charge la version de Standard ciblée par votre programme, ce dernier devrait fonctionner.

Un projet ciblant 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 des dépendances sur d'autres assemblages, ou des APIs publiées par d'autres vendeurs (c'est-à-dire 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 la norme .Net. La norme .Net évolue rapidement, mais elle est encore assez récente et se préoccupe suffisamment de certains des plus petits profils d'exécution pour que cette limitation puisse sembler étouffante. (Note un an et demi plus tard : cela commence à changer, et les versions récentes de .Net Standard sont beaucoup plus agréables et complètes).

D'un autre côté, une application destinée à Standard debe pouvoir être utilisé dans davantage de situations de déploiement, puisqu'en théorie il peut fonctionner avec Core, Framework, Mono, etc. Pour un projet de bibliothèque de classes visant une large distribution, c'est une promesse attrayante. Pour un projet de bibliothèque de classes utilisé principalement à des fins internes, ce n'est pas forcément une préoccupation majeure.

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

Answer 5

.NET Framework et .NET Core sont tous deux des cadres.

.NET Standard est une norme (en d'autres termes, une 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 ne pouvez créer qu'un projet de classe-bibliothèque qui ne peut pas être exécuté de manière autonome et doit être référencé par un autre projet exécutable .NET Core ou .NET Framework.