Remove deprecated IDistributedApplicationLifecycleHook interface

[Copilot]

Overview

This PR removes all usages of the deprecated IDistributedApplicationLifecycleHook interface and replaces them with modern event-based patterns, as required by dotnet/aspire#11266.

Changes

Deno & Bun: Installer Resource Pattern

Previously, Deno and Bun used lifecycle hooks to install packages before application startup. This PR migrates them to use the installer resource pattern (consistent with NodeJS npm/yarn/pnpm):

Before:

resource.ApplicationBuilder.Services.TryAddLifecycleHook<DenoPackageInstallerLifecycleHook>();

After:

var installer = new DenoInstallerResource(installerName, workingDirectory);
var installerBuilder = builder.AddResource(installer)
    .WithArgs("install")
    .WithParentRelationship(resource.Resource)
    .ExcludeFromManifest();
resource.WaitForCompletion(installerBuilder);

Files Changed:

• Added: DenoInstallerResource.cs, BunInstallerResource.cs
• Removed: DenoPackageInstallerLifecycleHook.cs, DenoPackageInstaller.cs, BunPackageInstallerLifecycleHook.cs
• Updated: DenoAppHostingExtensions.cs, BunAppExtensions.cs

Dapr: IDistributedApplicationEventingSubscriber Pattern

Dapr's lifecycle hook has been converted to use the IDistributedApplicationEventingSubscriber pattern for idempotent registration:

Before:

builder.Services.TryAddLifecycleHook<DaprDistributedApplicationLifecycleHook>();

After:

builder.Services.TryAddEventingSubscriber<DaprDistributedApplicationLifecycleHook>();

// In the subscriber class:
public Task SubscribeAsync(IDistributedApplicationEventing eventing, DistributedApplicationExecutionContext executionContext, CancellationToken cancellationToken)
{
    eventing.Subscribe<BeforeStartEvent>(OnBeforeStartAsync);
    return Task.CompletedTask;
}

Files Changed:

• Updated: IDistributedApplicationBuilderExtensions.cs, DaprDistributedApplicationLifecycleHook.cs

Pattern Benefits:

• Idempotent registration via TryAddEventingSubscriber (similar to old TryAddLifecycleHook)
• Cleaner separation of concerns with subscriber pattern
• Consistent with other Aspire infrastructure components (e.g., Azure AppService)

Tests

Updated tests to use standard public APIs instead of internal lifecycle hook methods:

• Replaced ExecuteBeforeStartHooksAsync() with app.StartAsync()
• Added tests to verify installer resources are created correctly
• Removed UnsafeAccessor reflection code

Benefits

1. No deprecated APIs - Eliminates all usages of IDistributedApplicationLifecycleHook
2. Consistency - Deno and Bun now follow the same pattern as NodeJS integrations
3. Better visibility - Package installers now appear as resources in the Aspire dashboard
4. Improved testability - Tests use standard public APIs
5. Idempotent registration - Dapr uses IDistributedApplicationEventingSubscriber for proper lifecycle management
6. Future-proof - Aligned with current .NET Aspire architecture

Migration Notes

No breaking changes for users:

• WithDenoPackageInstallation() and WithBunPackageInstallation() work exactly as before
• AddDapr() continues to work with the same API
• The only visible change is that installer resources now appear in the Aspire dashboard

Fixes #890

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Ensure life cycle hooks interface isn't used anymore</issue_title>
<issue_description>See dotnet/aspire#11266 - IDistributedApplicationLifecycleHook has been deprecated, so we need to ensure it's no longer used.</issue_description>

<agent_instructions>Compiling the solution will show the errors around the obsolete type and gives an indication on what to fix.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes #890

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[davidfowl]

You want to replace these with IDistributedApplicationEventingSubscriber is there a branch for 13? Is it main?

[aaronpowell]

You want to replace these with IDistributedApplicationEventingSubscriber is there a branch for 13? Is it main?

don't we want to replace them with the On<Event> methods?

[davidfowl]

IDistributedApplicationEventingSubscriber is a way to get both idempotency during registration (TryAddLifecycleHook) and it relies on subscribing to events via the On<X> methods.

[aaronpowell]

@copilot according to @davidfowl we should be using IDistributedApplicationEventingSubscriber instead. Here is the type definition: https://github.com/dotnet/aspire/blob/05ef4762f6748e9a8ff3d30857ab07bac3fd6f54/src/Aspire.Hosting/Lifecycle/IDistributedApplicationEventingSubscriber.cs#L12-L22 and you can find an example usage https://github.com/dotnet/aspire/blob/05ef4762f6748e9a8ff3d30857ab07bac3fd6f54/src/Aspire.Hosting.Azure.AppService/AzureAppServiceInfrastructure.cs#L73-L77 with the registration of the type https://github.com/dotnet/aspire/blob/05ef4762f6748e9a8ff3d30857ab07bac3fd6f54/src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs#L22-L32

[Copilot]

@copilot according to @davidfowl we should be using IDistributedApplicationEventingSubscriber instead. Here is the type definition: https://github.com/dotnet/aspire/blob/05ef4762f6748e9a8ff3d30857ab...

Updated Dapr to use IDistributedApplicationEventingSubscriber following the pattern from the Azure AppService example. The subscriber is now registered with TryAddEventingSubscriber for idempotency, and the SubscribeAsync method subscribes to BeforeStartEvent.

Commit: 69ebc86

[aaronpowell]

@davidfowl how's that looking?

[davidfowl]

This call isn't idempotent. There's a new helper here https://github.com/dotnet/aspire/blob/5a87acfdb041ce3f89189a8af379fa24df4f3d44/src/Aspire.Hosting/DistributedApplicationBuilderExtensions.cs#L91.

You can use it like so https://github.com/dotnet/aspire/blob/5a87acfdb041ce3f89189a8af379fa24df4f3d44/src/Aspire.Hosting/ProjectResourceBuilderExtensions.cs#L822-L829

[aaronpowell]

But this is moving away from the event model for doing this to the same model used for npm/pnpm/etc. installing.

[davidfowl]

Same comment as above.

[davidfowl]

Yep!