dotnet
.NET Core 6 Found multiple publish output files with the same relative path
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
@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.
@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.
@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.
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
The behavior is quite unexpected, it seems even more unexpected given: https://github.com/dotnet/sdk/issues/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: https://github.com/dotnet/sdk/issues/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.
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.
EDIT: I forgot to mention, that adding
<ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>toDirectory.Build.propsdid not affect themigrations bundleoperation (since it is in a generated project in a temp folder). And setting the Property via CMD/p:ErrorOnDuplicatePublishOutputFiles=falseis not recognized.
You may need to set this in the csproj or the Directory.Build.Targets depending on when this property is evaluated.
@vijayrkn I can't set it in the migration bundle project since its autogenerated
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?
set this in your project.csproj file
<PropertyGroup>
....
<ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>
</PropertyGroup>
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
ErrorOnDuplicatePublishOutputFilesproperty 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
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.
I am having the same issue, is there any update on this?
Adding ErrorOnDuplicatePublishOutputFiles to our csproj files broke our application.
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
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.
@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/
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
ErrorOnDuplicatePublishOutputFilesproperty to false." Alternatively, you could've madefalsethe 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"?
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.
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.
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?
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?
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.
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.
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.
This has also been a problem for us, and currently we can only ignore this use case by using <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>.
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...
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" />
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.
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.
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?
