search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.66k stars 1.06k forks source link

NETSDK1148 error when building for runtime win7-x86 #15748

Open adityapatwardhan opened 3 years ago

adityapatwardhan commented 3 years ago

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[bot] commented 3 years ago

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 commented 3 years ago

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

adityapatwardhan commented 3 years ago

Attaching the binlog as requested. msbuild.zip

sfoslund commented 3 years ago

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 commented 3 years ago

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

Why not both?

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:

Cons:

sfoslund commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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:

spanevin commented 2 years ago

@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 commented 2 years ago

@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?