What is the expected path for ResolvePackageFileConflicts to work with repositories that build their own platforms

[ViktorHofer]

CoreFx doesn't use the Microsoft.NETCore.App.Ref targeting pack as we build the refs ourselves. Without that targeting pack the ResolvePackageFileConflicts task seems to not be able to handle conflicts between package runtime assemblies and the live built ones.

Comparing an example project with a test project in CoreFx I can see the following differences:

• PlatformManifests: not set, points to a manifest file on disk which contains all the platform assemblies
• PreferredPackages: not set, a list of packages that are preferred?

Conflicts as such are therefore missing in CoreFx:

Encountered conflict between 'Platform:System.Xml.XDocument.dll' and 'CopyLocal:C:\Users\vihofer\.nuget\packages\system.xml.xdocument\4.0.11\lib\netstandard1.3\System.Xml.XDocument.dll'. NETSDK1033: Choosing 'Platform:System.Xml.XDocument.dll' because AssemblyVersion '4.1.1.0' is greater than '4.0.11.0'.

The impact of this is that dependencies that come via packages are copied to the output directory and are preferred over the live built ones.

What is the expected path for repositories that live build platforms?

EDIT: Attaching the binlog of the corefx test project: msbuild.zip

cc @ericstj @dsplaisted @nguerrera

[ViktorHofer]

cc @natemcmaster in case you are hitting this too in aspnetcore

[dsplaisted]

What exactly are you expecting to happen that is not happening? In the scenario described, if there was a conflict I would expect the conflict resolution to fall back to the highest assembly or file version. In the .binlog, it looks like that's what's happening.

[ViktorHofer]

The reference assemblies are resolved correctly, the higher version is taken. I was talking about the copy local items here, the runtime assemblies that are coming in from referencing packages that ie target netstandard <= 2.0.

[ViktorHofer]

I was talking with @ericstj about this offline and he suggested to include our runtime directory which contains our live build assemblies in _RuntimeAssetsForConflictResolution so that they are passed into the OtherRuntimeItems parameter.

[ericstj]

@dsplaisted essentially we are creating our own shared framework but none of the runtime items are ever visible to conflict resolution and we need to decide what the best way is to let conflict resolution know about those runtime items.

I discussed a few options: 1) generate a platform manifest 2) plumb them through as items either a) some existing item that's already included in _RuntimeAssetsForConflictResolution, so long as including to that item doesn't have side-effects, or b) directly including to _RuntimeAssetsForConflictResolution.

Do you have a preference for 2a or 2b, and if 2a a recommendation for which item is likely to not have side effects now or moving forward?

[ViktorHofer]

@dsplaisted I would like to make the changes that @ericstj mentioned above, today. Could you please let us know which item we should use for populating our framework assemblies?

[ViktorHofer]

I just tried approach 2b but it seems RID specific assets aren't handled correctly by the conflict resolution:

With option 2 our items will have a ConflictItemType of "Runtime" but the correct ConflictItemType for our live built assemblies should be "Platform":

sdk/src/Tasks/Common/ConflictResolution/ResolvePackageFileConflicts.cs

Line 228 in 4094dca

if (winner.ItemType == ConflictItemType.Platform)

Seems we need to generate the platform manifest and pass in the the PlatformManifests and TargetFrameworkDirectories parameters.

[ViktorHofer]

@ericstj I just noticed the TargetFrameworkDirectories parameter here. Do you think it makes sense to set that manually in corefx? The platform manifest items are appended to the items that come from the TargetFrameworkDirectories:

sdk/src/Tasks/Common/ConflictResolution/ResolvePackageFileConflicts.cs

Lines 120 to 125 in 4094dca

	var platformItems = PlatformManifests?.SelectMany(pm => PlatformManifestReader.LoadConflictItems(pm.ItemSpec, log)) ?? Enumerable.Empty<ConflictItem>();
	if (compilePlatformItems != null)
	{
	platformItems = platformItems.Concat(compilePlatformItems);
	}

EDIT: Ok this wouldn't help either as it also reads from a platform manifest file:

sdk/src/Tasks/Common/ConflictResolution/ResolvePackageFileConflicts.cs

Line 69 in 4094dca

return frameworkListReader.GetConflictItems(Path.Combine(tfd.ItemSpec, "RedistList", "FrameworkList.xml"), log);

Means I now need to investigate how I can produce a platform manifest file.

EDIT2: The source code for generating the manifest file lives here: https://github.com/dotnet/core-setup/blob/master/tools-local/tasks/GenerateFileVersionProps.cs. It's unfortunate that code that is needed by repositories who compose a shared framework isn't shared in arcade. This mean I probably need to copy this file to arcade somewhere to consume it as a task...

[ViktorHofer]

OK I'm now generating the manifest file in corefx successfully: dotnet/arcade@4400017 and dotnet/corefx@754b451

In future we ideally want to have a common library in arcade that is used by core-setup and repositories which compose their own shared framework(s) to avoid the duplication.