Supporting Several Aspire Host Projects - Contract changes

[rajeshkamal5050]

From @abpiskunov offline - Corner case scenario where there could be several Aspire Host projects and VS has added some support to let user pick one. In deployment scenario we already explicitly in some host project since user opened a Publish designer for it. We might want to add "hostProjectPath" to our contracts and we would pass it to the azd server everytime. If we do it we need to do it now, to avoid version changes later (which will be more work). Azd does not have to use that "project path" but contracts has to be changed now.

cc @ellismg @weikanglim @abpiskunov @anvillan

[vhvb1989]

I think this impacts azd easy init, azd needs to list and ask the user which appHost to use, instead of returning an error

[weikanglim]

My preliminary thoughts:

I'm wondering how multiple apphost projects would be structured. Ideally, they're treated as different deployable application from azd's perspective. In this case, we'd want an azure.yaml per apphost project.

In a scenario where the file structure looks like:

- Solution/
   - App1/
     - azure.yaml
     - App1.AppHost/
     - App1.Api/
   - App2/
     - azure.yaml
     - App2.AppHost/
     - App2.Api/

This would work nicely. When VS calls InitializeSessionAsync, you could pass the "hostProjectPath" for Solution/App1 and Solution/App2 respectively. Since all other calls past this references the session, we wouldn't need to update all the contracts.

The one restriction here from azd right now is that azure.yaml file "should be located above the projects being referenced". In a case where:

- Solution
   - App1.AppHost/
   - App1.Api/
   - App2.AppHost/
   - App2.Api/

I'm not sure how we could handle this yet.

[rajeshkamal5050]

Multiple app host projects in a solution is not supported and is out-of-scope for Aspire 8.0/GA

[christiannagel]

Please think about this scenario with one solution:

- Solution
  - App.Azure.AppHost
  - App.Prometheus.AppHost
  - App.Service1
  - App.Service2 

Where both AppHost projects reference the same service projects but have different app-models. The Azure AppHost uses AppConfiguration, KeyVault, App Configuration..., whereas the Prometheus AppHost uses Docker containers for Prometheus and Grafana.

First, I had one AppHost and switched between Azure and Prometheus by starting the AppHost locally based on a startup profile. Up to Aspire preview 3, the environment was forwarded to the service projects (where I need this information to switch based on using App Insights / Prometheus). Since Aspire preview 4, this information is not forwarded, and using multiple apphost projects make this easy in the local development environment. Discussion: https://github.com/dotnet/aspire/discussions/2707

I don't think this is a corner case. I have clients developing services to run on-premises, using Microsoft Azure, and AWS. With this it's still possible to use native cloud services by just using different app-model definitions. In such a scenario, multiple solution files could be used, and every solution file references one app host project, and service projects that are referenced from multiple solution files.

Referencing the AppHost project could solve all this?