.NET Core 6 Found multiple publish output files with the same relative path

[azampagl]

Describe the bug

On .NET Core 6 where when publishing with Web Deploy via Visual Studio 2022. I'm receiving the following error:

Error Found multiple publish output files with the same relative path: C:\Work\MySolution\A\appsettings.json, C:\Work\MySolution\B\appsettings.json, C:\Work\MySolution\A\appsettings.Staging.json, C:\Work\MySolution\B\appsettings.Staging.json, , C:\Work\MySolution\A\appsettings.Development.json, C:\Work\MySolution\B\appsettings.Development.json

There is no issues when building, just publishing.

I have two ASP.NET Core 6 projects. Project "A" references project "B" (I know B should really be a class library, but go with me).

I am aware that this is expected functionality in .NET Core 6 (https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output). However, I cannot seem to tell project "A" to ignore project "B" appsettings files. Previously ignoring the files worked. I am aware of the ErrorOnDuplicatePublishOutputFiles property I can set, but I'm trying to strictly tell it not to include project B's appsetting files.

I've tried various other combos of the following, but none of it seems to work. Not sure if there is an issue with VS2022 with new and/or deprecated directives that I am unaware of that is also contributing.

To Reproduce

Example 1: Tried typical content update approach (supposedly does not work after VS 15.3). Also tried with absolute paths.

A.csproj

...

<ItemGroup>
  <ProjectReference Include="..\B\B.csproj">
    <PrivateAssets>all</PrivateAssets>
  </ProjectReference>
</ItemGroup>
  
<ItemGroup>    
  <Content Update="..\B\appsettings.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
  <Content Update="..\B\appsettings.*.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
</ItemGroup>

...

Example 2: Tried typical content remove approach. Also tried with absolute paths.

