sdk: System.Exception: Publish has encountered an error

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?

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.

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

I encountered a similar problem in these days. I think it’s related to the newest update of visual studio or Azure Data Lake Tools. When I published the function app to Azure, VS popped up this error: However, there is nothing useful in the log file. This bothers me too much.

3/22/2021 9:11:02 PM
System.AggregateException: One or more errors occurred. ---> Microsoft.WebTools.Shared.Exceptions.WebToolsException: 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 ---
---> (Inner Exception #0) Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---

Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. 

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

I have to use another workaround: https://docs.microsoft.com/en-us/azure/azure-functions/deployment-zip-push

https://github.com/dotnet/runtime/pull/48336 adds a better error message which will contain the conflicting file paths. It will take a couple of day to flow to dotnet/installer, but once there it should be possible to take a nightly build of .NET 6 SDK and build the app with it to get the info from it.

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):

@vitek-karas I’ve been having the same problem for a few days and my project is .NET 6.0.

Findings:

Using the 5.0 linker (as in the repro) we produce basically broken output. The System.Security.Principal.WindowsIdentity in System.Security.Principal.Windows.dll derives from System.Security.Claims.ClaimsIdentity from System.Security.Claims.dll but when the app is trimmed this type reference suddenly points to System.Security.Claims.ClaimsIdentity from System.Runtime.InteropServices.dll - and such type doesn’t exist.

I vaguely remember linker messing up type refs in copyused mode. For example this issue https://github.com/mono/linker/issues/2138 - but I think there were others.

The failure is because crossgen fails on such IL as it can’t find the referenced type.

I tried using 6.0 linker on this and it’s better. The produced IL now has the correct type ref in it ( System.Security.Claims.ClaimsIdentity from System.Security.Claims.dll ) but it’s still a problem because the entire System.Security.Claims.dll is removed. This is because all these assemblies are in “copyused” mode, so in this case the trimmer doesn’t find any usage of the System.Security.Principal.WindowsIdentity type, and thus it doesn’t mark the base type, but something else from the System.Security.Principal.Windows assembly is kept and thus the entire assembly is kept. But the System.Security.Claims.ClaimsIdentity.dll is removed (as nothing from it was marked).

If used at runtime this would not matter, since the WindowsIdentity type should never get loaded (not used) and thus the fact that is a type ref to a missing type doesn’t matter. But crossgen doesn’t know this, it treats all types as potentially used and thus tries to load the WindowsIdentity and this fails, since the base type reference can’t be resolved.

Retargeting to .NET 6 fixes the failure, but it’s hard to tell if it will end up working as a whole. The trimmer in 6 reports quite a few warnings even with just a reference to the Microsoft.Extensions.Hosting , so it’s possible the app will not work. The reason why it doesn’t fail during publish is that in 6 the trim mode is “link” and so we remove the entire WindowsIdentity type and the problem goes away.

Maybe if there’s a way in crossgen to “ignore” unresolved references, it might fix this problem in 5.

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>

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.