This is caused by a breaking change in the .NET 6 SDK, and is independent of the .NET version your projects target. For example if you install Visual Studio 2022 it will install the .NET 6 SDK and use that for builds and deploys.

You can force VS to use an older SDK toolchain by generating a global.json file by running dotnet new globaljson in your solution root, then replacing the "version" property value with the desired SDK version (use dotnet --list-sdks to list installed versions).

I guess this means if you have a project dependency A->B where A and B are both executable and have their own appsettings.json, it would be preferable to split project B into B1 as a shell project with the appsettings.json and B2 as a library with all of B's functionality. Then dependencies A->B2 and B1->B2 would avoid the "multiple publish output files" issue.

The above answers led me to my solution. My case is a self-building Entity Framework library project that was now copying over its appsettings.json when building the website that used it.

My solution was to let it copy to output folder (when I am doing migration actions in VS**) but prevent it from publishing using the "Never" value because it is only ever published as a library under a website or web service.

<ItemGroup>
<Content Include="appsettings.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
    <CopyToPublishDirectory>Never</CopyToPublishDirectory>
</Content>
</ItemGroup>

** My EF library project builds itself according to the pattern in this data-seeding article.

Thus do I eat my cake and keep it.

I ran into this with a Blazor WebAssembly project and an associated integration test project which both had appsettings.json files while I was dotnet publish'ing out via a GitHub action. I found two additional ways that worked for me (along with the accepted answer):

1. Add <IsPublishable>false</IsPublishable > to the test project
2. In the dotnet publish commands, specify the .csproj directly via arguments

If you are getting this in a azure devops pipleline you can add the following task to specify the SDK version for your build

- task: UseDotNet@2
  displayName: 'Install .Net SDK version'
  inputs:
    packageType: sdk
    version: x.x.xxx //example (3.1.416)
    installationPath: $(Agent.ToolsDirectory)/dotnet

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer?view=azure-devops

Issue:

The issue raises after .NET 6 migration. There's a new feature that blocks multiple files from being copied to the same target directory with the same file name. See https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output

Solution #1 (workaround):

You can add the following build property to all your publishable (*.Web) projects' *.csproj files. This property will bypass this check and works as previously, in .NET5.

<ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>

Solution #2:

Exclude the problematic files to be copied to the output folder. In this example we'll exclude these files: compilerconfig.json and package.json.

Add the following lines to your common.props (located in the root directory of your solution):

<Content Remove="compilerconfig.json;package.json"/>
<None Include="compilerconfig.json;package.json">
  <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
  <CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>

I was able to resolve it by setting the Microsoft.NET.ConflictResolution.targets file under the <NETSdkError Condition="'$(_ResolvedFileToPublishContainsDuplicates)' == 'false'" <= this was originally true.

This file is located in "\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets"