Aspire integration for service discovery

[moljac]

Description

I am trying to integrate MAUI app with Aspire

Alreay opened issue in Aspire repo:

dotnet/aspire#876

From:

https://github.com/dotnet/aspire/blob/6464fea863ea9ba17712fb38301ec6558bb4810c/src/Aspire.Hosting/Extensions/ProjectResourceBuilderExtensions.cs#L24

Seems like MauiAppBuilder should implement IDistributedApplicationBuilder

https://github.com/dotnet/aspire/blob/6464fea863ea9ba17712fb38301ec6558bb4810c/src/Aspire.Hosting/IDistributedApplicationBuilder.cs#L14

and MAUI project would need to implement:

https://github.com/dotnet/aspire/blob/6464fea863ea9ba17712fb38301ec6558bb4810c/src/Aspire.Hosting/IServiceMetadata.cs#L11

Will dig more. This is conversation starter.

It would be killer feature for some stuff I need and I bet I am not the only one.

Sample
SampleAspireStarter.zip

Discussion

#21064

Public API Changes

Not sure (yet).

Intended Use-Case

Aspire integration for inner dev loop.

[davidfowl]

Seems like MauiAppBuilder should implement IDistributedApplicationBuilder

Maui doesn't need to implement this. This should be handled in the aspire app hosting model. We have to see what it would take to make it work with Maui projects. It's likely more time spent in MSBuild than in code 😄 . Then there's launching the process itself.

Making service discovery work should be doable as well with IConfiguration.

[mattleibow]

One thing that I do know that is a pain is a way to get the configuration from the sky down to the mobile earth. Typically it is a case of hardcoding values and making sure that all configuration things are available.

I hacked this on one of the samples in an attempt to have a azd up and then building the app worked without manual config: https://github.com/BretJohnson/azure-search-openai-demo-csharp/pull/4/files#diff-33df0fd88014f464426c5fcd7c0729b015117d3220ca3e99b64e9377a55bfc9bR103-R118

With aspire, it would be nice if there was a way to pre-configure something. Not sure what other things could be beneficial right now, but this is something that I always forget to do.

[Eilon]

I think there are 2 perhaps unrelated issues related to endpoints:

1. How to make it easier for people to try samples and get started. In this case it could be better to have more things be automatic and "just work"
2. In the real world you always know in advance where your real endpoints are. You know that your APIs are hosted at my_api.example.com. There is no doubt about that, no variation, and it's just something you hard-code in your app

These could be two variations of the same problem, but I'm not prepared to make that assumption.

So even if some app platform had a way of auto-configuring some things during dev, I'm not at all convinced it is what you'd use to solve the production problem.

Using azd up to generate a file could help solve (1), but I don't think it's something you'd want to use for (2). Especially because some people probably have a fake hostname like api.mycompany.example.com that is the friendly name that points to the real Azure resource you deployed to. The only way for the app to know that is to hard-code it.

[moljac]

@Eilon

My main sideproject is field app that collects data on edge mobile (phone/tablet/iot) and does some calculations on device, but main number crunching is on desktop.

So I play with all kinds of MAUI backends, just to see what is feasible for specific use cases. Right now I have sample[s] with backends as microservices and monolith with communication protocols/channels/whatever-the-name-is:

• REST WebApi, Minimal API, WatsonWebServer
• gRPC,
• SignalR (selfhosted)
• WCF Core,
• WebSockets WatsonWebsockets
• WatsonTCP
• etc

Launching few of those to test MAUI app that uses just subset of those is cumbersome. OK. I ve been using tye, but it needs scripts to launch multiple projects.

I watched Aspire talk on .NET@MS and I said it is nobrainer I need this just that MAUI app discovers endpoints in inner dev loop. Aspire is magic - no need to write down or search for endpoints (ports) etc..

I think there are 2 perhaps unrelated issues related to endpoints:

1. How to make it easier for people to try samples and get started. In this case it could be better to have more things be automatic and "just work"
2. In the real world you always know in advance where your real endpoints are.

I don't right after I do dotnet new webapi... And Aspire solves that.

You know that your APIs are hosted at my_api.example.com. There is no doubt about that, no variation, and it's just something you hard-code in your app

OK. From what I have heard/seen. Aspire does not focus on deployment (for now), so no my_api.example.com.
The focus is on inner dev loop. dotnet run single project and start developing distributed apps with MAUI app being one of clients.

These could be two variations of the same problem, but I'm not prepared to make that assumption.

So even if some app platform had a way of auto-configuring some things during dev, I'm not at all convinced it is what you'd use to solve the production problem.

I think ASP.net team is working on deployment too...

This should be something in that direction (I am not docker/kubernetes expert, not even intermediate)

https://github.com/dotnet/aspire/blob/main/samples/eShopLite/AppHost/aspire-manifest.json

