[Core] GenerateBundle task for single file publishing fails with v5.0.1

[NicoVIII]

I'm using the code generator lib Myriad in my project, which adds a dependency for FSharp.Compiler.Service. This dependency suddenly breaks single file publishing when I'm using v39. With v38 everything works fine.
It looks like the problem is the dependency on FSharp.Core 5.0.1 (#11111 (comment)).

Repro steps

Edit: I created a minimal repro: #11111 (comment)

I got the problem in one of my repos.
As you can see in the commit history and look at the CI results:
the deployment works, if I pin the Service to v38 and does not work, if I use v39 (which depends on FSharp.Core 5.0.1).

1. commit (works): NicoVIII/MagicCollectionHelper@46f09c4
2. commit (broken): NicoVIII/MagicCollectionHelper@b0e874c

With v5.0.1 if I execute following commands in src/MagicCollectionHelper/AvaloniaApp:

dotnet publish -c Release -r linux-x64 -o "../../../deploy"

This works.

dotnet publish -c Release -r linux-x64 -o "../../../deploy" -p:PublishSingleFile=true

This produces the following error:

error MSB4018: The "GenerateBundle" task failed unexpectedly. [/workspaces/MagicCollectionHelper/src/MagicCollectionHelper/AvaloniaApp/MagicCollectionHelper.AvaloniaApp.fsproj]
error MSB4018: System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath [/workspaces/MagicCollectionHelper/src/MagicCollectionHelper/AvaloniaApp/MagicCollectionHelper.AvaloniaApp.fsproj]
error MSB4018:    at Microsoft.NET.HostModel.Bundle.Bundler.GenerateBundle(IReadOnlyList`1 fileSpecs) [/workspaces/MagicCollectionHelper/src/MagicCollectionHelper/AvaloniaApp/MagicCollectionHelper.AvaloniaApp.fsproj]
error MSB4018:    at Microsoft.NET.Build.Tasks.GenerateBundle.ExecuteCore() [/workspaces/MagicCollectionHelper/src/MagicCollectionHelper/AvaloniaApp/MagicCollectionHelper.AvaloniaApp.fsproj]
error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [/workspaces/MagicCollectionHelper/src/MagicCollectionHelper/AvaloniaApp/MagicCollectionHelper.AvaloniaApp.fsproj]
error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/workspaces/MagicCollectionHelper/src/MagicCollectionHelper/AvaloniaApp/MagicCollectionHelper.AvaloniaApp.fsproj]
error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/workspaces/MagicCollectionHelper/src/MagicCollectionHelper/AvaloniaApp/MagicCollectionHelper.AvaloniaApp.fsproj]

Expected behavior

Publishing as single file works also with the current version of FSharp.Core.

Actual behavior

See Repro steps. Publishing as single file throws an error.

Known workarounds

Use v5.0.0.

Related information

Provide any related information (optional):

• OS: Manjaro (Development happens inside of a devcontainer)
• .NET 5.102
• Visual Studio Code

[njlr]

I had this issue but due to FSharp.Core version 5.0.1.

This line in paket.dependencies is a work-around:

nuget FSharp.Core 5.0.0

[NicoVIII]

Alright, thanks for the hint!
The compiler service v39 seems to depend on FSharp.Core 5.0.1, that's why it breaks for me.
I will try to reproduce that without the CompilerService but I updated the issue to reference FSharp.Core.

[cartermp]

I can't reproduce this on the latest macOS with a console app + updated FSharp.Core to 5.0.1 and FCS 39 on the .NET SDK 5.0.103, regardless of paket or nuget.

@njlr did you see this also on linux?

[njlr]

I can't reproduce this on the latest macOS with a console app + updated FSharp.Core to 5.0.1 and FCS 39 on the .NET SDK 5.0.103, regardless of paket or nuget.

@njlr did you see this also on linux?

We saw this on Linux and macOS. Our solution has multiple projects with interdependencies too.

Some of the settings:

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.1</TargetFramework>
        <PublishSingleFile>true</PublishSingleFile>
        <SelfContained>true</SelfContained>
        <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
        <PublishTrimmed>true</PublishTrimmed>
        <PublishReadyToRun>false</PublishReadyToRun>
        <Deterministic>true</Deterministic>
        <DeterministicSourcePaths>true</DeterministicSourcePaths>
    </PropertyGroup>

[NicoVIII]

I created a repro repo.
It seems to fail, if I have a project without OutputType (should be library) and reference that from a project with OutputType Exe.
Without this reference everything worked for me as well.
https://github.com/NicoVIII/ReproRepo-Singlefile-FSharp.Core-v5.0.1

This works with FSharp.Core 5.0.0, but not with FSharp.Core 5.0.1.

[cartermp]

Labeling as a regression and adding to the 16.10 milestone for now. Thanks @NicoVIII for the repro.

[daz10000]

Ha, was up till 1am this morning with this problem and I tracked it down (and also built a very minimal repro attached). This is a delightful collision of things. The single file publishing has an absolute prohibition against two files getting published to the same output file path but isn't smart enough to deconflict cases where the files are identical. There seem to be some cases where the build machinery adds two copies of FSharp.Core to a project. It doesn't affect regular builds because one probably just gets pasted over the other and they are identical. With 5.0.1 there was an xml file added to the package

diff -u3 5.0.0/fsharp.core.nuspec 5.0.1/fsharp.core.nuspec

+    <contentFiles>
+      <files include="**/FSharp.Core.xml" buildAction="None" copyToOutput="true" flatten="true" />
+    </contentFiles>

That file gets copied twice in some cases and the bundler gets upset. If you run net6 prerelease it even emits a helpful message here (of course this highlights another opportunity to make the bundler a little less mindless - if the paths are the same it shouldn't care, even if they are different it should probably do a binary check but anyway if this list is multiple, it fails)

System.ArgumentException: Invalid input specification: Found entries 
'C:\xxxxx\.nuget\packages\fsharp.core\5.0.1\contentFiles\any\netstandard2.0\FSharp.Core.xml', 
'C:\xxxxx\.nuget\packages\fsharp.core\5.0.1\contentFiles\any\netstandard2.0\FSharp.Core.xml' with the same BundleRelativePath 'FSharp.Core.xml

Fix is to get rid of the xml file from the package for now (or pin to 5.0.0). My repro attached - it's a two project case where one project brings in the second (empty) project. Oddly this trips things only with paket adding the packages. If I simply add the library to two projects directly, something is smart enough to remove the dups but not with the more complex paket build.

Playground.zip

[daz10000]

The nice runtime bundlefolks seem (justifiably) unenthusiastic about patching the bundling to work around what is probably in the end an SDK issue. I don't understand why the project setup I attached above results in the FSharp.Core xml file getting added twice but that's probably the root issue really. Removing the xml file will stop the pain but it's not really at fault.

[cartermp]

Thanks for the repro. @KevinRansom any thoughts here? It's related to the recent FSharp.Core changes.

[dsyme]

My understanding is that this is a duplicate of #11143 and was fixed by #11160