Handle Linux osx-arm64 dotnet tool publish without app host

[Copilot]

dotnet publish for osx-arm64 was failing on Linux with NETSDK1084 (missing app host), which then broke artifact validation for bin/Release/publish/osx-arm64.
This change scopes a Linux-only fallback for osx-arm64 tool publish so publish succeeds and artifact expectations stay aligned.

• Composer: Linux osx-arm64 fallback recipe

  • In DotNetComposer, for PackAsTool + target osx-arm64 on Linux:
    • switch to framework-dependent publish (SelfContained=false)
    • disable app host (UseAppHost=false)
    • disable single-file for that case
    • expect .dll artifact name (NetCore.Console.dll) instead of host binary

• Dotnet command generation: explicit non-self-contained for fallback

  • In DotNet.PublishAsync, when UseAppHost=false is present and recipe is not self-contained, emit --self-contained false to avoid SDK inference conflicts.

• Tests: artifact and recipe expectations updated

  • NetCoreConsoleTests: Linux assertion for osx-arm64 now expects NetCore.Console.dll.
  • DotNetComposerServiceTests: added focused coverage asserting Linux osx-arm64 publish recipe uses SelfContained=false, PublishSingleFile=false, UseAppHost=false, and .dll artifact naming.

var useFrameworkDependentPublish = OperatingSystem.IsLinux() &&
                                   targetPlatform.Os == ExecutableOperatingSystem.MacOSX &&
                                   targetPlatform.Arch == ExecutableArchitecture.Arm64;

var publishProperties = useFrameworkDependentPublish
    ? new Dictionary<string, string>(properties) { ["UseAppHost"] = "false" }
    : properties;

Original prompt

Fix the failing job for PR #601 in repository rasmus/Bake on branch add-osx-arm64-default-platform.

Observed failure from GitHub Actions job 76897370692 in run 26144691916:

• .NET SDK 10.0.300 fails during dotnet-publish with error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'osx-arm64'.
• The job log shows artifact validation then fails because .../bin/Release/publish/osx-arm64 does not exist.
• Failing tests include PlanThenApply(Warning), PlanThenApply(Error), PlanThenApply(Fatal), and Run.

Please inspect the workflow, the failing tests, and the implementation that builds the dotnet-publish command/configuration. Make the minimal correct change on branch add-osx-arm64-default-platform so the tests pass.

Likely fix direction:

• For osx-arm64 publish scenarios that run on Linux CI, disable app host generation (equivalent to adding -p:UseAppHost=false) when publishing for that RID, unless the code path is specifically intended to require an app host.
• If tests assert generated command text or expected artifacts, update them accordingly.
• Keep the fix narrowly scoped to the failing behavior.

Create a pull request with the code changes if supported by the workflow of this tool, using a concise PR title and include a clear explanation of the fix.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The failure is caused by the test fixture trying to publish for osx-arm64 on a Linux runner with a .NET SDK that does not provide an app host for that RID.

Root cause

From the failing job logs at commit f021bdba15c845115e3b29b0b12682dabce25bf7:

• .NET SDK 10.0.300 fails with:
  • error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'osx-arm64'.
• That causes artifact validation to fail because Bake expects:
  • .../bin/Release/publish/osx-arm64
    but that directory is never created.
• The failures show up in tests named:
  • PlanThenApply(Warning)
  • PlanThenApply(Error)
  • PlanThenApply(Fatal)
  • Run

The workflow itself is simple and delegates to the shared pipeline definition:

• .github/workflows/pull-requests.yml at f021bdba15c845115e3b29b0b12682dabce25bf7

Solution

Update the test inputs or publish recipe expectations so osx-arm64 is not published with an app host from this Linux environment.

The safest fix is to make the publish step for osx-arm64 framework-dependent and disable app host generation.

Code change to apply

Wherever the failing integration tests define the dotnet-publish step for osx-arm64, add:

-p:UseAppHost=false

or the equivalent Bake argument/property.

If the publish command currently looks like:

dotnet publish -c Release -r osx-arm64

change it to:

dotnet publish -c Release -r osx-arm64 -p:UseAppHost=false

If it is emitted through Bake recipe configuration, the equivalent should be something like:

new DotNetPublishSettings
{
    Configuration = "Release",
    Runtime = "osx-arm64",
    Properties =
    {
        ["UseAppHost"] = "false"
    }
}

If these tests validate produced artifact directories

Keep the expected output directory, but only if the publish is intended to succeed without an app host. If the scenario specifically requires a native executable/app host, then osx-arm64 should be removed from Linux-based test coverage instead.

That alternative fix would be:

var runtimes = new[]
{
    "linux-x64",
    "win-x64"
    // remove "osx-arm64" from this test matrix on Linux
};

Recommended fix

Prefer this logic:

• For cross-RID publish validation in tests: use UseAppHost=false for osx-arm64
• For app-host-specific validation: only run osx-arm64 on macOS runners

Why this is the right fix

The logs show linux-x64 publish succeeds, while osx-arm64 alone fails. That indicates the failure is not general publish logic, but specifically app host resolution for that RID on the current SDK/runner combination.

Suggested patch shape

If your test/build code constructs per-RID publish settings, apply conditional logic like:

DotNetPublishSettings CreatePublishSettings(string runtime) =>
    new()
    {
        Configuration = "Release",
        Runtime = runtime,
        Properties = runtime == "osx-arm64"
            ? new Dictionary<string, string> { ["UseAppHost"] = "false" }
            : new Dictionary<string, string>()
    };

If the test snapshots or expected command text assert the exact command line, update them to include:

-p:UseAppHost=false

for osx-arm64.

Summary

Fix the failing job by changing the `osx-arm...

This pull request was created from Copilot chat.