Skip to content

Instantly share code, notes, and snippets.

@davidfowl
Last active July 12, 2025 23:22
Show Gist options
  • Save davidfowl/b408af870d4b5b54a28bf18bffa127e1 to your computer and use it in GitHub Desktop.
Save davidfowl/b408af870d4b5b54a28bf18bffa127e1 to your computer and use it in GitHub Desktop.
Aspire Resource Model: Concepts, Design, and Authoring Guidance
@oising
Copy link

oising commented Jun 3, 2025

When a resource implements the IResourceWithParent interface, it declares true containment — meaning its lifecycle is controlled by its parent:

Startup: The child resource will only start after its parent starts (though readiness is independent).
Shutdown: If the parent is stopped or removed, the child is also stopped automatically.

I find this really confusing as a resource author. It implies that IResourceWithParent imparts direct and automatic control of child resources, when the reality is very different. Resource authors decide which methods comprise startup calls, and also they choose lifecycle hooks and wire up eventing to call these things. How exactly does Aspire enforce these semantics?

@oising
Copy link

oising commented Jun 3, 2025

There could be an analyzer that validates this -- example, if we say that "start" methods should be annotated with [EntryPoint] or [Startup], then a basic analyzer could ensure that these methods are not being called inside inappropriate eventing callbacks. Even then, this won't cover all scenarios. Something feels "off."

@davidfowl
Copy link
Author

I think we will change this assumption. This really only applies to specific resources...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment