Fix tool projects so they don't remove apphosts when publishing (not packing)

[baronfel]

Fixes #49799

The PackTool targets were unconditionally overwriting the UseAppHost and related properties at evaluation-time. This results in publishes of there projects not having AppHosts when they were expected to.

This change pushes the property modifications into a Target that runs early on in the pack process, so that publish is unaffected.

[Copilot]

Pull Request Overview

This PR fixes a bug where tool projects were incorrectly removing apphosts during publish operations. The issue was that PackTool targets were unconditionally overwriting UseAppHost and related properties at evaluation time, causing published tool projects to lack AppHosts when they were expected.

• Moved UseAppHost property modifications from evaluation-time to a target that runs early in the pack process
• Added a test to verify that tool projects can publish with apphosts correctly
• Relocated ToolCommandRunner property group to be set within the SetPackToolProperties target

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
test/Microsoft.NET.Publish.Tests/GivenThatWeWantToPublishAToolProject.cs	Added new test class to verify tool projects can publish with apphosts
src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.PackTool.targets	Moved UseAppHost and ToolCommandRunner property settings from evaluation-time to SetPackToolProperties target

Comments suppressed due to low confidence (2)

test/Microsoft.NET.Publish.Tests/GivenThatWeWantToPublishAToolProject.cs:35

• The test should verify that the publish command executed successfully before checking for the apphost file. Consider adding .Should().Pass() or similar assertion after Execute().

            publishCommand.Execute();

[dsplaisted]

There's a DirectoryInfo assertion which should give better error messages here. Somethnig like outputDirectory.Should().HaveFile($"consoledemo{Constants.ExeSuffix}");

[dsplaisted]

This feels flaky to me. We publish before we pack, does this mean that the contents of a normal Publish would be different from a Publish-for-Pack operation? That seems kind of bad and like it would hurt incrementality.

Could we let the app host be created in Publish regardless, but then filter it out of the files that we pack if need be?

[baronfel]

In this case I actually thing this brings the two outputs into alignment - when publishing an exe you get an apphost by default. When packing a RID-agnostic tool you never want an apphost. Making this explicit on the interior publish seems like a very safe thing to do IMO. It's also pretty ok from an incrementality perspective - the expensive parts of publishing aren't copying an apphost.

Re: your second part - that's an interesting idea. I confess that I find the idea of more explicitly controlling the publish more attractive though - it feels more intentional and less ad-hoc to me. We're publishing for a distinctly different purpose when we pack a tool - it feels right to express that on the parameters to the publish operation.

[dsplaisted]

We have some problems with Publish because in some cases the Build needs to be different depending on whether Publish is going to run. This seems like the same thing, only this time the behavior of Publish needs to be different depending on whether we're going to run Pack or not. That's why this feels off to me and why it seems like it would be better to change the behavior of Pack here than that of Publish.

[baronfel]

I don't follow - by definition I am changing the behavior of Pack - Pack wants the published output of the app, but within specific parameters for framework-dependent, rid--agnostic tools. The 'publish' in this case is an implementation detail of packaging the tool.