"Encountered conflict" build messages reported for satellite assemblies during build of .NET Core project

[tmat]

Repro:

1. Create a .NET Core project targeting net46
2. Add a package reference to some nuget package that contains satellite assemblies, e.g. Microsoft.VisualStudio.Composition, 15.3.38
3. Run

msbuild /v:diag > build.log

The build succeeds but the log contains messages like:

Encountered conflict between 'CopyLocal:C:\Users\tomat\.nuget\packages\microsoft.visualstudio.composition\15.3.38\lib\net45\cs\Microsoft.VisualStudio.Composition.resources.dll' and 'CopyLocal:C:\Users\tomat\.nuget\packages\microsoft.visualstudio.composition\15.3.38\lib\net45\de\Microsoft.VisualStudio.Composition.resources.dll'.  Could not determine winner due to equal file and assembly versions. (TaskId:18)

[tmat]

/cc @nguerrera

[nguerrera]

@dsplaisted @ericstj

[ericstj]

Looks like we're not computing the output path correctly. We don't wack either of them but it'd be nice to avoid that log spew.

Here's the code that tries to compute the output path:
https://github.com/dotnet/sdk/blob/release/2.0.0/src/Tasks/Common/src/ItemUtilities.cs#L116-L134

Can you share the full set of metadata on those resource DLL items so that we can see what we're missing?

[AmadeusW]

I have these dlls. How do I go about getting their metadata?
@ericstj if I open this repo's source code in VS and attach debugger to MSBuild, will the breakpoint in ItemUtilities.cs hit?

[ericstj]

@AmadeusW you'd need the symbols. What is it you're trying to do exactly?

[AmadeusW]

I'm trying to see how does it happen that C:\Users\amwieczo\.nuget\packages\microsoft.visualstudio.threading\15.3.23\lib\net45\cs\Microsoft.VisualStudio.Threading.resources.dll loses the cs and ends up conflicting with other language specific dlls that also lose their language subdirectory information when they're copied to the output directory. Ultimately I would like to contribute a fix, but I don't know how to debug this code.

[ericstj]

