Créer un package NuGet sur Linux qui cible .NET Framework

Vous pouvez simplement ajouter ce qui suit à votre fichier de projet :

  <ItemGroup Condition="$(TargetFramework.StartsWith('net4')) AND '$(MSBuildRuntimeType)' == 'Core' AND '$(OS)' != 'Windows_NT'">
    <PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0" PrivateAssets="All" />
  </ItemGroup>

Cela permettra de construire et d'emballer sur des systèmes non Windows pour .NET Framework.Mais vous ne pouvez exécuter que des cibles .NET Core à l'aide de dotnet CLI sur des systèmes non Windows. Vous devez donc également être prêt à sélectionner un framework cible à exécuter sur des systèmes non Windows, comme ceci :

dotnet run -f netcoreapp2.1

Source de la solution :https://github.com/dotnet/designs/pull/33#issuecomment-489264196. Il s'agit d'une solution de contournement, elle est donc susceptible d'être modifiée à l'avenir.

La distribution de l'interface de ligne de commande .NET ne contient aucun assembly de référence pour .NET Framework, de sorte que sa version de MSBuild ne peut pas résoudre les actifs nécessaires au moment de la compilation. Ce scénario est cependant suivi sur GitHub et a fonctionné avant la migration vers MSBuild (la CLI pourrait utiliser les assemblys de référence de mono).

Il existe cependant quelques alternatives qui peuvent être utilisées pour créer votre bibliothèque sur des machines non Windows :

1. Utilisez mono 5+ pour construire la bibliothèque.

C'est probablement le chemin le plus stable.

Mono 5 et supérieur contient la logique de génération nécessaire pour créer des applications .NET Standar et .NET Core. Sous Linux, le msbuild de mono peut devoir être installé en tant que package séparé. Ainsi, au lieu des commandes couramment utilisées suivantes

dotnet restore
dotnet build
dotnet publish -c Release

vous utiliseriez le msbuild de mono pour faire ce qui suit :

msbuild /t:Restore
msbuild
msbuild /t:Publish /p:Configuration=Release

Solution de contournement du pack pour mono < 5.2 :

La seule limitation est que mono (<5.2) ne peut pas produire de packages NuGet prêts à l'emploi, mais il existe une solution de contournement impliquant l'utilisation du NuGet.Build.Tasks.Pack Package NuGet dans le projet qui vous permet de faire msbuild /t:Pack /p:Configuration=Release en modifiant le fichier projet comme ceci (notez en particulier le Sdk="..." supprimé attribut sur le <Project> élément):

<Project>
  <PropertyGroup>
    <NuGetBuildTasksPackTargets>junk-value-to-avoid-conflicts</NuGetBuildTasksPackTargets>
  </PropertyGroup>
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />

  <!-- All your project's other content here -->

  <ItemGroup>
    <PackageReference Include="NuGet.Build.Tasks.Pack" Version="4.0.0" PrivateAssets="All" />
  </ItemGroup>
  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

2. Utilisez la CLI .NET et dites à MSBuild d'utiliser les assemblys de référence de mono.

Lors de la construction pour net* cadres cibles, vous pouvez définir le FrameworkPathOverride propriété à la fois en tant que variable d'environnement ou en tant que propriété dans le fichier csproj. Il doit pointer vers un ensemble d'assemblages de référence - les assemblages de référence de mono peuvent être utilisés ici. Mais certains contiennent un fichier spécial (liste redist) contenant des références à d'autres répertoires que la version MSBuild dans la CLI .NET ne peut pas suivre. Cela fonctionne cependant dans de nombreux scénarios :

export FrameworkPathOverride=/usr/lib/mono/4.5/
dotnet build -f net45

Cela a été utilisé et documenté par l'équipe F#.

3. Utilisez un package NuGet contenant des assemblys de référence.

Sur certains flux MyGet, Microsoft publie des packages NuGet contenant des assemblys de référence. Ils ne sont pas publiés ou "officiels", donc ce processus peut échouer à un moment donné. Cependant, ils prévoient d'enquêter pour officialiser cette voie.

Créez d'abord un fichier NuGet.Config dans le répertoire de votre solution avec le contenu suivant pour ajouter le flux :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <packageSources>
    <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
 </packageSources>
</configuration>

Ensuite, vous pouvez ajouter un groupe d'articles pour ajouter le PackageReference à un pack de ciblage et un PropertyGroup pour définir le chemin vers les assemblys de référence comme ceci :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp1.1;net461</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup Condition=" '$(TargetFramework)' == 'net461' ">
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
    <FrameworkPathOverride>$(NuGetPackageFolders)microsoft.targetingpack.netframework.v4.6.1\1.0.1\lib\net461\</FrameworkPathOverride>
  </PropertyGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
    <PackageReference Include="Microsoft.TargetingPack.NETFramework.v4.6.1" Version="1.0.1" ExcludeAssets="All" PrivateAssets="All" />
  </ItemGroup>

</Project>

Vous pouvez modifier le RuntimeIdentifier pour différentes plates-formes si vous utilisez des ressources natives (par exemple, pour obtenir .so fichiers pour Linux) ou supprimez-le entièrement lors de la création de bibliothèques.