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

815

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)

Bien que le premier soit ce que nous utilisons depuis des années, un point de confusion majeur que j'ai eu est quand utiliser les types de bibliothèque de classes .NET Standard et .NET Core. J'ai récemment été mordu par cela lors d'une tentative de multi-cible de différentes versions de framework et de la création d'un projet de test unitaire .

Alors, quelle est la différence entre la bibliothèque de classes (.NET Standard) et la bibliothèque de classes (.NET Core) , pourquoi les deux existent-elles et quand devrions-nous les utiliser l'une par rapport à l'autre?

Gigi
la source
10
Vous en avez manqué une: la bibliothèque de classes (portable). Core == framework, .NET Standard == portable.
Hans Passant
4
Il y en avait un de Xamarin aussi, mais ces autres n'ajoutent aucune valeur à la question :)
Gigi
7
Eh bien, ils le font. L'idée centrale est qu'ils ont abandonné l'approche portable, elle a trop souffert du n! problème avec beaucoup trop de profils. Alors maintenant, vous avez le choix entre 7 normes. La plupart ne sont pas réellement portables pour le moment :) .NETCore ne se fait pas à long terme, cela prend probablement encore deux ans au clip où ils vont.
Hans Passant
12
OP a dit "au moins 3 types différents". Le message était exact.
Dan Friedman
1
J'ai été confus par la dénomination de Core qui n'est pas un sous-ensemble de base ni de la plateforme Standard ni de la plateforme Framework. Nous voyons également régulièrement des ASP associés à .Net Core. C'est aussi très déroutant ...
Alexis Pautrot

Réponses:

612

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

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

Utilisez une bibliothèque .NET Standard lorsque vous souhaitez augmenter le nombre d'applications qui seront compatibles avec votre bibliothèque et que vous êtes d'accord avec 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 vous êtes d'accord avec autoriser uniquement les applications .NET Core à être compatible avec votre bibliothèque.

Par exemple, une bibliothèque qui cible .NET Standard 1.3 sera compatible avec les applications qui ciblent .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 et toute autre plate-forme qui prend en charge .NET Standard 1.3. Cependant, la bibliothèque n'aura pas accès à certaines parties de l'API .NET. Par exemple, le Microsoft.NETCore.CoreCLRpackage est compatible avec .NET Core mais pas avec .NET Standard.

Quelle est la différence entre la bibliothèque de classes (.NET Standard) et la bibliothèque de classes (.NET Core)?

La section Framework basée sur les packages décrit la différence.

Compatibilité: les bibliothèques qui ciblent .NET Standard s'exécuteront sur n'importe quel environnement d'exécution compatible .NET Standard, tel que .NET Core, .NET Framework, Mono / Xamarin. En revanche, les bibliothèques qui ciblent .NET Core ne peuvent s'exécuter que sur le runtime .NET Core.

Surface de l'API: les bibliothèques .NET Standard sont livrées avec tout, NETStandard.Librarytandis que les bibliothèques .NET Core sont livrées avec tout Microsoft.NETCore.App. Ce dernier comprend environ 20 bibliothèques supplémentaires, dont certaines que nous pouvons ajouter manuellement à notre bibliothèque .NET Standard (telles queSystem.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 runtime et sont fournies avec un modèle d'application. C'est important, par exemple, pour rendre exécutables les bibliothèques de classes de tests unitaires.

Pourquoi les deux existent-ils?

Ignorant les bibliothèques pendant un moment, la raison pour laquelle .NET Standard existe est pour la portabilité; il définit un ensemble d'API que les plateformes .NET acceptent de mettre en œuvre. Toute plate-forme qui implémente un standard .NET est compatible avec les bibliothèques qui ciblent ce standard .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). Inversement, les modèles de bibliothèque .NET Core existent pour accéder à davantage de surface API (au détriment de la compatibilité) et pour spécifier une plate-forme sur laquelle construire un exécutable.

Voici une matrice interactive qui montre quel .NET Standard prend en charge quelle (s) implémentation (s) .NET et quelle surface d'API est disponible.

