Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Aspire recently merged exec support (also see here for pending documentation). This allows tools (such as dotnet ef) to run in the context of the AppHost, exposing resources such as ConnectionStrings or environment variables.
I am currently using the Microsoft.Extensions.ApiDescription.Server package to generate OpenAPI documents at build-time. It would be great if we could have a way to enable aspire exec support for that. This would make the integration & adoption of the OpenAPI package much smoother for Aspire projects as it reduces discrepancies between build- and run-time document generation.
Describe the solution you'd like
Not sure yet. Maybe something like a <ExecuteInAspireContext> would work, that optionally prepends an aspire exec --resource XY -- ... to the dotnet-getdocument command. Resources could be provided via <IncludeAspireResource> or similar.
Maybe there's a more clever way to think about this problem and it could be solved from Aspire or MSBuild entirely.
Additional context
No response
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Aspire recently merged exec support (also see here for pending documentation). This allows tools (such as
dotnet ef) to run in the context of the AppHost, exposing resources such as ConnectionStrings or environment variables.I am currently using the
Microsoft.Extensions.ApiDescription.Serverpackage to generate OpenAPI documents at build-time. It would be great if we could have a way to enableaspire execsupport for that. This would make the integration & adoption of the OpenAPI package much smoother for Aspire projects as it reduces discrepancies between build- and run-time document generation.Describe the solution you'd like
Not sure yet. Maybe something like a
<ExecuteInAspireContext>would work, that optionally prepends anaspire exec --resource XY -- ...to thedotnet-getdocumentcommand. Resources could be provided via<IncludeAspireResource>or similar.Maybe there's a more clever way to think about this problem and it could be solved from Aspire or MSBuild entirely.
Additional context
No response