Using azd up to generate a file could help solve (1), but I don't think it's something you'd want to use for (2).

I don't even have azd installed. (Shame on me) And I launched aspire-starter without hassle and added MAUI app, but integration is missing and David explained what would need to be done.

Especially because some people probably have a fake hostname like api.mycompany.example.com that is the friendly name that points to the real Azure resource you deployed to. The only way for the app to know that is to hard-code it.

Or magic that Aspire does via project references and MSBuild...

[moljac]

Added playground repo

https://github.com/Samples-Playgrounds/Samples.Aspire

[Eilon]

@moljac agreed, I think there's definitely things we can improve for the dev experience, which should make it faster to get started with a project, and easier to do local dev work. I just wanted to note that this could be a different problem from a production case where you probably just "need to know" your real production end point (or at least primary discovery source), and that can be done by hard-coding to a known URL.

[davidfowl]

I think the work is mostly in aspire. It requires some msbuild magic somewhere

paging @baronfel

[baronfel]

Interesting problem. What's the goal - run all of the variants of the MAUI project? Run a single platform of the client project?

A couple hurdles that jump out to me:

• right now the AppHost project is using ProjectReferences directly - this means that the MAUI project is being asked to build a net8.0 TFM, which of course there isn't for a MAUI project. You can skip this negotiation with settings like SetTargetFramework and SkipGetTargetFrameworkProperties, but it might be too much to ask end users to decorate ProjectReferences with that metadata.
• even if you do that, MAUI apps have to do a bunch of setup to really run - there's often packaging the client app, selecting a device/simulator, pushing it to a device/simulator, and then finally launching the app on the device/simulator. Aspire might need to learn a new protocol for driving that process.
• and of course as mentioned above, you'd want to push any connection string data to the app in some way

@davidfowl some of these concerns is what I was poking at with my crazy metadata-only hack a few weeks ago. I'm not sure that ProjectReference directly is going to be the best final destination for the Aspire UX, and if it is we may have to do a bunch of hacking around.

[Eilon]

@baronfel in addition to that, .NET MAUI apps often run on devices other than what the developer is running their dev environment on. For example, from Visual Studio you can run apps in an Android emulator, an iPhone, or other system configurations. In those cases the URL to talk to for web APIs/services can be different than what you'd be using if you were running on Windows with localhost. For example, if the app is running from Windows on an Android emulator, then it needs to use the IP address 10.0.2.2 to talk to the Windows host.

[moljac]

Interesting problem.

Isn't it? I like complicating things.

What's the goal - run all of the variants of the MAUI project? Run a single platform of the client project?

I would not run all projects, but that would be easy way out (no params/metadata needed). Maybe desktop by default?

I dream of (I dream in code):

app_maui = builder
                .AddProject<Projects.SampleMAUI>("app_maui")
                #if __BRAINSTORMING__
                .Run(new string[] { "maccatalyst", "ios" } )
                .Run("android")
                .MsBuildParams("ios", "")
                #endif
                ;

or maybe

builder.Build()
        .Run()
        #if __BRAINSTORMING__
        .Run(new string[] { "maccatalyst", "ios" } )
        .Run("android")
        #endif
        ;

There are few inconsistencies that might be problem:

1. MAUI uses dotnet build -t:run and not dotnet run
2. iOS launches default simulator (iPad Pro 12.9 on my mac)
3. Android needs running emulator
   I don't see _DeviceName for Android.
   https://learn.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-properties

A couple hurdles that jump out to me:

• right now the AppHost project is using ProjectReferences directly - this means that the MAUI project is being asked to build a net8.0 TFM, which of course there isn't for a MAUI project.

Isn't net8.0-* superset of net8.0? Mathematically speaking.

You can skip this negotiation with settings like SetTargetFramework and SkipGetTargetFrameworkProperties, but it might be too much to ask end users to decorate ProjectReferences with that metadata.

Can you point me to some samples please? Or I'll bing it.

• even if you do that, MAUI apps have to do a bunch of setup to really run - there's often packaging the client app, selecting a device/simulator, pushing it to a device/simulator, and then finally launching the app on the device/simulator.

Yes, but it is NOT THAT complicated. MAUI team (and folks) did some great job to simplify that.
OK. I will add that to next comment.

Aspire might need to learn a new protocol for driving that process.

No. I don't think so....

• and of course as mentioned above, you'd want to push any connection string data to the app in some way

@davidfowl some of these concerns is what I was poking at with my crazy metadata-only hack a few weeks ago.

Can you point me to crazy stuff please?

I'm not sure that ProjectReference directly is going to be the best final destination for the Aspire UX,

But it looks lovely... I would like to know about Projects.*stuff and how to generate it for MAUI. Then I will try to see with extension methods how far can I go.

and if it is we may have to do a bunch of hacking around.

Or maybe not. The time will tell.

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.