Shaun Luttin
la source
2
Très bonne réponse. Une question supplémentaire (se rapporte à cette question : pourquoi un modèle d'application est-il nécessaire pour exécuter des tests unitaires? Cela n'a jamais été le cas par le passé, lorsque nous avons utilisé des bibliothèques de classes non exécutables pour contenir des collections de tests unitaires.
Gigi
3
J'ai mis à jour ma réponse à la question liée. TL; DR; Dans le passé, les bibliothèques de classes ciblaient le cadre complet, qui comprend un modèle d'application.
Shaun Luttin
Vous avez oublié de couvrir la bibliothèque de classes (.NET Framework), est-elle compatible avec .NET Standard et .NET Core?
Tomas
8
Ce diagramme m'a vraiment aidé à l'obtenir.
jpaugh
1
@BerBar La question initiale portait sur la différence entre .NET Standard et .NET Core. C'est pourquoi j'ai omis les détails multiplate-forme, car la multiplicité des plates-formes n'est pas une différence entre Core et Standard. J'ai intentionnellement gardé ma réponse limitée à la question d'origine.
Shaun Luttin
396

Une bibliothèque de classes .NET Core est basée sur la norme .NET . Si vous souhaitez implémenter une bibliothèque qui est 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 )

.NET Core , Xamarin et .NET Framework peuvent donc être identifiés comme des versions de .NET Standard

Pour pérenniser vos applications de partage et de réutilisation de code, vous préférez implémenter les bibliothèques .NET Standard.

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

Pour citer MSDN en tant que source faisant autorité, .NET Standard est destiné à être une bibliothèque pour les gouverner tous . Comme les images valent mille mots, ce qui suit clarifiera les choses:

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

Comme la plupart d'entre nous, vous êtes probablement dans la situation ci-dessous: (applications .NET Framework, Xamarin et maintenant .NET Core)

Entrez la description de l'image ici

2. Ce que la bibliothèque standard .NET vous permettra (compatibilité inter-framework)

L'implémentation d'une bibliothèque standard .NET permet le partage de code entre toutes 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 plateformes en intégrant toutes les API que vous attendez et appréciez dans les environnements dont vous avez besoin: 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 plates - formes .NET et empêche la fragmentation future .
  3. .NET standard 2.0 sera mis en œuvre par .NET Framework ,. NET Core et Xamarin . Pour .NET Core , cela ajoutera de nombreuses API existantes qui ont été demandées.
  4. .NET Standard 2.0 inclut un module d'interface de compatibilité pour les binaires .NET Framework , augmentant considérablement l'ensemble 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) comme histoire d'outils pour la création de bibliothèques .NET multiplateformes.

Pour un tableau qui vous aidera à comprendre la version la plus élevée de .NET Standard que vous pouvez cibler, en fonction des plates-formes .NET sur lesquelles vous prévoyez de fonctionner, rendez-vous ici .

Sources: MSDN: Présentation de .NET Standard

user919426
la source
2
ASP.NET Core est un peu mal placé dans ce graphique, car il peut être utilisé avec le .NET Framework complet, pas seulement .NET Core, car il cible réellement .NET Standard.
Neme
2
Mais vous pouvez créer une application ASP.NET Core avec le .NET Framework complet - ASP.NET Core appartient vraiment à la même couche que .NET Standard. Il n'est pas limité à .NET Core uniquement.
Neme
1
@Neme Premièrement, oui .Net Core peut inclure des bibliothèques .Net Framework mais perd la réutilisation multiplateforme (uniquement pour Windows - pas * nix ou OSX, ou réutilisation dans Xamarin). Une situation qui a été prise en compte étant donné que beaucoup ont et veulent réutiliser les bibliothèques existantes écrites dans le cadre complet de Net sans intérêt pour les avantages multiplateformes (niveau OS et niveau App-Model) ... Si vous pensez toujours que je suis faux, vous pouvez peut-être discuter avec Microsoft, qui a créé ces images ... :-)
user919426
3
Je ne parle pas de combiner .NET Core et .NET Framework. Mon point est qu'ASP.NET Core ne dépend pas du tout de .NET Core, malgré son nom. Il est écrit comme une bibliothèque qui cible .NET Standard, vous pouvez donc l'utiliser partout où vous pouvez utiliser .NET Standard. Oui, ils ont fait une erreur dans cette image.
Neme
2
@OgrishMan Vous ne pouvez pas créer d'exécutable dans .Net Standard . Il ne peut s'agir que d'une bibliothèque de classes, qui peut être référencée par un autre code d'exécution. Il n'a pas d'exécution .
user919426
91

