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

16

208

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
Figuration answered 10/11, 2021 at 20:13 Comment(0)
F
390

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://learn.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.

<PropertyGroup>
 <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>
</PropertyGroup>

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>
Figuration answered 10/11, 2021 at 20:16 Comment(12)
I encountered this issue after installing VS 2022 side-by-side with VS 2019, even though the solution with the error was still building in VS 2019 with .NET 5. Solution #1 seemed to work for me in the short term - thanks!Scoreboard
Is it possible to override this for a single file? If one have the scenario of proj B deps on proj A. Both emits an appsettings.json. In this specific case you actually want proj B to override the appsettings.json from proj A.Arlettaarlette
Confirmed this was the problem for me as well. Azure Pipelines stopped building since a recent update (~Dec, 2021) due to the auto generated XML documentation file MyApi.xml was found as duplicate. Removing the <CopyToOutputDirectory>Always</CopyToOutputDirectory> section from the .csproj fixed it in my case.Matthew
I ran into this issue after installing the .NET 6 SDK on our Azure DevOps on prem build server. After the install Azure App Service deployments via Azure DevOps Pipelines started to fail. This solution fixed the issue. Thank you!Lagting
It should be noted if you go with Solution #1 you don't need to add it to all the publishables, only the ones that are having this error. In our case we have about 9 project files building to Azure Service Fabric - we only needed to update 2 of them.Moxley
I don't understand this as a breaking change. Why are multiple executable project level appsettings.json files being copied to the same output directory? Each one is for each project. The problem seems to be that there's a problem and instead of fixing it they just made it everyone else's problem.Counterespionage
maybe add description specific location add in <PropertyGroup> where Solution #1 should be added, for someone that like, that didn't pay attention on the explanation, :)Tickle
I just have projects with multitargets (net5.0, net6.0). So this error makes no sense because only one file must be published in dependence on the framework.Primine
Solution 1 worked for me, I needed to add in all .csproj fileReasoned
I added caching of nuget in the CI Pipeline, and therefore needed the files packages.lock.json in the root of all projects, leading to the error "Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: D:\a\1\s[PROJECT1]\packages.lock.json, D:\a\1\s[PROJECT2]\packages.lock.json ...." Thus exluding the files from output folder didn't change the error and build failure. The following worked <ErrorOnDuplicatePublishOutputFiles>false... - learn.microsoft...artifacts/caching-nugetEads
Can we conditionally exclude the problematic files when the project is a dependency of another project, but include the files when the project is the project being built?Woolcott
This nearly worked for us but helped us find the answer that worked for us which was: <ItemGroup><Content Update ="appsettings.json" ... </Content> </ItemGroup> i.e. we had to use Update rather than IncludeCaraviello
F
37

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.

Faubion answered 7/1, 2022 at 15:33 Comment(6)
Can you tell me more about the cake?Cabaret
@MarkCooper, I would point you at another site, but I can't find a stack exchange site for cooking, cuisine, food, nutrition, diet, or cake.Faubion
In my observation, this is the better / best solution as it allows / forces one to deal with the files at a project level.Gruber
@Faubion I think this is what you need: cooking.stackexchange.comPierro
The cake is a lieBeaut
the main solutions did not work for me either, this one did. ErrorOnDuplicatePublishOutputFiles is completely ignored when building an EF migrations bundle.Fortunna
C
13

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://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer?view=azure-devops

Culottes answered 3/2, 2022 at 20:39 Comment(2)
Question about this not working in an ADO pipeline. I have a pipeline what runs windows-latest and it's ran successfully since august 2021. Was there a change in the windows-latest image that would make this fail? It started failing yesterday.Microphyte
This answer works if you combine it with the selected answer in Azure DevOps. Coz In my case I already has the SDK setup but it still fails. So, in case you encounter this. A combination of this and the selected answer worked for me.Resupinate
D
10

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
Dorkas answered 17/12, 2021 at 15:1 Comment(1)
FYI 1 specifically needs to be in a property group, per the reference materialCounterespionage
C
8

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.

Crystallite answered 12/4, 2022 at 17:4 Comment(0)
B
7

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.

enter image description here

Blagoveshchensk answered 24/4, 2022 at 7:5 Comment(0)
C
5

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.

Ceramal answered 23/12, 2021 at 5:16 Comment(1)
Solving the dependency issue is the real solution from my perspective. We should not reference executables directly in another executable. Thanks for the insight.Tabbatha
J
5

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

enter image description here

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

enter image description here

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

