Comment cibler plusieurs fois une bibliothèque de classes .NET Core avec csproj?

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

Maintenant que le format de projet officiel csprojutilise MSBuild, comment spécifier plusieurs frameworks à cibler? Je suis en train de chercher ce billet depuis les paramètres du projet dans VS2017, mais je suis en mesure de cibler seulement un cadre unique à partir des cadres de base .NET (il ne liste même pas les autres versions complètes .NET Framework que je ne l' ai installé) :

Vous devez modifier manuellement le fichier de projet et ajouter des s au TargetFramework par défaut et le changer essentiellement en TargetFrameworks . Ensuite, vous mentionnez le Moniker avec un ; séparateur.

Vous pouvez également placer les références de package Nuget dans un ItemGroup conditionnel manuellement ou en utilisant VS Nuget Package Manager.

Voici à quoi devrait ressembler votre .csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'net452'">
    <PackageReference Include="Microsoft.Azure.DocumentDB">
      <Version>1.12.0</Version>
    </PackageReference>
  </ItemGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netstandard1.6'">
    <PackageReference Include="Microsoft.Azure.DocumentDB.Core">
    <Version>1.1.0</Version>
    </PackageReference>
  </ItemGroup>
</Project>

Une autre solution de contournement que je fais ces jours-ci en raison d'une documentation manquante est que je crée un projet dans VS2015 et forme le project.json en utilisant la documentation disponible et intellisense, puis j'ouvre la solution dans VS2017 et j'utilise la mise à niveau intégrée. Je vais ensuite regarder le fichier csproj pour comprendre comment réaliser cette configuration.

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 prendre en charge netstandard à la place. La norme de plate-forme .NET est une évolution des PCL et représente la portabilité binaire entre les plates-formes en utilisant un seul surnom qui n'est pas lié à une statique comme les monikers portable-a + b + c.

Si vous souhaitez cibler un profil portable , il n'a pas de prédéfini moniker donc les profils portables aussi ne peut donc conclure TargetFrameworkIdentifier, TargetFrameworkVersionet TargetFrameworkProfile. De plus, une constante de compilateur n'est pas définie automatiquement. Enfin, vous devez ajouter toutes les références d'assemblage, aucune n'est fournie par défaut.

Cet exemple ci-dessous est tiré d'un projet qui a utilisé le dynamicmot - clé, donc il avait en plus besoin de l' Microsoft.CSharpassemblage, vous pouvez ainsi voir comment il est référencé pour différentes cibles.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.5;net40;portable40-net45+sl5+win8+wp8</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup Condition="'$(TargetFramework)'=='portable40-net45+sl5+win8+wp8'">
    <TargetFrameworkIdentifier>.NETPortable</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <TargetFrameworkProfile>Profile158</TargetFrameworkProfile>
    <DefineConstants>$(DefineConstants);PORTABLE158</DefineConstants>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)'=='netstandard1.5'">
    <PackageReference Include="Microsoft.CSharp" Version="4.3.0" />
    <PackageReference Include="System.ComponentModel" Version="4.3.0" />
  </ItemGroup>

  <ItemGroup Condition="'$(TargetFramework)'=='net40'">
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>

  <ItemGroup Condition="'$(TargetFramework)'=='portable40-net45+sl5+win8+wp8'">
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="System.Windows" />
  </ItemGroup>
</Project>

Vous pouvez modifier manuellement le .csprojfichier pour cela et définir TargetFrameworks(non TargetFramework) la propriété.

<TargetFrameworks>net451;netstandard1.4</TargetFrameworks>

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

J'ai en fait sélectionné Bibliothèque de classes (.NET Core).

Ce n'est pas le modèle de projet souhaité si votre bibliothèque doit fonctionner sur plusieurs plates-formes cibles. Avec ce modèle de projet, votre bibliothèque ne peut être utilisée que dans un projet qui cible .NETCore. L'approche de la bibliothèque PCL a été retirée, vous devez maintenant choisir un .NETStandard.

Pour ce faire, démarrez le projet avec le modèle de projet «Bibliothèque de classes (.NET Standard)». Vous avez maintenant la possibilité de choisir la version .NETStandard. La grille de compatibilité actuelle est ici .

J'espère qu'ils garderont cet article lié à jour. Ceci est en évolution, .NETStandard 2.0 a été cloué mais n'est pas encore disponible. Ciblé pour le deuxième trimestre de 2017, fin du printemps probablement, il indique 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

J'ai fait un guide du débutant sur le framework de réseau multi-ciblage et netcore qui commence par le correctif simple en 1 ligne, puis vous guide à travers chacune des complications.

L'approche la plus simple consiste à faire fonctionner en premier une cible netcore ou netstandard. Modifiez ensuite le fichier csproj et suivez ces étapes pour les autres cibles.

1. Découvrez les sections conditionnelles de votre fichier csproj, afin de pouvoir déclarer différentes dépendances pour chaque cible. Créez des sections conditionnelles pour chaque cible.
2. Ajoutez <Reference />spour System. * Les dll pour toutes les cibles de réseau en lisant simplement ce que les messages d'erreur de construction disent qu'il manque.
3. Traitez les dépendances NuGet <PackageReference />sdans les cas où elles ne sont pas les mêmes pour chaque cible. L'astuce la plus simple est de revenir temporairement au ciblage unique afin que l'interface graphique gère correctement les références Nuget pour vous.
4. Traitez du code qui ne se compile pas sur toutes les cibles, en apprenant une variété créative de techniques, de solutions de contournement et de gains de temps.
5. Sachez quand réduire vos pertes lorsque le coût de l'ajout de cibles supplémentaires est trop élevé.