NETSDK1148 error when building for runtime win7-x86

[adityapatwardhan]

We are seeing an issue when trying to build Powershell against .NET 6 preview.1 SDK. The error is:

C:\Users\adity\AppData\Local\Microsoft\dotnet\sdk\6.0.100-preview.1.21104.4\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(108,5): error NETSDK1148: Found multiple publish output files with the same relative path: C:\Users\adity\.nuget\packages\microsoft.netcore.app.runtime.win-x86\6.0.0-preview.1.21102.12\runtimes\win-x86\native\API-MS-Win-core-xstate-l2-1-0.dll, C:\Users\adity\.nuget\packages\runtime.win7-x86.microsoft.netcore.windows.apisets\1.0.1\runtimes\win7-x86\native\api-ms-win-core-xstate-l2-1-0.dll. [D:\PSGit\PowerShell\src\powershell-win-core\powershell-win-core.csproj]

The command line used to build:

dotnet publish --no-restore /property:GenerateFullPaths=true /property:IsWindows=true --configuration Release --framework net6.0 --runtime win7-x86 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop

Might be related to #14020

/cc @sfoslund as per Marc Paine.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[sfoslund]

This is a new error added with .NET 6, this comment provides some details on what it means: dotnet/aspnetcore#29524 (comment). This error is very project dependent so if you need help debugging please provide a binlog recreating the error.

[adityapatwardhan]

Attaching the binlog as requested.
msbuild.zip

[sfoslund]

From the binlog it looks like the conflict should be resolved by HandlePackageFileConflicts but since the casing is different between the two file names (API-MS-Win-core-xstate-l2-1-0.dll and api-ms-win-core-xstate-l2-1-0.dll) it isn't marked as a conflict and doesn't get resolved.

@dsplaisted is this expected since different platforms have different policies on casing in file names? Is this an issue with one of the packages pulling in the dll or is this a SDK bug?

[dsplaisted]

Is this an issue with one of the packages pulling in the dll or is this a SDK bug?

It looks like this is a package that we produce, so we should be consistent about the casing. So we should probably file a bug (on dotnet/runtime I think) for that.

It also might be a good idea to do case-insensitive comparison when doing conflict resolution.

Pros:

• Conflict resolution would work better for case-insensitive file systems

Cons:

• It wouldn't be possible to have assets processed by conflict resolution that differ only by case
• It could be a breaking change
• We might be less likely to find case inconsistency issues in packages we publish

[sfoslund]

Cool, I filed an issue on the runtime. It seems like changing to case insensitive comparisons would be ideal for case insensitive file systems, but I would be concerned about the effect on case sensitive file systems, I agree that it would probably be a breaking change for some scenarios.

[dsplaisted]

MSBuild already does case insensitive comparisons in a lot of places. So I'm not sure this would break the scenario where you have files that only differ by case any worse than it already is broken. Certainly there is some amount of risk though.

[mairaw]

I'm also getting this error on the preview pipeline for the dot.net website using the .NET 6 Preview 1 SDK
2021-02-17T23:35:43.3589315Z C:\hostedtoolcache\windows\dotnet\sdk\6.0.100-preview.1.21103.13\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(108,5): error NETSDK1148: Found multiple publish output files with the same relative path: C:\hostedtoolcache\windows\dotnet\sdk\6.0.100-preview.1.21103.13\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\BlazorWasm.web.config, D:\a\1\s\src\netlandingpage\web.config. [D:\a\1\s\src\netlandingpage\netlandingpage.csproj]

Same pipeline with .NET 5 SDK publishes without any errors.

[spanevin]

I'm facing the same issue with 6.0.101 SDK

Error reports the same file as duplicate, just different character case in path (which is actually the same path for windows file systems), and it is not appsettings.json, it's mongodb driver dll.

It worked well with 5.0.100 SDK