Puoi semplicemente aggiungere quanto segue al tuo file di progetto:
<ItemGroup Condition="$(TargetFramework.StartsWith('net4')) AND '$(MSBuildRuntimeType)' == 'Core' AND '$(OS)' != 'Windows_NT'">
<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0" PrivateAssets="All" />
</ItemGroup>
Ciò consentirà di compilare e comprimere su sistemi non Windows per .NET Framework. Ma è possibile eseguire solo destinazioni .NET Core utilizzando dotnet CLI su sistemi non Windows. Quindi dovresti anche essere pronto a selezionare un framework di destinazione da eseguire su sistemi non Windows, come questo:
dotnet run -f netcoreapp2.1
Fonte della soluzione:https://github.com/dotnet/designs/pull/33#issuecomment-489264196. Si tratta di una soluzione alternativa, quindi è soggetta a modifiche in futuro.
La distribuzione dell'interfaccia della riga di comando di .NET non contiene assembly di riferimento per .NET Framework, pertanto la relativa versione di MSBuild non è in grado di risolvere le risorse necessarie in fase di compilazione. Questo scenario è tuttavia tracciato su GitHub e ha funzionato prima della migrazione a MSBuild (l'interfaccia a riga di comando potrebbe utilizzare gli assembly di riferimento di mono).
Tuttavia, ci sono alcune alternative che possono essere utilizzate per costruire la tua libreria su macchine non Windows:
1. Usa mono 5+ per costruire la libreria.
Questo è probabilmente il percorso più stabile.
Mono 5 e versioni successive contengono la logica di compilazione necessaria per creare applicazioni .NET Standard e .NET Core. Su Linux, potrebbe essere necessario installare msbuild di mono come pacchetto separato. Quindi, invece dei seguenti comandi comunemente usati
dotnet restore
dotnet build
dotnet publish -c Release
useresti msbuild di mono per fare quanto segue:
msbuild /t:Restore
msbuild
msbuild /t:Publish /p:Configuration=Release
Soluzione del pacchetto per mono <5.2:
L'unica limitazione è che mono (<5.2) non può produrre pacchetti NuGet pronti all'uso, ma esiste una soluzione alternativa che prevede l'utilizzo di NuGet.Build.Tasks.Pack Pacchetto NuGet nel progetto che consente di eseguire msbuild /t:Pack /p:Configuration=Release modificando il file di progetto in questo modo (notare in particolare il file Sdk="..." rimosso). attributo sul <Project> elemento):
<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. Utilizza l'interfaccia a riga di comando di .NET e comunica a MSBuild di utilizzare gli assembly di riferimento di mono.
Durante la compilazione per net* framework di destinazione, puoi impostare FrameworkPathOverride property sia come variabile di ambiente che come proprietà nel file csproj. Deve puntare a un insieme di assembly di riferimento:qui è possibile utilizzare gli assembly di riferimento di mono. Ma alcuni contengono un file speciale (elenco redist) contenente riferimenti ad altre directory che la versione di MSBuild nell'interfaccia a riga di comando di .NET non può seguire. Funziona in molti scenari però:
export FrameworkPathOverride=/usr/lib/mono/4.5/
dotnet build -f net45
Questo è stato utilizzato e documentato dal team di F#.
3. Usa un pacchetto NuGet contenente assembly di riferimento.
In alcuni feed MyGet, Microsoft pubblica pacchetti NuGet contenenti assembly di riferimento. Non sono pubblicati o "ufficiali", quindi questo processo potrebbe fallire a un certo punto nel tempo. Tuttavia, hanno in programma di indagare per rendere ufficiale questo percorso.
Per prima cosa crea un file NuGet.Config nella directory della tua soluzione con i seguenti contenuti per aggiungere il feed:
<?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>
Quindi puoi aggiungere un gruppo di articoli per aggiungere il PackageReference a un pacchetto di targeting e a un PropertyGroup per impostare il percorso degli assembly di riferimento in questo modo:
<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>
Puoi cambiare il RuntimeIdentifier per piattaforme diverse se utilizzi risorse native (ad es. per ottenere .so files per linux) o rimuoverlo completamente durante la creazione di librerie.