FSharp compiler packages differ in signatures between dotnet/sdk and dotnet/fsharp published assets

[mmitche]

FSharp produces the FSharp.Compiler.Service package both as a primary repo asset that gets published by arcade to feeds. It also puts it into the Microsoft.FSharp.Compiler package, which is ingested by dontet/sdk, unpacked, and published along with SDK's assets during repo build publishing.

The package is being signed twice, leading to hash differences in the copy in Microsoft.FSharp.Compiler vs. the primary repo asset.

I think this has been this way for a while, but we only noticed when fsharp started pushing to the dotnet8 feeds via the ".NET 8" channel. The fsharp repo build publishes to dotnet8, but then sdk does too. Previously, fsharp was only using the VS channels, which go to dotnet-tools. Since the hashes differ, publishing fails: https://dev.azure.com/dnceng/internal/_build/results?buildId=2187714&view=logs&j=ba23343f-f710-5af9-782d-5bd26b102304&t=c7a8693b-2f9c-5ea8-c909-cde9405ac2e1&l=399

To work around this in the short term, I have switched the net8 branch to push to ".NET Core Tooling Dev", which pushes to dotnet-tools.

Potential root cause?

FSharp builds two solutions in succession to produce the required outputs. FSharp.sln/VisualFSharp.sln, then Microsoft.FSharp.Compiler.sln. Both passes sign files. My hunch is that the second build, which produces the Microsoft.FSharp.Compiler package, is packing up either a signed or unsigned version of FSharp.Compiler.Service (probably unsigned?), then passing all files produced (including the other copy of FSharp.Compiler.Service) to the signing service. The two nupkgs have different hashes, so they don't dedupe and are both signed.

[lewing]

This appears to have caused the sdk to downgrate to net7 versions which aren't in the net8 feeds at all dotnet/sdk#32870