Cree un paquete NuGet en Linux que se dirija a .NET Framework

Simplemente puede agregar lo siguiente a su archivo de proyecto:

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

Esto permitirá compilar y empaquetar en sistemas que no sean Windows para .NET Framework. Pero solo puede ejecutar objetivos .NET Core usando dotnet CLI en sistemas que no son de Windows. Por lo tanto, también debe estar listo para seleccionar un marco de destino para ejecutar en sistemas que no son de Windows, como este:

dotnet run -f netcoreapp2.1

Fuente de la solución:https://github.com/dotnet/designs/pull/33#issuecomment-489264196. Esta es una solución alternativa, por lo que está sujeta a cambios en el futuro.

La distribución de la CLI de .NET no contiene ensamblados de referencia para .NET Framework, por lo que su versión de MSBuild no puede resolver los recursos de tiempo de compilación necesarios. Sin embargo, este escenario se rastrea en GitHub y funcionó antes de la migración a MSBuild (la CLI podría usar los ensamblajes de referencia de mono).

Sin embargo, existen algunas alternativas que se pueden usar para construir su biblioteca en máquinas que no sean Windows:

1. Use mono 5+ para construir la biblioteca.

Este es probablemente el camino más estable.

Mono 5 y superior contiene la lógica de compilación necesaria para compilar aplicaciones .NET Standar y .NET Core. En Linux, es posible que sea necesario instalar msbuild de mono como un paquete separado. Entonces, en lugar de los siguientes comandos de uso común

dotnet restore
dotnet build
dotnet publish -c Release

usaría msbuild de mono para hacer lo siguiente:

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

Paquete de soluciones alternativas para mono <5.2:

La única limitación es que mono (<5.2) no puede producir paquetes NuGet listos para usar, pero existe una solución alternativa que implica el uso de NuGet.Build.Tasks.Pack Paquete NuGet en el proyecto que le permite hacer msbuild /t:Pack /p:Configuration=Release modificando el archivo del proyecto de esta manera (especialmente tenga en cuenta el Sdk="..." eliminado atributo en el <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. Use la CLI de .NET y dígale a MSBuild que use los ensamblados de referencia de mono.

Al construir para net* marcos de destino, puede establecer el FrameworkPathOverride property como variable de entorno o como propiedad en el archivo csproj. Debe apuntar a un conjunto de ensamblajes de referencia:aquí se pueden usar los ensamblajes de referencia de mono. Pero algunos contienen un archivo especial (lista redist) que contiene referencias a otros directorios que la versión de MSBuild en la CLI de .NET no puede seguir. Sin embargo, funciona en muchos escenarios:

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

Esto fue utilizado y documentado por el equipo de F#.

3. Use un paquete NuGet que contenga ensamblados de referencia.

En algunas fuentes de MyGet, Microsoft publica paquetes de NuGet que contienen ensamblados de referencia. Sin embargo, no están publicados ni son "oficiales", por lo que este proceso puede fallar en algún momento. Sin embargo, planean investigar para hacer oficial este camino.

Primero cree un archivo NuGet.Config en el directorio de su solución con los siguientes contenidos para agregar el 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>

Luego puede agregar un grupo de artículos para agregar el PackageReference a un paquete de segmentación y un PropertyGroup para establecer la ruta a los ensamblajes de referencia de esta manera:

<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>

Puedes cambiar el RuntimeIdentifier para diferentes plataformas si usa activos nativos (por ejemplo, para obtener .so archivos para linux) o elimínelo por completo al crear bibliotecas.