A.csproj`

...

<ItemGroup>
  <ProjectReference Include="..\B\B.csproj">
    <PrivateAssets>all</PrivateAssets>
  </ProjectReference>
</ItemGroup>
  
<ItemGroup>    
  <Content Remove="..\B\appsettings.json" />
  <Content Remove="..\B\appsettings.*.json" />
</ItemGroup>

<ItemGroup>    
  <None Include="..\B\appsettings.json" />
  <None Include="..\B\appsettings.*.json" />
</ItemGroup>

...

Example 3: I tried using the GeneratePathProperty path to make sure it was directly ignoring project B's files.

A.csproj

...

<ItemGroup>
  <ProjectReference Include="..\B\B.csproj" GeneratePathProperty="true">
    <PrivateAssets>all</PrivateAssets>
  </ProjectReference>
</ItemGroup>
  
<ItemGroup>    
  <Content Update="$(PkgB)\appsettings.json" CopyToPublishDirectory="Never" />
  <Content Update="$(PkgB)\appsettings.*.json" CopyToPublishDirectory="Never" />
</ItemGroup>

...

Example 4: Modified pubxml to ignore specific files. Tried with absolute paths too.

A.pubxml

...

<ExcludeFilesFromDeployment>..\B\appsettings.json;..\B\appsettings.Staging.json;...</ExcludeFilesFromDeployment> 

...

Example 5: Modified pubxml file to explicity ignore project B files. Tried absolute paths as well.

A.pubxml

...

<ItemGroup>
  <ResolvedFileToPublish Include="..\B\appsettings.json">
    <CopyToPublishDirectory>Never</CopyToPublishDirectory>
  </ResolvedFileToPublish>
  <ResolvedFileToPublish Include="..\B\appsettings.Staging.json">
    <CopyToPublishDirectory>Never</CopyToPublishDirectory>
  </ResolvedFileToPublish>
  <ResolvedFileToPublish Include="..\B\appsettings.Development.json">
    <CopyToPublishDirectory>Never</CopyToPublishDirectory>
  </ResolvedFileToPublish>
  <ResolvedFileToPublish Include="..\B\appsettings.Backup.json">
    <CopyToPublishDirectory>Never</CopyToPublishDirectory>
  </ResolvedFileToPublish>
</ItemGroup>

...

Exceptions (if any)

Further technical details

• ASP.NET Core version: 6.0.0
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: VS 2022
• Include the output of dotnet --info:

dotnet --info Output

.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

[javiercn]

@azampagl thanks for contacting us.

A few things, I don't think there's anything specific about ASP.NET Core, so I'm going to transfer the issue to the SDK and let other folks chime in. That said, you need to apply any change you want into project B.csproj, otherwise it won't have any effect.

You can probably write some MSBuild target to remove the files if necessary before the GetCopyTo(Output|Publish)DirectoryItems, but that's outside of the scope of the issues we deal with in this tracker.

[azampagl]

@javiercn Thanks!

In regards to

That said, you need to apply any change you want into project B.csproj, otherwise it won't have any effect.

How would that work? The issue is I still would like to publish project B's appsettings.json when publishing project B. However, when publishing project A, I only want to publish project A's appsettings.json and not project B's.

[javiercn]

@azampagl If that's what you want, the only way I know to achieve that is via a custom target. In general, referencing a web app from another web app is not a scenario we support nor something we test for.

[vijayrkn]

Looks like you are running into this breaking change documented here : https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output

You can follow the recommended suggestions to fix this : https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output#recommended-action

[seanamos]

The behavior is quite unexpected, it seems even more unexpected given: #3871

➜ dotnet --version    
6.0.100

MySln.sln
|
|-->ProjectA.csproj (net6.0/Microsoft.NET.Sdk)
|        |
|        |-->file.txt (CopyToOutputDirectory="PreserveNewest")
|
|-->ProjectB.csproj (net6.0/Microsoft.NET.Sdk, references ProjectA.csproj)
         |
         |-->file.txt (CopyToOutputDirectory="PreserveNewest")

dotnet publish ProjectB

/usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: /xxx/file.txt, /xxx/file.txt. [xxx/ProjectB.csproj]
NETSdkError: /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: /xxx/file.txt, /xxx/file.txt.

There is <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>, but that exhibits the same "undefined" overwriting behavior that was supposed to be addressed here: #3871

I'm pretty sure the desired behavior is to be able to reference a project and optionally not copy/publish any/specific content files from that project.

appSettings.json is the originally given example, but this obviously happens with any file.

[fritz-net]

For me this works on VS build and cmd build, however I get the same error when doing dotnet-ef migrations bundle:
error NETSDK1152: Found multiple publish output files with the same relative path: and the affected files are appsettings.Development.json and appsettings.json (I don't have other appsettings like for prod (yet))

EDIT: I forgot to mention, that adding <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles> to Directory.Build.props did not affect the migrations bundle operation (since it is in a generated project in a temp folder). And setting the Property via CMD /p:ErrorOnDuplicatePublishOutputFiles=false is not recognized.

[vijayrkn]

EDIT: I forgot to mention, that adding <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles> to Directory.Build.props did not affect the migrations bundle operation (since it is in a generated project in a temp folder). And setting the Property via CMD /p:ErrorOnDuplicatePublishOutputFiles=false is not recognized.

You may need to set this in the csproj or the Directory.Build.Targets depending on when this property is evaluated.

[fritz-net]

@vijayrkn I can't set it in the migration bundle project since its autogenerated

[jchannon]

I've just hit the same issue.

I have 3 Azure Functions apps each with a host.json file. These get published individually so need a host.json.
I have a database migrator app that references these 3 projects and when publishing it I now get the "multiple files in the same path" error. Adding the below to the migrator app doesn't fix it:

 <ItemGroup>
        <Content Remove="host.json"/>
        <None Include="host.json">
            <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
            <CopyToPublishDirectory>Never</CopyToPublishDirectory>
        </None>
    </ItemGroup>

How can I get this to work?

[Defria]

set this in your project.csproj file

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

[ruffin--]

You can follow the recommended suggestions to fix this : https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output#recommended-action

That's my issue, but there wasn't much in the way of fixing it:

Ideally, you should update your project to avoid situations where multiple files with the same name are copied to the publish output. The error message includes the name of the duplicate file. Some causes for duplicate files include:

• An ASP.NET Core project that references an ASP.NET Core web service, and each has its own appsettings.json file.
  ...

Yep, that's why I'm getting it. So how do I update my project to avoid this again? 😉

I mean, sure, it adds later...

• Alternatively, you can set the ErrorOnDuplicatePublishOutputFiles property to false.

... but that's no longer an "alternate" solution if I'm not given a preferred solution. And if the two "Some causes for duplicate files" examples mean I can't use the preferred solution, that oughta be made clear. /shrug

[bobharing]

We have the same issue with out projects. There are several project referencing each other and these projects also have an applicationinsights.config file. We get the issue described above when doing a publish because the projects output to the publish out location.

[connershoop]

I am having the same issue, is there any update on this?

Adding ErrorOnDuplicatePublishOutputFiles to our csproj files broke our application.

[Mhsoun]

MS pointed to the exact cause of the problem, but then what? Anyone has more than appsettings file and managed to fix this error?
"An ASP.NET Core project that references an ASP.NET Core web service, and each has its own appsettings.json file."
https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output

[robwillup]

For me it's happening with NLog.config.
I'd be nice if there was a way to specify in csproj which file we want to be published. Maybe by pointing a path for example.

[ericcmmi]

@robwillup for NLog.config the package reference isn't necessary once you have a config file created. You can delete the packagereference for NLog.config to and set the config file to "copy if newer". See the readme here https://www.nuget.org/packages/NLog.Config/

[IanKemp]

When encountering duplicate files, why can't publish simply choose the file that is being referenced by the project being published? In other words, why does this need to be a build-stopping error as opposed to a warning?

The web page describing this change is, in typical Microsoft fashion, chronically useless, specifically the "Recommended actions":

• "Ideally, you should update your project to avoid situations where multiple files with the same name are copied to the publish output." Whoa dude, it's almost as if the error message didn't already tell me the same thing. How about the page actually tells me how to do that update? I.e., how to select which of the duplicate files to keep?
• "Alternatively, you can set the ErrorOnDuplicatePublishOutputFiles property to false." Alternatively, you could've made false the default and allowed developers to opt-in to having their builds break due to this issue, instead of having their (currently working) builds arbitrarily break because of an upgrade from .NET 5 to .NET 6. And if you're just going to recommend that people turn off the error, why bother even emitting it?

You can probably write some MSBuild target to remove the files if necessary before the GetCopyTo(Output|Publish)DirectoryItems

This tells me that you did not bother thinking about how to usefully solve this problem, you just decided to make it visible. That's not helpful, that is in fact the exact opposite.

but that's outside of the scope of the issues we deal with in this tracker.

Really? Really?

Telling people how to solve an error that you imposed on them is "outside of the scope of the issues we deal with in this tracker"? I just... wow.

How long before obvious bug reports are also "outside of the scope of the issues we deal with in this tracker"?

[ssavkovic]

Same issue here. We have ASP.NET Core assembly referenced by test assembly. We need different default settings in appsettings.json for different runs. Not clear to me why is referenced assembly appsettings.json even being picked up? We really just need appsettings.json from the project being built as well as any other files.

[seanamos]

For those arriving here, I don't have good news.

The reason the documentation around this seems so inadequate is because there isn't actually an easy workaround or a good solution at the moment.

The SDK has always had a problem where referencing projects with output files copies those files into your output, potentially overwriting your files if there are name collisions. They chose to introduce an error, because you probably don't want that to happen and it creates hard to diagnose bugs, but they didn't really provide any way to actually fix the problem (exclude files from referenced projects being copied or choose where to copy those files).

We ended up begrudgingly doing something like this:

MySln.sln
|
|-->ProjectA.csproj
|        |
|        |-->appsettings.json
|
|-->ProjectB.csproj (references ProjectA.csproj)
         |
         |-->projectb-appsettings.json

Horrible, but there really isn't any other way at the moment.

[dmartensson]

I just stumbled on the same problem when upgrading from NET5 to NET6 but maybe in a slightly different setting.

We have multiple projects in the same solution, all with their own application.json but we build these on team city and create nugets that are then deployed.

The publish directories are all under each project so the "duplicate files" are never overwriting each other, the "relative" path is the same "under the project" but that does not mean its the dame actual directory.

But now with NET 6 installed we can no longer build this project and we do need the application.json files copied to the output directory.

Solving this for us is going to be a major problem if it means we need to split all the projects up into separate solutions, thats 10 new build pipelines we need to create and possibly having to split up the repositories also.

I understand if this actually did overwrite but I have checked, it does not overwrite using NET5.

Are we missing something else or is this a case that was overlooked?

[Timovzl]

In my attempts, the use of <ErrorOnDuplicatePublishOutputFiles>False</ErrorOnDuplicatePublishOutputFiles> seems to work consistently thus far. Since the outer project depends on the inner project, it makes sense that the inner project would go first, allowing the outer project to then overwrite its files. Does anybody know how reliable this theory is?

[Timovzl]

As to "why would you want to reference a runnable project", let me contribute another use case.

On all environments except Production, we have a simulator application that mimics the third parties we connect to. For this necessary evil of a project, we had to choose between either duplicating package references from another web application project or taking a reference to that other web application. Each has its downsides, but we chose the latter, in order to constraint any disadvantages to the necessary evil that is causing them.

[OskarKlintrot]

My use case is a bit different from @Timovzl. I want to reference and run a web project from a console app. The reason being that dotnet tools are extremely easy to create and distribute but I want to have a GUI for some use cases. So, I would love to be able to run a Razor Pages web app from the CLI.

[holm76]

I just ran into this problem. I have a solution with multiple Asp.Net Core 6 Web Api projects. They have worked great for a long ting. Then I started getting this problem.
Project A would not deploy because of file collision with appsetting.json in Project B only neither project A or project B is dependent on each other. They do share other class libraries but they know nothing of each other. Project B was able to deploy no problem.

How is this happening? I tried to restart VS but that did not help. Google sent me here.

I may have solved my own little problem for maybe only a short period. Because Project A is not dependent on Project B I removed Project B form my solution and was able to publish Project A. I then added Project B again to test if the error came back but I was still able to publish. Don't know what caused my error but maybe somebody can use this info for something.

[real-zony]

This has also been a problem for us, and currently we can only ignore this use case by using <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>.

[mikeobrien]

Running into the same issue. In my case we have a test suite project referencing website projects for unit testing. ErrorOnDuplicatePublishOutputFiles seemed to work for a few weeks but all of a sudden stopped working...

[ziachap]

This issue has plagued all my projects for a long time and it doesn't seem like anything is going to be done about it. Having to do what seanamos said, just make sure the files in different projects have different names so they don't overwrite eachother. I feel like this could be easily solved with the ability to add some tag to ProjectReference that prevents content files being copied to referenced projects or something similar:

<ProjectReference IncludeContent="false" Include="..\MyProj\MyProj.csproj" />

[Neuroquila-n8fall]

In addition to @ziachap suggestion I would rather make referenced projects NEVER copy non-source files to the destination. It just doesn't make any sense to have that feature in the first place. I would make this an opt-in solution so you have to be explicit about this behavior.

It's okay to introduce breaking changes but without any good solution on how to circumvent the outcome of a breaking change, it's a downright frustrating experience.

[mcfriend99]

In my attempts, the use of <ErrorOnDuplicatePublishOutputFiles>False</ErrorOnDuplicatePublishOutputFiles> seems to work consistently thus far. Since the outer project depends on the inner project, it makes sense that the inner project would go first, allowing the outer project to then overwrite its files. Does anybody know how reliable this theory is?

No. Turns out that's not how it works. The referenced project artefacts still overwrote the project's own in our situation.

[Creastoff]

Why do some publishable projects rely on another publishable project? What scenarios are there where you cannot store the shared content in a class library project?

[Timovzl]

@Creastoff A few use cases have been mentioned in the thread.

[chrkon]

Hello, I ran into this issue yesterday after a Visual Studio 2022 Update to version 17.8.3. But it seems not to be related to this update. After rollback to Visual Studio 2022 version 17.7.6 this issue is still there.

It is an WinUI3 project with a bunch of nuget packages. When I want to publish it, we get now this error:
Found multiple publish output files with the same relative path:

I found these two files written on the output window:

1. obj\x64\Release\net6.0-windows10.0.22621.0\win-x64\MsixContent\Microsoft.Web.WebView2.Core.dll
2. obj\x64\Release\net6.0-windows10.0.22621.0\win-x64\R2R\Microsoft.Web.WebView2.Core.dll

As you can see, the file "Microsoft.Web.WebView2.Core.dll" is copied from two different folders, but both folders are generated during the publishing process. Of course I have already cleaned up the folders and the obj and the bin folder are deleted before publishing.

And this file (Microsoft.Web.WebViw2.Core.dll) is not a direct part of our project. I assume it is part of one of the used nuget packages. But I am not sure. I have no idea from where this nuget package file is comming from.

And I don't understand why the files have different sizes. In the R2R folder it has a size of 429056 Bytes and in the MsixContent folder it has 666560 Bytes.

Does anybody have an idea or a hint for me? How can I solve this issue?

Kind regards,
Christof, Germany

Edit: Rollback info added, 2023-12-19 13:25

[Ganesh-Ponipireddy]

I'm also facing the similar issue with dotnet 8. In local code is publishing successfully but when building and publishing in container it is giving multiple output files error.
/obj/Release/net8.0/linux-x64/apphost,
/obj/Release/net8.0/apphost,

Even I tried adding
<ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles> but it did not solve my issue

[ncikic]

Same here. Dotnet 7 publishing blazor maui hybrid. With dotnet 6 it was working. I had problems in running another app inside container with ef core 6 so I updated projects to dotnet 7 and ef core 7. Now this other app is working but blazor hybrid is not publishing anymore..

[cristalink]

The problem persists in .NET 8. Perhaps, the author of this issue (@azampagl) should edit the title to remove "6" from it. I hope this might help promoting the fix.

[ericskelton]

Theres a solution to this problem posted on stackoverflow by user1589652 that worked for me. posting the solution here for visibility.

<Target Name="DeleteAllAppsettings" AfterTargets="PostBuildEvent">
		<ItemGroup>
			<AppSettingsFilesToDelete Include="$(OutputPath)appsettings*.json" />
		</ItemGroup>
		<Delete Files="@(AppSettingsFilesToDelete)" />
		<Message Text="Deleted appsettings JSON files: @(AppSettingsFilesToDelete)" Importance="high" />
	</Target>
	
	<Target Name="CopyProjectAppSettings" AfterTargets="PostBuildEvent">
		<ItemGroup>
			<AppSettingsJsonFiles Include="appsettings*.json" />
		</ItemGroup>
		<Copy SourceFiles="@(AppSettingsJsonFiles)" DestinationFolder="$(OutputPath)" SkipUnchangedFiles="false" />
		<Message Text="Copied project appsettings JSON files to output directory." Importance="high" />
</Target>

This adds post build events that deletes all appsettings files and then copies in the appsettings files in the project's root directory.

I like this solution a lot better than renaming the appsettings files like the others in this thread are suggesting

[TheInevitable360]

i had the same issue when i tried to publish an application which had 2 projects. porject A and project B. i just simply added
win-x64 to PropertyGroup of projects. you can find the appropriate identifiers here. i hope this works for you as well

[DavidVTurley]

I am getting a wierd issue as well.
I am working in a solution that contains 4 projects. I reference 1 of them from my project. That solution is marked as a library class. It also has 0 references to other projects.

However when I go to build my project, it also builds and dumps the non referenced files from the other projects into the \bin folder.

And when I go to publish my program, it states that the appsettings.json is being found in the project that shouldnt even be built as there is no reference to it.

[SeMuell]

As mentioned by others, we have the same problem and still unsolved... We have one big solution with around 90 projects, some of them are background services and have their own appsettings.json which are not referenced by any other project.

The appsettings.json from the background services are always overwriting the main project appsettings.json... The only, very ugly solution so far is to rename the appsettings.json of each and every background service.

The solution proposed by @ericskelton did unfortunately not work, since we do link one appsettings.json which is discarded with that approach.

[fardarter]

Absolutely mad that this has no solution.