web-dev-qa-db-fra.com

Comment multi-cibler 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 frameworks (par exemple, net451, netcoreapp1.0).

Maintenant que le format de projet officiel est csproj avec MSBuild, comment spécifiez-vous plusieurs frameworks à cibler? J'essaie de chercher cela dans les paramètres 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 du .NET Framework que I ont installé):

enter image description here

c#msbuild.net-corevisual-studio-2017csproj
76
Gigi

Vous devez modifier manuellement le fichier de projet et ajouter s au paramètre par défaut TargetFramework et changez le 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 à l'aide de 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 que je fais ces jours-ci à cause de la documentation manquante est que je crée un projet dans VS2015 et forme le fichier project.json en utilisant la documentation disponible et intellisense, puis que j'ouvre la solution dans VS2017 et utilise la mise à niveau intégrée. Je regarderai ensuite le fichier csproj pour comprendre comment réaliser cette configuration.

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

Microsoft:

Les PCL ne sont pas recommandés +

Bien que les PCL soient pris en charge, les auteurs de paquets devraient plutôt prendre en charge netstandard. La plate-forme .NET Standard est une évolution des PCL et représente la portabilité binaire entre plates-formes utilisant un moniker unique 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 moniker prédéfini . Par conséquent, les profils portables ne peuvent pas non plus déduire TargetFrameworkIdentifier, TargetFrameworkVersion et TargetFrameworkProfile. De plus, une constante du 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 provient d'un projet qui utilisait le mot clé dynamic. Il avait donc également besoin de l'assembly Microsoft.CSharp. Vous pouvez ainsi voir comment il fait référence à 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>
97
Aboo

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

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

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

22
Night walker

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 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 "Class Library (.NET Standard)". Vous avez maintenant la possibilité de choisir la version .NETStandard. La grille de compatibilité actuelle est ici .

Espérons qu'ils garderont cet article lié mis à jour. Ceci est en pleine mutation, .NETStandard 2.0 a été cloué mais n’a pas encore été expédié. Cible pour le deuxième trimestre de 2017, probablement à la fin du printemps, il est actuellement établi à 97%. J'ai entendu les concepteurs dire qu'utiliser 1.5 ou 1.6 n'est pas recommandé, pas assez compatible avec 2.0

11
Hans Passant

J'ai fait un guide du débutant sur le framework net et le netcore multi-ciblage .

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

  1. En savoir plus sur les sections conditionnelles dans 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 />s pour System. * Dll pour toutes les cibles netframework simplement en lisant ce qui est manquant dans les messages d'erreur de génération.
  3. Traitez les dépendances NuGet <PackageReference />s dans les cas où elles ne sont pas les mêmes pour chaque cible. L'astuce la plus simple consiste à revenir temporairement à l'objectif unique afin que l'interface graphique gère correctement les références Nuget.
  4. Traitez un code qui ne 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 d’ajout d’objectifs est trop élevé.
2
Chris F Carroll