Sdk: System.Exception: Publish has encountered an error

Created on 10 Feb 2020  路  18Comments  路  Source: dotnet/sdk

I'm facing an issue with dotnet publish command. I'm able to compile XX times and then without a valid reason I'm not able to publish the exe anymore.
Also deleting bin and obj nothing change.
Another strange thing is that after the first broken publish I need administrator permissions to delete bin folder.
Here the errors

Publish has encountered an error.
Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. 

A diagnostic log has been written to the following location:
"C:\Users\enricobenedos\AppData\Local\Temp\tmp616C.tmp"

.tmp file content

2/10/2020 8:02:07 AM
System.AggregateException: One or more errors occurred. ---> System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. 
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Microsoft.Publish.Framework.Model.DefaultPublishSteps.<>c__DisplayClass26_0.<IsBuildCompletedSuccessfully>b__2()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Publish.Framework.Model.DefaultPublishSteps.<DefaultCorePublishStep>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Publish.Framework.ViewModel.ProfileSelectorViewModel.<RunPublishTaskAsync>d__213.MoveNext()
---> (Inner Exception #0) System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---

System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. 

===================

and with PowerShell the result is the same

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 725.51 ms for C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerCore\FCSInstallerCore.csproj.
  Restore completed in 725.48 ms for C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj.
  FCSInstallerCore -> C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerCore\bin\Release\netcoreapp3.1\FCSInstallerCore.dll
  FCSInstallerGUI -> C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\bin\Release\netcoreapp3.1\win-x64\FCSInstallerGUI.dll
C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018: The "GenerateBundle" task failed unexpectedly. [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]
C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018: System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]
C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018:    at Microsoft.NET.HostModel.Bundle.Bundler.GenerateBundle(IReadOnlyList`1 fileSpecs) [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]
C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018:    at Microsoft.NET.Build.Tasks.GenerateBundle.ExecuteCore() [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]
C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]
C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]
C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]

These are the main project references
image

Ans these are the referenced project dependencies
image

Most helpful comment

Based on the feedback of the conflicting nuget dependencies I was able to create a bare bones azure function with the same functionality as before and got it to publish.

I think the real issue here is that since conflicting dependencies is a measurable error, then "We were unable to determine the cause of the error" is not valid error text. There needs to be a better error message, especially since this error reportedly also hides VS timing out. It leaves the actual root cause up to a lot of guessing and hits on several historic (and closed) github issues from multiple repositories.

All 18 comments

Getting the same error when trying to publish to a local folder a .NET Core 3.1 console app

+1, trying to publish a self-contained .NET Core 3.1 console app. @karelz can you help find an owner for this?

Not sure who the owner is ... @samsp-msft?

Does it repro with a simple HelloWorld app? (having a minimal repro steps clearly described usually helps to speed up investigations and solutions)

Yes I was able to reduce the repro.

  1. File -> New project .NET Core Console application
  2. Target .NET Core 3.1
  3. Change the .csproj to have the following PackageReferences:
<ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.9.8">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
    <PackageReference Include="System.Runtime" Version="4.3.1" />
</ItemGroup>
  1. Try to publish using any kind of a profile (I'm using self-contained, Debug, win-x64):

image

@wli3 @swaroop-sridhar

Same issue. Publish worked before updating visual studio to latest version. Now seeing this error when publishing a previously working V2 azure function project and when publishing a brand new V3 project.

Have already followed common troubleshooting such as turning off WEBSITE_RUN_FROM_PACKAGE
and updating extension Cloud Explorer for VS Preview.

Troubleshooting resources are saying that this is a VS timeout error but I suspect there is more to it. Here is a reference to an older issues with similar output that has the above steps listed
https://github.com/Azure/Azure-Functions/issues/1108

I tried out the repro provided by @jevansaks. In this case, looks like the publish fails because of mismatch in nuget package versions.

Here's the output:

D:\test\pub>dotnet publish -r win-x64
Microsoft (R) Build Engine version 16.6.0-preview-20162-03+00781ad13 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Collections from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Collections (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Collections (>= 4.0.11)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Diagnostics.Debug from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Diagnostics.Debug (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Diagnostics.Debug (>= 4.0.11)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.IO from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.IO (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.IO (>= 4.1.0)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.IO.FileSystem.Primitives (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem.Primitives (>= 4.0.1)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Resources.ResourceManager from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Resources.ResourceManager (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Resources.ResourceManager (>= 4.0.1)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Runtime.Extensions from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Runtime.Extensions (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Runtime.Extensions (>= 4.1.0)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Runtime.Handles from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Runtime.Handles (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> System.Runtime.Handles (>= 4.0.1)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Runtime.InteropServices from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Runtime.InteropServices (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.Runtime.InteropServices (>= 4.1.0)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Text.Encoding from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Text.Encoding (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Text.Encoding (>= 4.0.11)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Text.Encoding.Extensions from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Text.Encoding.Extensions (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Text.Encoding.Extensions (>= 4.0.11)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Threading from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Threading (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Threading (>= 4.0.11)
D:\test\pub\pub.csproj : error NU1605: Detected package downgrade: System.Threading.Tasks from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Xml.ReaderWriter 4.0.11 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Threading.Tasks (>= 4.3.0)
D:\test\pub\pub.csproj : error NU1605:  pub -> Newtonsoft.Json 9.0.1 -> System.Threading.Tasks (>= 4.0.11)

Also, this failure is deterministic.

The problem reported by @enricobenedos is a different issue.

C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(868,5): error MSB4018: System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath [C:\Projects\FCSSystem\Supervisore.NET\FCSInstallerGUI\FCSInstallerGUI\FCSInstallerGUI.csproj]

This means that there were multiple source files with the same name that are trying to be copied to the publish location. When the app is published as a single-file, this case is detected, and we throw an error. During a normal publish, this doesn't result in an error but one file will overwrite the other
(a known discrepancy to be addressed).

Anyway, the problem almost always arises because of conflicts in nuget packages causing colliding resources (ex: .net core and .net framework binaries both getting copied to the output). The SDK detects and removes duplicates in many cases, but it is not 100% fool-proof.

So, you can look at the verbose log of the build to identify the duplicate input to the GenerateBundle task, and trace them back to the originating package.

However, I expect this failure occur every time, so I'm a bit surprised to hear that its not detereministic.

Another strange thing is that after the first broken publish I need administrator permissions to delete bin folder.

This is also very surprising. Can you please provide steps to help reproduce the problem?
Do you get an access-denied error? Or do the folders re-appear? Sometimes VS re-creates the obj-bin folders to restore packages.

Based on the feedback of the conflicting nuget dependencies I was able to create a bare bones azure function with the same functionality as before and got it to publish.

I think the real issue here is that since conflicting dependencies is a measurable error, then "We were unable to determine the cause of the error" is not valid error text. There needs to be a better error message, especially since this error reportedly also hides VS timing out. It leaves the actual root cause up to a lot of guessing and hits on several historic (and closed) github issues from multiple repositories.

I guess I came from the wrong place, creating a new issue

I hit this painful issue as well. By inspecting the output I was able to determine that log4net 2.0.8 was the package that was triggering the conflicts in my particular case. Adding the following explicit _system_ package references on _my lowest project_ that uses log4net addressed it:

  <ItemGroup>
    <PackageReference Include="DryIoc.dll" Version="4.2.1" />  
    <PackageReference Include="log4net" Version="2.0.8" />  
    <PackageReference Include="System.Diagnostics.Debug" Version="4.3.0" />  
    <PackageReference Include="System.IO.FileSystem" Version="4.3.0" />  
    <PackageReference Include="System.Net.NameResolution" Version="4.3.0" />  
    <PackageReference Include="System.Net.Primitives" Version="4.3.0" />  
    <PackageReference Include="System.Runtime.Extensions" Version="4.3.1" />  
    <PackageReference Include="System.Runtime.InteropServices" Version="4.3.0" />  
    <PackageReference Include="System.Threading" Version="4.3.0" />  
  </ItemGroup>

I met the same issue as @AdamCaviness described which caused by log4net 2.0.8. My workaround is using msbuild instead of dotnet publish.
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/visual-studio-publish-profiles?view=aspnetcore-3.1#folder-publish-example

msbuild /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile

PS, before that you should fix the Error NU1605 using <NoWarn>NU1603</NoWarn>, see the reference here

Just came across this issue. Renaming the output exe resolved the issue. Surprised it didn't just overwrite the old exe. My output options were for a single file and with netcoreapp3.1 and win-x64. And mine is a simple service app.

I had a similar root cause as @swaroop-sridhar mentioned here: https://github.com/dotnet/sdk/issues/10621#issuecomment-615672587

My output:

PM> dotnet publish -r linux-x64
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

Determining projects to restore...
C:\Usersdivan\source\repos\BetterConsoleApp\ConsoleUI\ConsoleUI.csproj : error NU1605: Detected package downgrade: System.Diagnostics.Debug from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. [C:\Usersdivan\source\repos\BetterConsoleApp\BetterConsoleApp.sln]
.
.
.
Failed to restore C:\Usersdivan\source\repos\BetterConsoleApp\ConsoleUI\ConsoleUI.csproj (in 835 ms).

My solution:
Install the System.Diagnostics.Debug NuGet package.

This fixed the problem and I was able to publish after that:
PM> dotnet publish -r linux-x64
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

Determining projects to restore...
Restored C:\Usersdivan\source\repos\BetterConsoleApp\ConsoleUI\ConsoleUI.csproj (in 858 ms).
ConsoleUI -> C:\Usersdivan\source\repos\BetterConsoleApp\ConsoleUI\bin\Debug\netcoreapp3.1\linux-x64\ConsoleUI.dll
ConsoleUI -> C:\Usersdivan\source\repos\BetterConsoleApp\ConsoleUI\bin\Debug\netcoreapp3.1\linux-x64\publish\
PM> dotnet publish -r linux-x64

Is this problem only in .NET Core projects? I am very interested in finding out if it is, and why, if that is the case.

When I run it in Visual Studio, I get the "We were unable to determine the cause of the error".

When I run it from the command line, it works:

dotnet publish -r linux-x64

Welcome to .NET Core 3.1!

SDK Version: 3.1.302
...

...

Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Determining projects to restore...
Restored ...\MyProject.csproj (in 33.98 sec).
RaidManager -> ...\bin\Debug\netcoreapp3.1\linux-x64\MyProject.dll
RaidManager -> ...\bin\Debug\netcoreapp3.1\linux-x64\publish\

Edit: Known issue with the Serilog package, fixed in dev build: https://github.com/serilog/serilog-sinks-file/issues/177

I seem to be having the same package version problems (found my way here thanks to the worthless "unable to determine the cause" publish error message from within VS), but referencing the downgrade versions doesn't help. If I'm reading the error message correctly, it looks like the linux-arm runtime requires a newer version. In this case the profile is an attempt to deploy a 32-bit ARM single-file build using Serilog's file sink which apparently requires some System.IO.xxx 4.0.1 packages ... but the runtime portion of the error messages shows -> runtime.unix.System.IO.FileSystem 4.3.0 -> System.Runtime.Handles (>= 4.3.0)... not sure where the 4.3.0 runtime reference originates. Maybe the 3.1.x SDK? (The single-file option doesn't matter -- it's the linux-arm target. If I switch publish to Portable it works, but of course, I get a lot of stuff I don't need.)

C:\Source\pi-cam-test>dotnet publish -p:PublishProfile="raspberrypi network share"
Microsoft (R) Build Engine version 16.7.0+7fb82e5b2 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605: Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.  [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605:  pi-cam-test -> Serilog.Sinks.File 4.1.0 -> System.IO.FileSystem 4.0.1 -> runtime.unix.System.IO.FileSystem 4.3.0 -> System.IO.FileSystem.Primitives (>= 4.3.0)  [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605:  pi-cam-test -> System.IO.FileSystem.Primitives (>= 4.0.1) [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605: Detected package downgrade: System.Runtime.Handles from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.  [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605:  pi-cam-test -> Serilog.Sinks.File 4.1.0 -> System.IO.FileSystem 4.0.1 -> runtime.unix.System.IO.FileSystem 4.3.0 -> System.Runtime.Handles (>= 4.3.0)  [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605:  pi-cam-test -> Serilog.Sinks.File 4.1.0 -> System.IO.FileSystem 4.0.1 -> System.Runtime.Handles (>= 4.0.1) [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605: Detected package downgrade: System.Text.Encoding.Extensions from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.  [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605:  pi-cam-test -> Serilog.Sinks.File 4.1.0 -> System.IO.FileSystem 4.0.1 -> runtime.unix.System.IO.FileSystem 4.3.0 -> System.Text.Encoding.Extensions (>= 4.3.0)  [C:\Source\pi-cam-test\pi-cam-test.sln]
C:\Source\pi-cam-test\pi-cam-test.csproj : error NU1605:  pi-cam-test -> Serilog.Sinks.File 4.1.0 -> System.Text.Encoding.Extensions (>= 4.0.11) [C:\Source\pi-cam-test\pi-cam-test.sln]
  Failed to restore C:\Source\pi-cam-test\pi-cam-test.csproj (in 642 ms).

References in the csproj for that attempt:

<ItemGroup>
  <PackageReference Include="Microsoft.Extensions.Logging" Version="3.1.5" />
  <PackageReference Include="Mono.Posix.NETStandard" Version="1.0.0" />
  <PackageReference Include="Serilog.Extensions.Logging" Version="3.0.1" />
  <PackageReference Include="Serilog.Sinks.File" Version="4.1.0" />
  <PackageReference Include="System.Drawing.Common" Version="4.7.0" />

  <PackageReference Include="System.IO.FileSystem.Primitives" Version="4.0.1" />
  <PackageReference Include="System.Runtime.Handles" Version="4.0.1" />
  <PackageReference Include="System.Text.Encoding.Extensions" Version="4.0.11" />
</ItemGroup>

Is there any update on this?
Looking through Verbose build logs just to see which file is attempting to be copied twice is a huge pain.

Could we atleast get a better error message if this cannot be easily fixed?

Was this page helpful?
0 / 5 - 0 ratings