Errore NuGet NU5051

Scenario 1

Un progetto ha più alias del framework di destinazione che si risolvono nello stesso framework efficace e il pacchetto non riesce a determinare quale alias deve contribuire all'output di compilazione, alle dipendenze o ai riferimenti del framework al pacchetto.

Issue

Un progetto simile al seguente ha due alias (apple e banana) che entrambi si risolvono in net10.0:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>apple;banana</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup>
    <TargetFrameworkIdentifier>.NETCoreApp</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v10.0</TargetFrameworkVersion>
    <TargetFrameworkMoniker>.NETCoreApp,Version=v10.0</TargetFrameworkMoniker>
  </PropertyGroup>
</Project>

Quando si esegue dotnet pack, NuGet genera NU5051 perché non può includere output di compilazione duplicati o gruppi di dipendenze per lo stesso framework in un singolo pacchetto.

Soluzione

Impostare IncludeBuildOutput su false e SuppressDependenciesWhenPacking su true su tutti gli alias per ogni framework efficace. Questo indica a NuGet quale alias contribuisce all'output di compilazione e alle dipendenze.

  <!-- Let 'apple' contribute the build output and dependencies -->
  <PropertyGroup Condition="'$(TargetFramework)' == 'banana'">
    <IncludeBuildOutput>false</IncludeBuildOutput>
    <SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking>
  </PropertyGroup>

Se gli alias hanno elementi diversi FrameworkReference , usare PrivateAssets="all" nei riferimenti al framework negli alias secondari per eliminarli dal pacchetto.

Scenario 2

Un progetto ha alias per compilazioni specifiche del runtime e vuole inserire l'output di compilazione di ogni alias in un percorso del pacchetto personalizzato (ad esempio, runtimes/<rid>/lib/<tfm>/).

Issue

Un progetto come il seguente ha net10.0 come alias primario e linuxios come alias secondari. Tutte e tre le soluzioni allo stesso framework efficace:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net10.0;linux;ios</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup Condition="'$(TargetFramework)' == 'linux' OR '$(TargetFramework)' == 'ios' OR '$(TargetFramework)' == 'net10.0'">
    <TargetFrameworkIdentifier>.NETCoreApp</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v10.0</TargetFrameworkVersion>
    <TargetFrameworkMoniker>.NETCoreApp,Version=v10.0</TargetFrameworkMoniker>
  </PropertyGroup>
</Project>

L'esecuzione dotnet pack genera NU5051 perché tre alias producono output di compilazione e dipendenze per lo stesso framework.

Soluzione

Eliminare l'output e le dipendenze di compilazione predefiniti per gli alias secondari e usare TargetsForTfmSpecificContentInPackage per inserire gli assembly degli alias secondari in percorsi di pacchetto personalizzati:

  <PropertyGroup>
    <TargetsForTfmSpecificContentInPackage>$(TargetsForTfmSpecificContentInPackage);GetMyPackageFiles</TargetsForTfmSpecificContentInPackage>
  </PropertyGroup>

  <PropertyGroup Condition="'$(TargetFramework)' == 'linux' OR '$(TargetFramework)' == 'ios'">
    <IncludeBuildOutput>false</IncludeBuildOutput>
    <SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking>
  </PropertyGroup>

  <Target Name="GetMyPackageFiles">
    <ItemGroup Condition="'$(TargetFramework)' == 'linux' OR '$(TargetFramework)' == 'ios'">
      <TfmSpecificPackageFile Include="$(OutputPath)$(AssemblyName).dll">
        <PackagePath>runtimes/$(TargetFramework)/lib/net10.0</PackagePath>
      </TfmSpecificPackageFile>
    </ItemGroup>
  </Target>

Con questa configurazione, net10.0 contribuisce l'output e le dipendenze di compilazione predefiniti lib/net10.0/ , mentre linux e ios posizionare gli assembly rispettivamente in runtimes/linux/lib/net10.0/ e runtimes/ios/lib/net10.0/ .

Per altre informazioni sul multitargeting con framework duplicati, vedere Targeting multiple frameworks .For more information about multi-targeting with duplicate frameworks, see Targeting multiple frameworks. Per altre informazioni sull'estendibilità dei pacchetti, vedere La destinazione del pacchetto.