CODEWITHSUNDEEP
c#azurepublish.net-6.0
Nader Gharibian Fard
Nader Gharibian Fard

Reputation: 8135

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

Upvotes: 233

Views: 162766

Answers (17)

nimblebit
nimblebit

Reputation: 559

I encountered this same error while publishing a lambda function in VS 2022

... publish: C:\ProgramFiles\dotnet\sdk\8.0.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5):
error NETSDK1152: Found multiple publish output files with the same relative path:
C:\function1\appsettings.json,  
C:\function2\appsettings.json.  
[C:\function1\name.csproj]
ERROR: The dotnet publish command return unsuccessful error code

The issue in this instance was the function being published was referencing another lambda project in the solution. The 2nd project had the same file structure.

Removing the reference to the incorrect project allowed the upload utility to complete.

Upvotes: 0

wilsjd
wilsjd

Reputation: 2258

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

Upvotes: 0

Liam Björkman
Liam Björkman

Reputation: 37

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

Upvotes: 2

Joel Wiklund
Joel Wiklund

Reputation: 1875

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>

Upvotes: 0

Eagles757
Eagles757

Reputation: 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.

Upvotes: -1

Muhammed ASLAN
Muhammed ASLAN

Reputation: 190

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>

Upvotes: 1

JimiSweden
JimiSweden

Reputation: 814

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

Upvotes: 3

Sohail Ahmed
Sohail Ahmed

Reputation: 1190

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

Upvotes: 2

Nader Gharibian Fard
Nader Gharibian Fard

Reputation: 8135

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>

Upvotes: 431

Kebechet
Kebechet

Reputation: 2417

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

Upvotes: 7

Ali Mahmoodi
Ali Mahmoodi

Reputation: 1204

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.

Upvotes: 13

Kiarash
Kiarash

Reputation: 1919

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

Upvotes: 5

JCisar
JCisar

Reputation: 2674

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

Upvotes: 13

cherry
cherry

Reputation: 722

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.

Upvotes: 41

Mark Foreman
Mark Foreman

Reputation: 2500

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.

Upvotes: 5

Ben Sampica
Ben Sampica

Reputation: 3412

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

Upvotes: 12

George M
George M

Reputation: 83

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"

Upvotes: 1

Related Questions