Donc, la réponse courte serait:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)
Joe
la source
26
@ Joe.wang comme je le vois, il est mauvais que cela gâche la relation entre .NET Core et .NET Framework. Si .NET Core est l'oiseau, alors .NET Framework ne peut pas être l'aigle (peut-être que cat est plus approprié).
Lex Li
8
@LexLi a raison, cela embrouille les eaux. .NET Framework n'est pas un sous-type de .NET Core.
Eric Eskildsen
6
cela peut sembler un peu fantaisiste mais pas précis
afr0
3
Le commentaire original de @Joe semblait plus précis. la réponse modifiée par la communauté a rendu la confusion
Nandun
7
Les chiens ont plus de fonctionnalités que les chats? Nop :)
hrzafer
71

.NET 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 grandes ou plus petites (ou tout simplement différentes) des nombreuses API et assemblages que Microsoft a créés pour .NET, selon l'endroit où ils sont installés et dans quel 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, et 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 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 runtime prend en charge la version de Standard ciblée par votre programme, votre programme doit y fonctionner.

Un projet ciblant une version de la norme ne pourra pas utiliser des 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 sur des API publiées par d'autres fournisseurs (par exemple, 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 nouveau et se soucie suffisamment de certains des plus petits profils d'exécution, que cette limitation peut sembler étouffante. (Remarque un an et demi plus tard: cela commence à changer, et les versions récentes de .NET Standard sont beaucoup plus agréables et plus complètes).

En revanche, une application destinée à Standard devrait pouvoir être utilisée dans plus de situations de déploiement, car en théorie, elle peut fonctionner avec Core, Framework, Mono, etc. Pour un projet de bibliothèque de classe à la recherche d'une large distribution, c'est une promesse intéressante . Pour un projet de bibliothèque de classe utilisé principalement à des fins internes, cela peut ne pas être autant une préoccupation.

.NET Standard peut également être utile dans les situations où l'équipe de l'administrateur système souhaite passer d'ASP.NET sur Windows à ASP.NET pour .NET Core sur Linux pour des raisons philosophiques ou financières, mais l'équipe de développement souhaite continuer à travailler contre. NET Framework dans Visual Studio sur Windows.

Joel Coehoorn
la source
1
Bien qu'un bon aperçu de ce que sont .NET Core et .NET Standard, cette réponse ne répond pas à la question sur les bibliothèques de classes ciblant chacune d'entre elles.
Gigi
6
Si tel est votre objectif, la question doit être fermée sous la forme soit "pas clair ce que vous demandez", car il y aura toujours trop de spécificités situationnelles qui jouent dans l'environnement d'une personne donnée pour que nous vous disions quoi faire , ou comme "Trop large" si vous posez des questions sur le cas général. Tout ce que nous pouvons faire ici est de vous donner des informations sur les produits, afin que vous puissiez être informé pour prendre votre propre décision.
Joel Coehoorn
Ce n'est clairement pas le cas, car un autre a répondu avec précision à la question. Ma question concernait les bibliothèques de classes. Votre réponse portait sur les cadres.
Gigi
29

.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 bibliothèque de classes 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.

bside
la source
20

J'espère que cela vous aidera à comprendre la relation entre la surface de l'API standard .NET et les autres plates-formes .NET . Chaque interface représente un cadre cible et les méthodes représentent des groupes d'API disponibles sur ce cadre 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

