Is <AspireUseCliBundle>true</AspireUseCliBundle> expected to break dotnet watch

[Will Dean (willdean)]

If I add <AspireUseCliBundle>true</AspireUseCliBundle> to a project, as advised by the latest versions of Aspire, I can no longer use dotnet watch, because it fails with a complaint about a --no-build option (which Aspire has added somewhere)

Before I go to the effort of filing a proper, reproducible bug, is this to be expected?

[Zuhair Halawa (zuhairhalawa)]

With AspireUseCliBundle enabled (it is also the default now for .csproj AppHosts), Aspire.Hosting.AppHost.targets rewrites RunCommand and RunArguments so that dotnet run launches aspire run --project "<AppHost>" --no-build -- instead of the AppHost itself, whenever an Aspire CLI 13.5.0 or newer is found. dotnet watch starts the project through dotnet run --no-build, so it picks up the rewritten command, and that is the likely source of the --no-build you are seeing.

There is an opt-out: setting ASPIRE_SUPPRESS_CLI_RUN_HOOK to 1 or true (as an environment variable, or -p:ASPIRE_SUPPRESS_CLI_RUN_HOOK=true) leaves RunCommand alone, so dotnet run and dotnet watch launch the AppHost directly again. The bundle's DCP and dashboard locations are still stamped into the build output as assembly metadata. The Aspire CLI sets the same switch itself when it starts dotnet watch for its own watch mode.

$env:ASPIRE_SUPPRESS_CLI_RUN_HOOK = "1"
dotnet watch

The thread doesn't include the exact error text, so this is read from the targets file rather than from the message. If the error still mentions --no-build with the switch set, the full output would show where it comes from.

[Zuhair Halawa (zuhairhalawa)]

If the opt-out gets dotnet watch working for you, could you mark the answer as accepted? If it does not, the full error output would help narrow down where --no-build comes from.