Jerejereld answered 21/3, 2022 at 5:58 Comment(1)
tnx but doesnt solved my issue.Catchfly
E
3

I added caching of nuget in the CI Pipeline, https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/caching-nuget?view=azure-devops

and therefore needed the files packages.lock.json in the root of all projects, leading to the error

"C:\hostedtoolcache\windows\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: D:\a\1\s[PROJECT1]\packages.lock.json, D:\a\1\s[PROJECT2]\packages.lock.json ...."

Thus exluding the files from output folder didn't change the error and build failure.

The following worked : ErrorOnDuplicatePublishOutputFiles>false

   <PropertyGroup>   
       <!-- creates nuget lock file packages.lock.json in the root folder, 
needed to cache packages in azure pipeline-->
 <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    <!-- solves build error duplicate files -->
<ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>
    </PropertyGroup> 

NOTE: I also had to ad the azure step "nuget authentication" after the restore step (no config added); this might be due to packages from both official and organization sources.


//... YAML ... 
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 6.0.300'
  inputs:
    version: 6.0.300
    includePreviewVersions: true

- task: NuGetToolInstaller@1
  displayName: 'Use NuGet '

- task: Cache@2
  displayName: Cache
  inputs:
    key: 'nuget | "$(Agent.OS)" | **/packages.lock.json,!**/bin/**,!**/obj/**'
    path: '$(NUGET_PACKAGES)'
    cacheHitVar: 'CACHE_RESTORED'
    restoreKeys: |
     nuget | "$(Agent.OS)"
     nuget

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: ProbablyTheBestSolution.Ever.sln
    feedsToUse: config
    nugetConfigPath: NuGet.Config
  condition: ne(variables.CACHE_RESTORED, true)

- task: NuGetAuthenticate@1
  displayName: 'NuGet Authenticate'

- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    //...
Eads answered 9/3, 2023 at 19:55 Comment(1)
I had the exact same setup and indeed adding <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles> to every project fixed my Docker build process, thanks!Ecumenical
L
2

I have two projects, API and Hangfire. The duplication was in publishing hangfire since it uses both API and Hangfire projects and I solved it by removing appsettings files before the publish step.

COPY . .
RUN find ${API} -iname "appsettings*.json" -exec rm {} \;
RUN dotnet publish ${HANGFIRE}/*.csproj --configuration Release --output out --no-restore
Lesslie answered 11/12, 2022 at 17:1 Comment(0)
C
1

in my case, the package.json was the duplicated file and no need for it on production, so I excluded it.

   <ItemGroup>
     <Content Remove="package.json" />
     <None Include="package.json" />
   </ItemGroup>
Curricle answered 28/4, 2023 at 13:4 Comment(0)
C
1

For me it was caused due to accidentaly referencing another project inside the project being built. Check your dependencies.

Cystoid answered 16/1, 2024 at 14:47 Comment(0)
S
0

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"

Salenasalene answered 12/11, 2021 at 0:4 Comment(2)
I would not recommend this - you are changing the installed files of the .NET 6 SDK. Not only do you have to repeat this when a newer version of the SDK is installed. You also have a hard time rolling this out to other devs. Setting the ErrorOnDuplicatePublishOutputFiles parameter can be checked into a repository, e.g. as a build script or as part of a csproj file.Equinox
remove that whole block make solution for me with old wix installer project; thxPadlock
S
0

My issue was due to the fact that NServiceBus was generating SQL files.

That was fixed by adding the following to the corresponding .csproj folders:

<PropertyGroup>
<SqlPersistenceGenerateScripts>false</SqlPersistenceGenerateScripts>
</PropertyGroup>
Stoltzfus answered 9/1, 2024 at 12:7 Comment(1)
I've ran into this with several projects referencing SQL Persisntect. Disabling script generation works and combined with Directory.Build.props at the root level solved my error.Peugia
V
0

I ran into this after updating my project from .NET 6 to .NET 8. I somehow ended up with isolated function references (Workers) in my Razor Class Library project. (Not sure if I added them there or the migration assistant did that for me). It worked fine after I removed those worker references.

enter image description here

Verdure answered 20/2, 2024 at 23:22 Comment(0)
B
-1

I just solved this with core 2.2. The issue was 3 files were in the main project folder that was not supposed to be there. I removed 3 files from the main folder and that fixed the issue. Apparently someone copied the files from the obj folder to the main project folder and that caused us to see this error.

Botryoidal answered 4/1, 2024 at 14:11 Comment(1)
As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.Megasporophyll

© 2022 - 2025 — McMap. All rights reserved.