Mahbubur Rahman
la source
17

Une autre façon d'expliquer la différence pourrait être avec des exemples du monde réel, car la plupart d'entre nous, les mortels, utiliseront les outils et les cadres existants (Xamarin, Unity, etc.) pour faire le travail.

Ainsi, avec .NET Framework, vous disposez de tous les outils .NET mais vous ne pouvez cibler que les applications Windows (UWP, Winforms, ASP.NET, etc.). Étant donné que .NET Framework est une source fermée, il n'y a pas grand-chose à faire à ce sujet.

Avec .NET Core, vous disposez de moins d'outils, mais vous pouvez cibler les principales plates-formes de bureau (Windows, Linux, Mac). Ceci est particulièrement utile dans les applications ASP.NET Core, car vous pouvez désormais héberger Asp.net sous Linux (prix d'hébergement moins chers). Maintenant, puisque .NET Core était open source, il est techniquement possible de développer des bibliothèques pour d'autres plates-formes. Mais comme il n'y a pas de frameworks qui le supportent, je ne pense pas que ce soit une bonne idée.

Avec .NET Standard, vous avez encore moins d'outils mais vous pouvez cibler toutes / la plupart des plateformes. Vous pouvez cibler Mobile grâce à Xamarin, et vous pouvez même cibler les consoles de jeu grâce à Mono / Unity. Mise à jour: Il est également possible de cibler des clients Web avec la plate-forme UNO et Blazor (bien que les deux soient un peu expérimentaux en ce moment).

Dans une application réelle, vous devrez peut-être les utiliser tous. Par exemple, j'ai développé une application de point de vente qui avait l'architecture suivante:

Serveur et client partagés:

  • Une bibliothèque .NET Standard qui gère les modèles de mon application.
  • Une bibliothèque .NET Standard qui gère la validation des données envoyées par les clients.

Puisqu'il s'agit d'une bibliothèque .NET Standard, elle peut être utilisée dans n'importe quel autre projet (client et serveur).

C'est également un bon avantage d'avoir la validation sur une bibliothèque standard .NET car je peux être sûr que la même validation est appliquée sur le serveur et le client. Le serveur est obligatoire, tandis que le client est facultatif et utile pour réduire le trafic.

Côté serveur (API Web):

  • Une bibliothèque .NET Standard (qui pourrait également être Core) qui gère toutes les connexions à la base de données.

  • Un projet .NET Core qui gère l'API Rest et utilise la bibliothèque de bases de données.

Comme cela est développé dans .NET Core, je peux héberger l'application sur un serveur Linux.

Côté client (MVVM avec WPF + Xamarin.Forms Android / IOS):

  • Une bibliothèque .NET Standard qui gère la connexion de l'API client.

  • Une bibliothèque .NET Standard qui gère la logique ViewModels. Utilisé dans toutes les vues.

  • Une application .NET Framework WPF qui gère les vues WPF pour une application Windows. Mise à jour: les applications WPF peuvent désormais être .NET core, bien qu'elles ne fonctionnent actuellement que sur Windows. AvaloniaUI est une bonne alternative pour créer des applications GUI de bureau pour d'autres plates-formes de bureau.

  • Une bibliothèque .NET Standard qui gère les vues Xamarin Forms.

  • Un projet Xamarin Android et Xamarin IOS.

Vous pouvez donc voir qu'il y a un grand avantage ici du côté client de l'application, car je peux réutiliser les deux bibliothèques .NET Standard (API client et ViewModels) et simplement faire des vues sans logique pour les applications WPF, Xamarin et IOS.

Dev Kevin
la source
2
Je pense que c'est une meilleure réponse car elle intègre le monde réel.
J Weezy
12

.NET Standard: Considérez-le comme une grande bibliothèque standard. Lorsque vous l'utilisez comme 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 comme dépendance peut être ajoutée à un Xamarin.Android, un Xamarin.iOS, un projet .NET Core Windows / OS X / Linux.

