Update Aspire.AppHost.Sdk to support simpler file-based app AppHosts #11445

DamianEdwards · 2025-09-16T23:48:35Z

Description

Updates the Aspire.AppHost.Sdk to auto-import the Microsoft.NET.Sdk if it detects it isn't already referenced. It also updates the Aspire.AppHost.Sdk to auto include a package reference to Aspire.Hosting.AppHost with the same version as the SDK if it isn't already referenced.

The Aspire.AppHost.Sdk was also updated to ensure the various markers for native AOT and trimming are forcibly disabled so that file-based AppHosts (and others) default to PublishAot=false. This can be simplified once dotnet/sdk#50885 is merged.

The enables an AppHost project or file-based app to just reference the Aspire.AppHost.Sdk SDK. The single-file AppHost template has been updated in this PR to reflect this:

#:sdk Aspire.AppHost.Sdk@9.5.0

var builder = DistributedApplication.CreateBuilder(args);

builder.Build().Run();

The changes are gated to only apply to file-based app AppHosts for now.

Checklist

Is this feature complete?
- Yes. Ready to ship.
Are you including unit tests for the changes and scenario tests if relevant?
- No (existing template tests verify this doesn't break existing scenarios)
Did you add public API?
- No
Does the change make any security assumptions or guarantees?
- No
Does the change require an update in our Aspire docs?
- No (file-based app host is experimental for now)

github-actions · 2025-09-16T23:48:45Z

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 11445

Or

Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 11445"

…imported

Copilot

Pull Request Overview

This PR implements automatic importing of the base .NET SDK from the Aspire.AppHost.Sdk when it's not already imported, enabling single-file app host templates to only reference the Aspire SDK while automatically getting .NET SDK functionality.

Adds conditional import logic to automatically include Microsoft.NET.Sdk when not present
Moves property defaults (PublishAot=false, etc.) from template to SDK for centralized management
Adds implicit PackageReference for Aspire.Hosting.AppHost when not already referenced

Reviewed Changes

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

File	Description
apphost.cs	Removes explicit Microsoft.NET.Sdk, package reference, and property declarations from single-file template
Sdk.in.props	Adds conditional Microsoft.NET.Sdk import logic and default property values
Sdk.in.targets	Adds Microsoft.NET.Sdk targets import and new targets for AOT defaults and implicit package references

Copilot · 2025-09-17T19:27:34Z

src/Aspire.AppHost.Sdk/SDK/Sdk.in.targets

    <AspireRidToolExecutable>$(AspireRidToolDirectory)Aspire.RuntimeIdentifier.Tool.dll</AspireRidToolExecutable>
  </PropertyGroup>

+  <Target Name="DisablePublishAotForAspireHost" BeforeTargets="_ComputeToolPackInputsToProcessFrameworkReferences;_CollectTargetFrameworkForTelemetry;ProcessFrameworkReferences;Restore;CollectPackageReferences" Condition="'$(IsAspireHost)' == 'true' and '$(DisableAspirePublishAotDefaults)' != 'true'">


[nitpick] The target name 'DisablePublishAotForAspireHost' doesn't accurately reflect what the target does - it sets multiple AOT and trimming properties, not just PublishAot. Consider renaming to 'SetAspireHostAotDefaults' or 'ConfigureAspireHostPublishSettings' for better clarity.

Suggested change

<Target Name="DisablePublishAotForAspireHost" BeforeTargets="_ComputeToolPackInputsToProcessFrameworkReferences;_CollectTargetFrameworkForTelemetry;ProcessFrameworkReferences;Restore;CollectPackageReferences" Condition="'$(IsAspireHost)' == 'true' and '$(DisableAspirePublishAotDefaults)' != 'true'">

<Target Name="SetAspireHostAotDefaults" BeforeTargets="_ComputeToolPackInputsToProcessFrameworkReferences;_CollectTargetFrameworkForTelemetry;ProcessFrameworkReferences;Restore;CollectPackageReferences" Condition="'$(IsAspireHost)' == 'true' and '$(DisableAspirePublishAotDefaults)' != 'true'">

Copilot · 2025-09-17T19:27:35Z

src/Aspire.AppHost.Sdk/SDK/Sdk.in.props

+    <PublishAot>false</PublishAot>
+    <PublishTrimmed>false</PublishTrimmed>
+    <EnableAotAnalyzer>false</EnableAotAnalyzer>
+    <EnableTrimAnalyzer>false</EnableTrimAnalyzer>
+    <EnableSingleFileAnalyzer>false</EnableSingleFileAnalyzer>


These property defaults are duplicated in both Sdk.in.props (lines 7-11) and in the DisablePublishAotForAspireHost target in Sdk.in.targets (lines 56-60). This duplication could lead to inconsistencies. Consider consolidating these settings in one location, preferably in the target where they can be conditionally applied.

Suggested change

<PublishAot>false</PublishAot>

<PublishTrimmed>false</PublishTrimmed>

<EnableAotAnalyzer>false</EnableAotAnalyzer>

<EnableTrimAnalyzer>false</EnableTrimAnalyzer>

<EnableSingleFileAnalyzer>false</EnableSingleFileAnalyzer>

Yep, doing it in both places until dotnet/sdk#50885 is merged and flows through to rc.2 builds.

baronfel · 2025-09-17T20:31:59Z

src/Aspire.AppHost.Sdk/SDK/Sdk.in.props

    <IsAspireHost>true</IsAspireHost>
+    <PublishAot>false</PublishAot>
+    <PublishTrimmed>false</PublishTrimmed>
+    <EnableAotAnalyzer>false</EnableAotAnalyzer>


Instead of setting all of these it may be easier to set IsAotCompatible and IsTrimmable to false - these are an implicit condition of all 3 of the analyzers, and they also tie into disabling the ProjectCapability Items you remove later on:

https://github.com/dotnet/sdk/blob/b64c645566412038bd42f080f27525f07d88ba8b/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L23-L24

https://github.com/dotnet/sdk/blob/f9cf0b926534cdb941c876cbf021288198e673c9/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.Analyzers.targets#L76-L96

https://github.com/dotnet/sdk/blob/b64c645566412038bd42f080f27525f07d88ba8b/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L35-L42

Let me try.

Actually, I think still need to set these explicitly don't I because they'll be set an evaluation due to the file-based apps virtual project setting PublishAot to true?

Also AppHost projects aren't publishable so the publish targets shouldn't matter in this case.

mm not sure I love setting these in the SDK, where other projects that are not file-based apps would be impacted. Is there a way to fix this via the virtual project somehow? For instance, if it sees that the aspire sdk is set then set these to false inside the virtual project?

Yeah I'm not a fan of hard-coding stuff like that in file-based apps directly, that's backwards :)
SDKs should be able to impart changes on projects that reference them, that's not an issue. This specific implementation of doing it in the targets is a temp workaround for file-based apps which we can remove once that's fixed. Then we'll just be setting the default values of these in our Sdk.in.props file.

