runtime: ResolvePackageFileConflicts is detecting unexpected conflicts

While building the runtime repo in source build for .NET 6.0 I have encountered an issue where ResolvePackageFileConflicts is detecting unexpected conflicts.

Here is a binlog for the issue - https://artprodcus3.artifacts.visualstudio.com/Ab55de4ed-4b5a-4215-a8e4-0a0a5f71e7d8/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL2RuY2VuZy9wcm9qZWN0SWQvOWVlNmQ0NzgtZDI4OC00N2Y3LWFhY2MtZjZlNmQwODJhZTZkL2J1aWxkSWQvMTMzMTc1Ny9hcnRpZmFjdE5hbWUvU291cmNlLUJ1aWxkK0J1aWxkK1RhcmJhbGwrRmVkb3JhMzMtT25saW5lX0J1aWxkTG9nc19BdHRlbXB0Mg2/content?format=file&subPath=%2Fsrc%2Fruntime.566b53a66b0afa573f0dae33d07c8de9685aa5c8%2Fartifacts%2FbuildLogs%2Fsource-build%2Fself%2Fsrc%2Fartifacts%2Fsourcebuild.binlog.

_CreateR2RImages is failing for the Microsoft.NETCore.App.CrossGen2 project. The root issue is that System.Private.CoreLib.dll cannot be loaded. It appears that the ResolvePackageFileConflicts task is removing this assembly from the ReadyToRun implementation assemblies list as well as several others.

Encountered conflict between'CopyLocal:/repos/installer/artifacts/tarball/src/runtime.566b53a66b0afa573f0dae33d07c8de9685aa5c8/artifacts/source-build/self/src/artifacts/bin/microsoft.netcore.app.runtime.fedora.33-x64/Release/runtimes/fedora.33-x64/lib/net6.0/Microsoft.VisualBasic.Core.dll'and'CopyLocal:/repos/installer/artifacts/tarball/src/runtime.566b53a66b0afa573f0dae33d07c8de9685aa5c8/artifacts/source-build/self/src/artifacts/bin/coreclr/Linux.x64.Release/System.Private.CoreLib.dll'.Choosing'CopyLocal:/repos/installer/artifacts/tarball/src/runtime.566b53a66b0afa573f0dae33d07c8de9685aa5c8/artifacts/source-build/self/src/artifacts/bin/microsoft.netcore.app.runtime.fedora.33-x64/Release/runtimes/fedora.33-x64/lib/net6.0/Microsoft.VisualBasic.Core.dll'because AssemblyVersion '11.0.0.0' is greater than '6.0.0.0'.

I don’t understand what the ResolvePackageFileConflicts task is doing and why it is picking Microsoft.VisualBasic.Core.dll over System.Private.CoreLib.dll. Can you help me understand what is going on here?

About this issue

Original URL
State: open
Created 3 years ago
Comments: 28 (27 by maintainers)

Commits related to this issue

Add patch for crossgen2 issue in runtime This includes the fix suggested by hoyosjs on https://github.com/dotnet/sdk/issues/20543 — committed to MichaelSimons/installer by dseefeld 3 years ago

Most upvoted comments

Probably the fix here is to change that SFXPROJ section to be:

  <Target Name="AddRuntimeFilesToPackage" DependsOnTargets="ResolveRuntimeFilesFromLocalBuild">
    <ItemGroup>
      <CrossgenFile Include="@(RuntimeFiles)" Condition="'%(Filename)' == 'crossgen'" />
      <OptimizationDataFile Include="@(RuntimeFiles)" Condition="'%(Filename)' == 'StandardOptimizationData'" />
      <ReferenceCopyLocalPaths Include="@(RuntimeFiles)" Exclude="@(CrossgenFile);@(OptimizationDataFile)" />
        <TargetPath>tools/%(RuntimeFiles.Filename)%(RuntimeFiles.Extension)</TargetPath>
      <ReferenceCopyLocalPaths/>
      <ReferenceCopyLocalPaths DestinationSubDirectory="tools/" />
    </ItemGroup>
  </Target>

  <Target Name="AddFrameworkFilesToPackage" DependsOnTargets="ResolveLibrariesFromLocalBuild">
    <ItemGroup>
      <ReferenceCopyLocalPaths Include="@(LibrariesRuntimeFiles)" DestinationSubDirectory="tools/">
        <TargetPath>tools/%(LibrariesRuntimeFiles.Filename)%(LibrariesRuntimeFiles.Extension)</TargetPath>
      <ReferenceCopyLocalPaths/>
    </ItemGroup>
  </Target>

cc: @dotnet/crossgen-contrib

hoyosjs on Sep 3, 2021

That’s not expected at all. Identifying conflicts happens by comparing item keys.

Since these are “CopyLocal” that would be here: https://github.com/dotnet/sdk/blob/1fb85c4e1bc9f005ead912cb6b27635f5461ed74/src/Tasks/Common/ConflictResolution/ResolvePackageFileConflicts.cs#L117-L121

So the item key in this case is ItemUtilities.GetTargetPath https://github.com/dotnet/sdk/blob/1fb85c4e1bc9f005ead912cb6b27635f5461ed74/src/Tasks/Common/ItemUtilities.cs#L123-L153

So that will honor “TargetPath” metadata as the item key if it exists

These items did set TargetPath, and for some reason, it doesn’t contain filename.

/tarball/src/runtime.566b53a66b0afa573f0dae33d07c8de9685aa5c8/artifacts/source-build/self/src/artifacts/bin/microsoft.netcore.app.runtime.fedora.33-x64/Release/runtimes/fedora.33-x64/lib/net6.0/Microsoft.VisualBasic.Core.dll
    IsNative = 
    PostprocessAssembly = true
    RelativePath = Microsoft.VisualBasic.Core.dll
    CopyToPublishDirectory = Always
    TargetPath = tools/


/tarball/src/runtime.566b53a66b0afa573f0dae33d07c8de9685aa5c8/artifacts/source-build/self/src/artifacts/bin/coreclr/Linux.x64.Release/System.Private.CoreLib.dll
    PostprocessAssembly = true
    RelativePath = System.Private.CoreLib.dll
    CopyToPublishDirectory = Always
    TargetPath = tools/

So this explains why it’s happening, but I’m not sure what changed between source build and the normal build, but perhaps this gives you enough breadcrumbs to compare and find out why TargetPath is wrong?

ericstj on Sep 2, 2021