.NET Core: Considérez-le comme la continuation de l'ancien framework .NET, juste son open source et certaines choses ne sont pas encore implémentées et d'autres sont obsolètes. Il étend le standard .NET avec des fonctions supplémentaires, mais il ne fonctionne que sur les bureaux . Lorsque vous ajoutez cela en tant que dépendance, vous pouvez créer des applications exécutables sur Windows, Linux et OS X. (Bien que la console ne soit pour l'instant, pas d'interface graphique). Donc .NET Core = .NET Standard + trucs spécifiques au bureau.

Aussi UWP utilise et le nouveau ASP.NET de base utilise comme une dépendance aussi.

Peter Mortensen
la source
8

.NET Standard 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 la cible en tant que .NET Standard 2.0 afin que la bibliothèque créée soit compatible avec différentes versions de .NET Framework, notamment .NET Core, Mono , etc.

ARP
la source
2

Les réponses ci-dessus peuvent décrire la meilleure compréhension de la différence entre le noyau net, le standard net et le cadre net, donc je veux juste partager mon expérience en choisissant ceci plutôt que cela.

Dans le projet que vous devez mélanger entre .NET Framework, .NET Core et .NET Standard. Par exemple, au moment où nous construisons le système avec .NET Core 1.0, il n'y a pas de support pour l'hébergement de services Windows avec .net core.

La raison suivante est que nous utilisions Active Report qui ne prend pas en charge .NET Core. Nous voulons donc créer une bibliothèque d'infrastructure qui peut être utilisée à la fois pour .NET Core (asp.net core) et Windows Service and Reporting (.NET Framework) -> C'est pourquoi nous avons choisi .NET Standard pour ce type de bibliothèque. Choisir la norme .NET signifie que vous devez considérer attentivement chaque classe de la bibliothèque doit être simple et croisée .NET (noyau, framework, standard).

Conclusion:

  • .NET Standard pour la bibliothèque d'infrastructure et commun partagé. Cette bibliothèque peut être référencée par .NET Framework et .NET Core.
  • .NET Framework pour les technologies non prises en charge comme Active Report, Window Services (désormais compatible avec .NET 3.0).
  • .NET Core pour ASP.NET Core bien sûr.

Microsoft vient d'annoncer .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/

toannm
la source
@Gigi Veuillez lire attentivement ma réponse, j'ai dit que c'était lorsque .NET Core dans une version 1.0 et dans ce cas, nous voulons concevoir une solution pour combiner à la fois .NET Core et .NET Framework. ASP.NET Core prend en charge .NET Framework à partir de la version 2.0 ci-dessus. Ma réponse est une histoire lorsque vous devez gérer plusieurs versions de .NET. Je ne comprends donc pas pourquoi vous avez un downvote lorsque vous ne comprenez pas correctement la situation.
toannm
Merci pour votre réponse - j'ai lu votre réponse et j'ai lu la partie où vous avez fait référence à .NET Core 1.0. Pourtant, je n'ai pas considéré cela comme une condition préalable à l'interprétation de vos conclusions, ce qui, sinon, induirait les gens en erreur avec la version actuelle. De plus, il semble que mon commentaire ait été annulé par la police de Stack Overflow, ce qui est une honte à laquelle je me suis habitué sur ce site.
Gigi
0

Les formulaires Windows .NET Framework , ASP.NET et WPF doivent être développés à l'aide de la bibliothèque .NET Framework

Les applications .NET Standard Xamarin, IOs et MAC OSx doivent être dévopées à l'aide de la bibliothèque .NET Standard


La plateforme Windows universelle (UWP) .NET Core et l'application Linux doivent être développées à l'aide de la bibliothèque .NET Core. L'API est implémentée en C ++ et vous pouvez utiliser C ++, VB.NET, C #, F # et Javascript languages.NET

Fabio Panzironi
la source
0

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

Ömer Özkan
la source
Votre réponse n'est pas entièrement liée à la question. veuillez réviser
Programmeur Avid