Is there a property that we can chain of only defined in virtual projects so we can add a condition to these? If not, I think at the very least we should add conditions to all of these to check if they were not already defined (meaning only set them if they are not set already)

I think at the very least we should add conditions to all of these to check if they were not already defined (meaning only set them if they are not set already)

This specifically won't work because of where they have to run, that's the issue.

We can condition this so that it only applies to file-based apps (there's a property) if we really want to isolate it, but I'm not convinced it matters. What's the concern?

put the other way - are there actual valid use cases for an Aspire AppHost to be trimmed/AOT? If not, why even allow it?

There are not, it's dev time only and we block publishing.

baronfel · 2025-09-17T20:33:20Z

src/Aspire.AppHost.Sdk/SDK/Sdk.in.targets

    <AspireRidToolExecutable>$(AspireRidToolDirectory)Aspire.RuntimeIdentifier.Tool.dll</AspireRidToolExecutable>
  </PropertyGroup>

+  <Target Name="DisablePublishAotForAspireHost" BeforeTargets="_ComputeToolPackInputsToProcessFrameworkReferences;_CollectTargetFrameworkForTelemetry;ProcessFrameworkReferences;Restore;CollectPackageReferences" Condition="'$(IsAspireHost)' == 'true' and '$(DisableAspirePublishAotDefaults)' != 'true'">


There's a part of me that wants to try and trim this dependency list - e.g. Restore is implied by CollectPackageReferences, so it could be safe to drop Restore directly.

The intent is for this to go away completely once dotnet/sdk#50885 is in anyway.

joperezr · 2025-09-17T22:43:43Z

src/Aspire.AppHost.Sdk/SDK/Sdk.in.targets

  </PropertyGroup>

+  <Target Name="DisablePublishAotForAspireHost" BeforeTargets="_ComputeToolPackInputsToProcessFrameworkReferences;_CollectTargetFrameworkForTelemetry;ProcessFrameworkReferences;Restore;CollectPackageReferences" Condition="'$(IsAspireHost)' == 'true' and '$(DisableAspirePublishAotDefaults)' != 'true'">
+    <PropertyGroup>


Why do you need this target if these are defined in Sdk.props already statically?

Because file-based apps resets the PublishAot property (and thus everything that is evaluated off of its value) directly in the virtual project today, so setting it in our props gets overwritten. Doing it in this target is required to ensure it overrides what is set in the project. This whole target will be removed once dotnet run is fixed to only set the implicit project-level stuff if a value isn't already explicitly set (dotnet/sdk#50885).

joperezr · 2025-09-17T22:46:11Z

src/Aspire.AppHost.Sdk/SDK/Sdk.in.targets

+    <ItemGroup>
+      <!-- Add the reference to the Aspire.Hosting.AppHost package if not already referenced -->
+      <PackageReference Include="Aspire.Hosting.AppHost" Version="$(_ImplicitAppHostVersion)"  IsImplicitlyDefined="true"
+                        Condition="'@(PackageReference->WithMetadataValue('Identity','Aspire.Hosting.AppHost'))' == '' And '@(PackageVersion->WithMetadataValue('Identity','Aspire.Hosting.AppHost'))' == ''" />


NIT: why do you need to check PackageVersion too? Even if using CPM, wouldn't we want to do this even if there was a PackageVersion for it?

I think that's copilot being helpful 😄
I think it's safe to remove the check for PackageVersion like you say.

Although the challenge there is, if using CPM, we don't want to implicitly add the package with a version right? Because that version should now be controlled by CPM, not the PackageReference we add. Or does the IsImplicitlyDefined="true" effectively turn off CPM for that PackageReference?

Yes, when you mark the package as implicitly defined then you can pass a version.

joperezr · 2025-09-17T22:49:07Z

src/Aspire.AppHost.Sdk/SDK/Sdk.in.targets

+    </PropertyGroup>
+    <ItemGroup>
+      <!-- Add the reference to the Aspire.Hosting.AppHost package if not already referenced -->
+      <PackageReference Include="Aspire.Hosting.AppHost" Version="$(_ImplicitAppHostVersion)"  IsImplicitlyDefined="true"


One thing I don't like about this change, is that it may cause people to remove the PackageReference from their project, and therefore never finding out if there is a newer version of Aspire given Msbuild SDKs don't have update notifications. If possible, I'd also condition this to only happen for file-based apps.

We don't have to advertise it for now and the templates aren't being changed. Plus we have aspire update (assuming that still works 😄). If we're really super concerned about this, we can limit this to file-based AppHosts only.

mitchdenny · 2025-09-17T23:02:39Z

We need to make sure that aspire update is going to work after this change.

DamianEdwards · 2025-09-17T23:20:40Z

@mitchdenny

We need to make sure that aspire update is going to work after this change.

We don't need to advertise this being doable for non-file-based AppHosts for now. Indeed this doesn't change the current templates to remove the package reference. But if it's simply ensuring that aspire update works when there isn't a PackageReference then that'd be good! I think it will likely need updating to support the following syntax:

<Project Sdk="Aspire.AppHost.Sdk/9.5.0-pr.11445.979496fd">

mitchdenny · 2025-09-18T00:04:13Z

@mitchdenny

We need to make sure that aspire update is going to work after this change.

We don't need to advertise this being doable for non-file-based AppHosts for now. Indeed this doesn't change the current templates to remove the package reference. But if it's simply ensuring that aspire update works when there isn't a PackageReference then that'd be good! I think it will likely need updating to support the following syntax:
<Project Sdk="Aspire.AppHost.Sdk/9.5.0-pr.11445.979496fd">

That being the case I'm more supportive of this change. When we get to Aspire vNext we'll just need to make sure we update aspire update to be able to handle the possible different AppHost.csproj shapes that might come up since in some cases we do direct XML parsing/patching.

…file-based apps only

DamianEdwards · 2025-09-18T00:38:14Z

@joperezr @baronfel @mitchdenny I've updated this so that it only applies to file-based apps to limit the blast radius. We can expand this to regular AppHosts when we're ready.

baronfel

💪

mitchdenny · 2025-09-18T02:23:20Z

I just cross tested this with #11451 just to make sure that it continued to work with the incoming single file support for aspire add and it works fine.

DamianEdwards · 2025-09-18T04:19:47Z

/backport to release/9.5

github-actions · 2025-09-18T04:19:59Z

Started backporting to release/9.5: https://github.com/dotnet/aspire/actions/runs/17817878589

github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Sep 16, 2025

DamianEdwards mentioned this pull request Sep 17, 2025

Implement Aspire Single-File AppHost template with CLI feature flag integration #11393

Merged

DamianEdwards added 8 commits September 17, 2025 09:47

Auto-import base .NET SDK from the Aspire.AppHost.Sdk if not already …

153e3a3

…imported

Default to disable publishaot

65f8586

Auto-add the AppHost package if not referenced

8c4ba11

Update Sdk.in.targets

c584212

Fix typo

2d2d0cb

Update Sdk.in.props

c97e648

Move defaulting PublishAot to SDK targets

9dfa9e9

rebase on single-file stuff & simplify template

112e4e9

DamianEdwards force-pushed the damianedwards/sdk-auto-import branch from bda9216 to 112e4e9 Compare September 17, 2025 16:55

DamianEdwards added 5 commits September 17, 2025 10:20

Set PublishAot earlier to ensure it's REALLY set

1c48da7

MOAR!

d4dde9f

Fix typo

96e0065

Once more with feeling

7e3c467

There's still hope

979496f

DamianEdwards marked this pull request as ready for review September 17, 2025 19:26

Copilot AI review requested due to automatic review settings September 17, 2025 19:26

DamianEdwards changed the title ~~WIP - Auto-import base .NET SDK from the Aspire.AppHost.Sdk if not already imported~~ Auto-import base .NET SDK from the Aspire.AppHost.Sdk if not already imported Sep 17, 2025

Copilot AI reviewed Sep 17, 2025

View reviewed changes

DamianEdwards requested review from joperezr and radical September 17, 2025 19:42

DamianEdwards assigned baronfel and unassigned baronfel Sep 17, 2025

DamianEdwards requested review from baronfel and mitchdenny September 17, 2025 19:43

DamianEdwards changed the title ~~Auto-import base .NET SDK from the Aspire.AppHost.Sdk if not already imported~~ Update Aspire.AppHost.Sdk to support simpler AppHosts (files & projects) Sep 17, 2025

maddymontaquila approved these changes Sep 17, 2025

View reviewed changes

baronfel reviewed Sep 17, 2025

View reviewed changes

baronfel approved these changes Sep 17, 2025

View reviewed changes

joperezr reviewed Sep 17, 2025

View reviewed changes

Restrict implicit SDK, package reference, & AOT/trimming defaults to …

46b90c5

…file-based apps only

DamianEdwards requested a review from baronfel September 18, 2025 00:55

DamianEdwards changed the title ~~Update Aspire.AppHost.Sdk to support simpler AppHosts (files & projects)~~ Update Aspire.AppHost.Sdk to support simpler file-based app AppHosts Sep 18, 2025

baronfel approved these changes Sep 18, 2025

View reviewed changes

mitchdenny approved these changes Sep 18, 2025

View reviewed changes

github-actions bot mentioned this pull request Sep 18, 2025

[release/9.5] Update Aspire.AppHost.Sdk to support simpler file-based app AppHosts #11472

Merged

DamianEdwards merged commit d676496 into main Sep 18, 2025
311 checks passed

DamianEdwards deleted the damianedwards/sdk-auto-import branch September 18, 2025 04:31

dotnet-policy-service bot added this to the 9.5 milestone Sep 18, 2025

baronfel mentioned this pull request Sep 22, 2025

Allow SDKs to overwrite default file-based app properties dotnet/sdk#50885

Merged

	<Target Name="DisablePublishAotForAspireHost" BeforeTargets="_ComputeToolPackInputsToProcessFrameworkReferences;_CollectTargetFrameworkForTelemetry;ProcessFrameworkReferences;Restore;CollectPackageReferences" Condition="'$(IsAspireHost)' == 'true' and '$(DisableAspirePublishAotDefaults)' != 'true'">
	<Target Name="SetAspireHostAotDefaults" BeforeTargets="_ComputeToolPackInputsToProcessFrameworkReferences;_CollectTargetFrameworkForTelemetry;ProcessFrameworkReferences;Restore;CollectPackageReferences" Condition="'$(IsAspireHost)' == 'true' and '$(DisableAspirePublishAotDefaults)' != 'true'">

Update Aspire.AppHost.Sdk to support simpler file-based app AppHosts #11445

Update Aspire.AppHost.Sdk to support simpler file-based app AppHosts #11445

Uh oh!

Conversation

DamianEdwards commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

github-actions bot commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Sep 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 17, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mitchdenny commented Sep 17, 2025

Uh oh!

DamianEdwards commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mitchdenny commented Sep 18, 2025

Uh oh!

DamianEdwards commented Sep 18, 2025

Uh oh!

baronfel left a comment

Choose a reason for hiding this comment

Uh oh!

mitchdenny commented Sep 18, 2025

Uh oh!

DamianEdwards commented Sep 18, 2025

DamianEdwards commented Sep 16, 2025 •

edited

Loading

github-actions bot commented Sep 16, 2025 •

edited

Loading

DamianEdwards commented Sep 17, 2025 •

edited

Loading