Open captainsafia opened 2 months ago
I'm gonna move this out of 9.0 since I don't think we'll be able to deliver something before 9.0 for this.
I think this is a good candidate for post-9.0 work though.
We'll have to reason through how some of the changes we applied for Functions, I'm thinking specifically about the endpoint/port related changes for publishing, will mesh with fully modeling Functions as projects.
For some scenarios, specifically Azure Functions, we want to implement Functions-specific behavior in Aspire APIs like Azure Functions. We currently achieve this by defining a custom
AzureFunctionsResource
resource type that is a wrapper around the defaultProjectResource
type. This pattern allows us to model specific behavior to targetAzureFunctionsResource
. However, it requires that users call theAddAzureFunctionsProject
extension method in order to be able to invoke Functions-specific code.An additional approach is to support attaching additional metadata into pre-existing
ProjectResources
and support targeting our Functions-specific methods onto that interface:In order to support this scenario, we need to be able to customize the interfaces that are applied to the
AzureFunctionsTest_Functions
type via MSBuild and the cogeneration step. To achieve this, we need to support an@(ExtraInterfaces)
property that hosting packages can populate with additional interfaces that need to be applied on projects they target.The flow of this would look as follows:
IsAzureFunctionsProject=true
property