Publish error: Found multiple publish output files with the same relative path

When I publish my ABP project I get the following error:

C:\Program Files\dotnet\sdk\6.0.100-rc.1.21458.32\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: 

D:\Github\volo\abp\lepton-theme\src\Volo.Abp.AspNetCore.Mvc.UI.Theme.Lepton\compilerconfig.json,
D:\Github\volo\abp\bookstore\src\Acme.BookStore.Theme\compilerconfig.json, 

D:\Github\volo\abp\lepton-theme\src\Volo.Abp.AspNetCore.Mvc.UI.Theme.Lepton\package.json, 
D:\Github\volo\abp\bookstore\src\Acme.BookStore.Web\package.json. 

D:\Github\volo\abp\bookstore\src\Acme.BookStore.Web\Acme.BookStore.Web.csproj

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>

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

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

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.

I ran into this issue with a web application that had a Razor Class Library. The culprit file was LIBMAN.JSON.

Right click on the file and change the properties of the file to:

Build Action: NONE

Copy to Output Directory: DO NOT COPY

Other files that are used for tooling only could possibly be changes the same way.

I have also used compilerconfig.json for compiling scss to css. And the easiest fix through UI is to:

Open Solution Explorer->compilerconfig.json->right click->properties and there set:

Build Action: None
Copy to Output Directory: Do not copy

Do this for all compiler.config files (in my case on client project as well as on the server)

The reason behind this is that this compiler config is only used locally in building process but it is not required later on while app is running.

I was able to resolve it by setting the Microsoft.NET.ConflictResolution.targets file under the

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

If your projects (All part of the same solution) uses a different version of the same nuget pacage, you will see this error. Now you can either find a workaround as others mentioned in the answers if for some reason you have to keep both versions (which is not a good practice).

Or do the right thing and make sure all project using same version of the package. to do that just open Visual studio's NuGet package manager for solution as shown in the screenshot

A window opens which will have a consolidate tab at the top, click on the consolidate tab. if you have a version conflict, you will be able to see lisr=t of NuGet packages on the left side. If that is the case it means you have conflicts. Click on any package and you will be able to see the list of your solution's projects on the right side just like the following screenshot

in my example (screenshot), I have 2 versions of Microsoft.Net.Sdk.Functions one with 3.0.13 and 3.0.11. All you need to do is to select your preferred version and click install and both projects will be updated to the same version. Push the changes and devops build again and enjoy