`mergenupkg` breaks build pipeline in .NET 9; ci still using .NET 6

[cagyirey]

Problem overview

I noticed Myriad's main branch had been ~mostly upgraded to .NET 9 but the package wasn't available on NuGet. There are two issues:

• The publish action is configured to install .NET 6 (and Windows — you probably don't want that). We should change this line to 9.x

• We can't publish the package anyway, because the mergenupkg build step is broken in .NET 9:

Myriad cadence$ dotnet tool restore
Failed to validate package signing.

Verifying dotnet-mergenupkg.3.0.0

Signature type: Repository
  Subject Name: CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US
  SHA256 hash: 0E5F38F57DC1BCC806D8494F4F90FBCEDD988B46760709CBEEC6F4219AA6157D
  Valid from: 4/9/2018 9:00:00 PM to 4/14/2021 9:00:00 AM

warn : NU3018: The repository primary signature found a chain building issue: RevocationStatusUnknown: An incomplete certificate revocation check occurred.
error: NU3037: The repository primary signature validity period has expired.
error: NU3028: The repository primary signature's timestamp found a chain building issue: ExplicitDistrust: The trust setting for this policy was set to Deny.

Package signature validation failed.

Instructions for reproduction

• Install .NET 9 SDK
• Run dotnet tool restore from repository root.

Proposed solution

• Publish myriad as a .NET tool and Myriad.Sdk as a separate package
• OR develop some solution to allow MSBuild to locate build scripts inside our dotnet tool install directory.

I'm leaning toward the first for simplicity sake. I tried to figure out how to make the second solution work, but it seems like more trouble than its worth. Let me know which approach you prefer and I'll submit a PR.

[7sharp9]

Having two packages makes using it more difficult to use though though right?

I think, (I forget now because so much time has passed) that @enricosada used mergenupkg due to a limitation in dotnet tools at that point in time. I just cant remember now. When we were both working at Jet the basis for the package architecture came from Falanx which has the same build steps and cache checking. I mean, you dont need to know all this, I'm just thinking out loud :-)

[7sharp9]

I wonder if the issue was that the myriad.sdk could not have the tool as a dependency?

[cagyirey]

I think the logic must've been something like the following:

1. A lot of the important logic is in the Myriad.Sdk MSBuild scripts.
2. If you were to dotnet tool install myriad, MSBuild wouldn't import the scripts because it only looks for build scripts in referenced packages, not tools.
3. If you bundle the tool with the build scripts as Myriad.Sdk, the MSBuild scripts are detected as intended and we handle the installation of the tool at the same time.

There's also something in the code about mergenupkg being a workaround for Paket trying to run fixnupkg on Myriad.Sdk and failing (because there's no actual code?). Maybe we can just combine the tool and the MSBuild stuff into one project and keep distributing it as a package?

Personally, I wouldn't care all that much if I had to dotnet tool install myriad when building Myriad plugins but that's just me.

[7sharp9]

To be honest I think I've forgot most of the issues over time. I wonder if the Myriad.Sdk could prompt to do an install if it detects the absence of the tool?

[7sharp9]

Also, if there was some warning and I got round to updating a template that would even things out.

[7sharp9]

Anecdotally it should be ok to split, its just getting round to looking at it an analysing to ensure theres a good experience and updating the docs. And fixing the docs, whew!