Comment multi-ciblez-vous une bibliothèque de classes .NET Core avec csproj?

Lorsque .NET Core utilisait toujours le format project.json , vous pouviez créer une bibliothèque de classes ciblant plusieurs infrastructures (par exemple, net451, netcoreapp1.0).

Maintenant que le format de projet officiel est csproj utilisant MSBuild, comment spécifiez-vous plusieurs frameworks à cibler? J’essaie de rechercher cela depuis les parameters du projet dans VS2017, mais je ne peux cibler qu’un seul framework à partir des frameworks .NET Core (il ne répertorie même pas les autres versions complètes de .NET Framework que j’ai installées) :

entrer la description de l'image ici

Vous devez append le composant TargetFramework par défaut et le remplacer par TargetFrameworks . Ensuite, vous mentionnez le Moniker avec un ; séparateur.

Vous pouvez également placer les références du package Nuget dans un ItemGroup conditionnel manuellement ou à l’aide du gestionnaire de packages VS Nuget.

Voici à quoi devrait ressembler votre fichier .csproj:

   netstandard1.6;net452    1.12.0     1.1.0    

Une autre solution de contournement que je fais aujourd’hui en raison de la documentation manquante est que je crée un projet dans VS2015 et que je crée project.json en utilisant la documentation disponible et intellisense, puis ouvre la solution dans VS2017 et utilise la mise à niveau intégrée. Je vais ensuite regarder le fichier csproj pour savoir comment faire en sorte que cette configuration se produise.

Multi-ciblage de cibles plus ésotériques sans Moniker :

Microsoft:

Les PCL ne sont pas recommandés +

Bien que les PCL soient pris en charge, les auteurs de packages doivent plutôt prendre en charge netstandard. Le standard de plate-forme .NET est une évolution des PCL et représente la portabilité binary sur les plates-formes en utilisant un seul moniker qui n’est pas lié à un statique comme les monikeurs portables-a + b + c.

Si vous souhaitez cibler un profil portable, celui-ci ne possède pas de moniker prédéfini, de sorte que les profils portables ne peuvent également pas inférer TargetFrameworkIdentifier , TargetFrameworkVersion et TargetFrameworkProfile . De plus, une constante du compilateur n’est pas définie automatiquement. Enfin, vous devez append toutes les références d’assemblage qui ne sont pas fournies par défaut.

Cet exemple ci-dessous est tiré d’un projet utilisant le mot-clé dynamic afin qu’il nécessite en plus l’assembly Microsoft.CSharp , vous pouvez donc voir comment il fait référence à différentes cibles.

   netstandard1.5;net40;portable40-net45+sl5+win8+wp8   .NETPortable v4.0 Profile158 $(DefineConstants);PORTABLE158                

Vous pouvez modifier manuellement le fichier .csproj pour cela et définir la TargetFrameworks (pas TargetFramework ).

 net451;netstandard1.4 

Par exemple, consultez EFCore.csproj : https://github.com/aspnet/EntityFrameworkCore/blob/951e4826a38ad5499b9b3ec6645e47c825fa842a/src/EFCore/EFCore.csproj

J’ai en fait sélectionné Class Library (.NET Core).

Ce n’est pas le modèle de projet que vous souhaitez si votre bibliothèque doit fonctionner sur plusieurs cibles de plate-forme. Avec ce modèle de projet, votre bibliothèque ne peut être utilisée que dans un projet ciblant .NETCore. L’approche de la bibliothèque PCL a été retirée, vous devez maintenant choisir une .NETStandard.

Vous le faites en démarrant le projet avec le modèle de projet “Class Library (.NET Standard)”. Vous avez maintenant la possibilité de choisir la version .NETStandard. La grid de compatibilité actuelle est ici .

J’espère qu’ils garderont cet article lié mis à jour. Ceci est en pleine mutation. NETStandard 2.0 a été cloué mais ne sera pas livré. Ciblé pour le deuxième sortingmestre de 2017, fin du spring probablement, il montre actuellement que 97% ont été réalisés. J’ai entendu les concepteurs dire que l’utilisation de 1.5 ou 1.6 n’est pas recommandée, pas assez compatible avec 2.0