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.

[dotnet-issue-labeler]

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

[dsplaisted]

@spanevin See this documentation on the breaking change and how to resolve it: https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output

The simple fix is to set ErrorOnDuplicatePublishOutputFiles to false.

If possible, it would be better to normalize the casing for the file if that's under your control.

[spanevin]

@dsplaisted I read the docs and behavior which I see doesn't match behavior which should be, based on the docs.

Docs say:

Starting in .NET 6, MSBuild removes duplicate files that are copied to the publish folder if both the source and destination are the same. If there are any remaining duplicates, a NETSDK1152 error is generated and lists the files that are duplicated.

It clearly says that if the files are the same - duplicates must be removed by msbuild.

In my case files are the same - it's snappy32.dll, snappy64.dll and libzstd.dll from exactly the same nuget package.

Found multiple publish output files with the same relative path:
{solutionRoot}\packages\MongoDB.Driver.Core.2.12.4\runtimes\win\native\snappy32.dll,
{solutionRoot}\packages\mongodb.driver.core\2.12.4\runtimes\win\native\snappy32.dll,
{solutionRoot}\packages\MongoDB.Driver.Core.2.12.4\runtimes\win\native\snappy64.dll,
{solutionRoot}\packages\mongodb.driver.core\2.12.4\runtimes\win\native\snappy64.dll,
{solutionRoot}\packages\MongoDB.Driver.Core.2.12.4\runtimes\win\native\libzstd.dll,
{solutionRoot}\packages\mongodb.driver.core\2.12.4\runtimes\win\native\libzstd.dll.

Solution configuration is the following:
ProjectA - old-style csproj with packages.config references, references MongoDB.Driver.Core.2.12.4, a library
ProjectB - new SDK-style csproj, references MongoDB.Driver.Core.2.12.4 as PackageReference, a library
ProjectC - new SDK-style csproj (AspNetCore-based web service), references ProjectA and ProjectB as ProjectReference, an Exe

When I'm doing build of ProjectC - dotnet publish fails with this error.

If I convert ProjectA to SDK-style with PackageReference instead of packages.config reference - dotnet publish is not failed anymore.

I don't think that setting ErrorOnDuplicatePublishOutputFiles to false is a good idea. It is not a fix, it is just a workaround for a particular case. If real duplicate files with different content appear in this solution - this setting will hide a real error, which is not good.

As you can see from my build output - paths to the files have different case, and different package location is used (package\version vs package.version), but it's still the same nuget package, so it's the same files.

[dsplaisted]

@spanevin Yes, I think it is better not to set ErrorOnDuplicatePublishOutputFiles to false, but for folks who just want an easy fix to get back to the behavior (even though it can hide issues) that was in the 5.0 and earlier SDKs, it's an option.

In your case, it looks like the duplicate files are caused by a mix of projects that use packages.config and PackageReference. I'd suggest one of the following:

• Convert all projects to use PackageReference instead of packages.config. If this is possible, it will probably be the best solution.
• Delete the references to the native DLLs from the ProjectA csproj file. This may not work if there are other projects besides ProjectC that depend on ProjectA and need those DLLs to flow.
• Write a custom target in ProjectC to remove the snappy32, snappy64, and libzstd references which are flowing from the packages.config project.

[spanevin]

@dsplaisted I understand there are workarounds, but it makes migration to new versions really complicated. Luckily right now just few of several hundreds of projects are affected for us, but it could be much worse...
The problem is that if we install NET6 SDK on a build server, it immediately breaks builds of all repositories which have at least one project/solution affected with this issue or any other similar issue. We can't just stop development and start fixing compatibility issues... And we can't just add global.json with SDK limitation as we really want to use net6.

[dsplaisted]

@spanevin I'm not sure what you're asking for. Right now you can either go back to the old behavior where the error is ignored, or you can fix the root cause. Is there something else you think we should be doing?