Typically you start debugging the msbuild targets by examining logs. If you determine that you need to debug a task its often simplest to just build a copy of that task locally and then use that one (so that you're sure you have symbols).

also lose their language subdirectory information when they're copied to the output directory

Just to be clear, these targets aren't doing anything to strip the info, so if you see that happening in the output directory it would be the root cause and not this. The task I mentioned would just be noticing that these would be clashing in the output and you'd need to look earlier in the build to see what wasn't passing the resource directory through.

[ericstj]

Yeah, it looks like there is a different root cause here that's worse than just a message. A better way to state this issue is:

1. Build a non-SDK csproj referencing nuget package with resources: resource.dlls are placed in culture-specific subfolders.
2. Build an SDK csproj of the same: resources are not placed in lang-specific folders.

In non-SDK projects the subfolder was controlled with locale info from the lock file. See https://github.com/NuGet/NuGet.BuildTasks/blob/057af5b6ff9521551cf6dcee5cd737993a943472/src/Microsoft.NuGet.Build.Tasks/ResolveNuGetPackageAssets.cs#L782-L789. This gets set to TargetPath by the task that raises items.

In SDK projects it looks like NuGet populates this as locale metadata on the FileDependencies item, but SDK doesn't do anything with it. The bug appears to be in the SDK targets. The place to look at for a potential fix is likely here:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.PackageDependencyResolution.targets

Lines 505 to 540 in 98ea6b2

	<!--NativeLibrary-->
	<_NativeFileItems Include="@(_ActiveTFMFileDependencies->WithMetadataValue('FileGroup', 'NativeLibrary'))" />
	<__NativeCopyLocalItems Include="@(FileDefinitions)" Exclude="@(_NativeFileItems)" />
	<_NativeCopyLocalItems Include="@(FileDefinitions)" Exclude="@(__NativeCopyLocalItems)" />
	<NativeCopyLocalItems Include="%(_NativeCopyLocalItems.ResolvedPath)" />
	<!--RuntimeAssembly-->
	<_RuntimeFileItems Include="@(_ActiveTFMFileDependencies->WithMetadataValue('FileGroup', 'RuntimeAssembly'))" />
	<__RuntimeCopyLocalItems Include="@(FileDefinitions)" Exclude="@(_RuntimeFileItems)" />
	<_RuntimeCopyLocalItems Include="@(FileDefinitions)" Exclude="@(__RuntimeCopyLocalItems)" />
	<RuntimeCopyLocalItems Include="%(_RuntimeCopyLocalItems.ResolvedPath)" />
	<!--ResourceAssembly-->
	<_ResourceFileItems Include="@(_ActiveTFMFileDependencies->WithMetadataValue('FileGroup', 'ResourceAssembly'))" />
	<__ResourceCopyLocalItems Include="@(FileDefinitions)" Exclude="@(_ResourceFileItems)" />
	<_ResourceCopyLocalItems Include="@(FileDefinitions)" Exclude="@(__ResourceCopyLocalItems)" />
	<ResourceCopyLocalItems Include="%(_ResourceCopyLocalItems.ResolvedPath)" />
	<!-- ALL -->
	<_AllCopyLocalItems Include="@(_NativeCopyLocalItems);@(_RuntimeCopyLocalItems);@(_ResourceCopyLocalItems)" />
	<AllCopyLocalItems Include="@(_AllCopyLocalItems->'%(ResolvedPath)')">
	<Private>false</Private>
	<NuGetIsFrameworkReference>false</NuGetIsFrameworkReference>
	<NuGetSourceType>Package</NuGetSourceType>
	<NuGetPackageId>%(PackageName)</NuGetPackageId>
	<NuGetPackageVersion>%(PackageVersion)</NuGetPackageVersion>
	</AllCopyLocalItems>
	<AllCopyLocalItems Include="@(_ContentCopyLocalItems)">
	<Private>false</Private>
	<NuGetIsFrameworkReference>false</NuGetIsFrameworkReference>
	<NuGetSourceType>Package</NuGetSourceType>
	<NuGetPackageId>%(PackageName)</NuGetPackageId>
	<NuGetPackageVersion>%(PackageVersion)</NuGetPackageVersion>
	</AllCopyLocalItems>

[nguerrera]

@AmadeusW What version of Visual Studio (if any) are you using and what NET Core SDK are you using: dotnet --info.

That looks like #1360 which was fixed in version 2.0 of the .NET Core SDK. You should try again with Visual Studio 15.3 (if you're using VS) and https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-core-2-0/

Alternatively, if for some reason you can't upgrade, there is a workaround described for older SDK versions in the linked bug.

[mehmetilker]

@nguerrera The problem is continue with Core 2.0 SDK and VS 17.3
Message is not example same except first part : "Encountered conflict between "....

6> Encountered conflict between 'Platform:System.Security.Cryptography.Csp.dll' and 'Runtime:C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.security.cryptography.csp\4.3.0\runtimes\unix\lib\netstandard1.3\System.Security.Cryptography.Csp.dll'. Choosing 'Platform:System.Security.Cryptography.Csp.dll' because AssemblyVersion '4.1.0.0' is greater than '4.0.1.0'.

[ericstj]

@mehmetilker you seem to be discussing something different. That isn't a resource assembly and the message you are seeing is merely conflict resolution working by design. It's choosing the higher versioned assembly from the platform rather than one from a package. If you have a specific question about that, open a new issue please.

[felipecruz91]

@ericstj How can we force it so that the assembly from the package gets preference over the one from the platform?

[ericstj]

Give it a higher version. See https://github.com/dotnet/sdk/blob/master/src/Tasks/Common/ConflictResolution/ConflictResolver.cs.