Support for MAUI runtimes in ASP.NET Core?

[JustArchi]

Hey,

I apologize in advance if this is not the correct place to ask this, but I didn't find any better one. Feel free to move this issue if appropriate.

For testing purposes, in MAUI net6.0-android project I've tried to reference other project of mine targetting net6.0 which is a library. I didn't have any issues doing so, but during compilation I've stumbled upon following error:

Error NETSDK1082 There is no Microsoft.AspNetCore.App runtime package available for the specified RuntimeIdentifier "android-x86"

If I understand this right, I can reference standard net6.0 projects because Microsoft.NETCore.App.Runtime.Mono.android-x86 exists and is usable, at least I successfully did that with example net6.0 library. However, I'd like to reference a library that has actual ASP.NET Core elements (Kestrel web server, API with MVC etc), which according to the error is impossible because it can't find a required android-x86 runtime, which seems to be correct as of today.

Now I apologize if I'm trying to do some extreme stupidity, or I don't understand something, but I wanted to verify whether it'd be possible to "convert" existing CLI project of mine which uses Kestrel and API controllers into an Android MAUI app that could start the "backend" part on the target machine, with some nice frontend utilizing those API endpoints over HTTP. I'm testing this in .NET 6.0 preview 6 if it matters.

Is this possible/planned? Or perhaps I'm doing something horribly wrong?

In any case, thank you in advance for answering, I appreciate it.

[Eilon]

(Transferring back to aspnetcore repo...)

Hi @JustArchi , code that is specific to ASP.NET Core scenarios, such as hosting Kestrel, requires platform support, which as you discovered, it not available on some platforms, such as Android.

I think this might really be a question for the ASP.NET folks as to whether there is a desire to support certain features, such as Kestrel, on "arbitrary" platforms, or whether to specifically add support to particular platforms (e.g. android-x86).

Hosting a local web server in a cross-platform app is something reasonable (though perhaps not super common), so it's worth considering.

For right now I'm not aware of any plan to support this.

[Eilon]

Tagging @danroth27 because I think you mentioned something about this the other day.

[JustArchi]

Thanks for your answer @Eilon, I appreciate it.

Hosting a local web server in a cross-platform app is something reasonable (though perhaps not super common), so it's worth considering.

Yeah I definitely don't see everybody jumping on this idea right away and bundling every Android/iOS/etc app with a local web server, but I also came to conclusion that it's something reasonable enough to at least suggest/evaluate on. I have no idea how much work would be required to bring ASP.NET Core runtime to those new .NET 6.0 platforms, but if it helps in any way then I'd be definitely interested in making use of such functionality, at least for that one use case I have in mind.

It could also be a decent alternative if somebody wanted to build an app that looks more like a typical website to you. To give you some idea, I have a CLI app realizing its functionality with bundled Kestrel web server and MVC APIs, which is not really any different from a typical ASP.NET Core website, but it's more of the CLI app and APIs are just an extra. Anyway, I bundle that app with frontend written in html/css/js (static files that Kestrel serves), which results in user navigating to his localhost app address, where he can control the app through a website interface (that calls appropriate API endpoints).

As an experiment I tried to convert this "idea" into Android app, where the app could create a very simple Webview with that localhost address (where the frontend is already mobile-aware), while launching the backend part the same as on all other OSes I build this for. This in result failed as of today, since there is no ASP.NET Core runtime for Android (which is just an example platform I tried to test it on).

I'm describing that just to give you some insight into what this whole "feature request" could be useful for, while MAUI is great on its own and building new apps is definitely going to be interesting, there might be more of such CLI apps with some kind of web interface that could easily be converted into Android apps without much hassle if just the ASP.NET Core runtime was available to make use of. It's not like my app requires something more than a web server with static files and MVC APIs anyway.

In any case thank you in advance for evaluation of this idea, perhaps it could be something to think of for the future.

[mkArtakMSFT]

@davidfowl feel free to update the label. This seems to be the closest match.

[juwens]

@JustArchi to second your "reasonable scenario" statement.

We are actually started using local GRPC (client and server) in our current Xamarin app as an IPC technology to communicate between two apps.

We have some LOB-concerns which forces us to do a lot (and kinda complex) local IPC between our app and a third party app.

And to use one identical API technology on all Platforms targets (Android, iOS and Windows) we've chosen grpc.

[eestein]

I've got the "same" problem.
I'm trying to add DI to my maui app using the idea James wrote here https://montemagno.com/add-asp-net-cores-dependency-injection-into-xamarin-apps-with-hostbuilder/
And then I get the error:

NETSDK1082 There was no runtime pack for Microsoft.AspNetCore.App available for the specified RuntimeIdentifier 'iossimulator-x64'.
Sample.Mobile.Maui
C:\Program Files\dotnet\sdk\6.0.100-rc.2.21505.57\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 427

The same goes for maccatalyst-x64, android-x86 and linux-arm.

I created a mauilib with the default structure:

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<TargetFrameworks>net6.0-ios;net6.0-android;net6.0-maccatalyst</TargetFrameworks>
		<!-- <TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows')) and '$(MSBuildRuntimeType)' == 'Full'">$(TargetFrameworks);net6.0-windows10.0.19041</TargetFrameworks> -->
		<TargetPlatformMinVersion Condition="$(TargetFramework.Contains('-windows'))">10.0.17763.0</TargetPlatformMinVersion>
		<UseMaui>true</UseMaui>
		<SingleProject>true</SingleProject>

		<SupportedOSPlatformVersion Condition="'$(TargetFramework)' == 'net6.0-ios'">14.2</SupportedOSPlatformVersion>
		<SupportedOSPlatformVersion Condition="'$(TargetFramework)' == 'net6.0-maccatalyst'">14.0</SupportedOSPlatformVersion>
		<SupportedOSPlatformVersion Condition="'$(TargetFramework)' == 'net6.0-android'">21.0</SupportedOSPlatformVersion>
		<SupportedOSPlatformVersion Condition="$(TargetFramework.Contains('-windows'))">10.0.18362.0</SupportedOSPlatformVersion>
	</PropertyGroup>

	<ItemGroup>
	  <Folder Include="Platforms\iOS\" />
	  <Folder Include="Platforms\Windows\" />
	  <Folder Include="Resources\Fonts\" />
	  <Folder Include="Resources\Images\" />
	</ItemGroup>

</Project>

I tried recreating the projects twice from the command line, but it still won't work. dotnet new maui and dotnet new mauilib.

Is there a workaround for this? I'd very much like to be able to use DI, but I'm blocked as is.

Checking up the nuget repository, I found the references, but for .Mono. Is there something I'm doing incorrectly?

[danroth27]

@eestein .NET MAUI already has support for dependency injection built-in. MauiAppBuilder exposes a Services property that you can use to configure your services. You shouldn't need to add any additional dependencies.

[eestein]

@danroth27 thanks, I appreciate you taking the time to evaluate my question.
The thing is, I'm not adding anything extra.

This is the info for my maui lib.

These are my usings:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Maui.Hosting;

These are the only nuget packages I've got installed:

These are the dependencies:

This is my csproj:

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<TargetFrameworks>net6.0;net6.0-ios;net6.0-android;net6.0-maccatalyst</TargetFrameworks>
		<Nullable>enable</Nullable>
		<UseMaui>true</UseMaui>
		<SingleProject>true</SingleProject>

		<SupportedOSPlatformVersion Condition="'$(TargetFramework)' == 'net6.0-ios'">14.2</SupportedOSPlatformVersion>
		<SupportedOSPlatformVersion Condition="'$(TargetFramework)' == 'net6.0-maccatalyst'">14.0</SupportedOSPlatformVersion>
		<SupportedOSPlatformVersion Condition="'$(TargetFramework)' == 'net6.0-android'">21.0</SupportedOSPlatformVersion>
		<SupportedOSPlatformVersion Condition="$(TargetFramework.Contains('-windows'))">10.0.18362.0</SupportedOSPlatformVersion>
	</PropertyGroup>

	<ItemGroup>
		<ProjectReference Include="..\Sample.Data\Sample.Data.csproj" />
	</ItemGroup>

</Project>

And I still get the error:

/usr/local/share/dotnet/sdk/6.0.100-rc.2.21505.57/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(427,5): error NETSDK1082: There was no runtime pack for Microsoft.AspNetCore.App available for the specified RuntimeIdentifier 'iossimulator-x64'. [/Users/eestein/Documents/dev/smp/sample-repo/Sample/Sample.Mobile.Maui/Sample.Mobile.Maui.csproj]

I'm not trying to waste anyone's time here, believe me when I tell you I research a lot before asking. The thing is I'm stuck on this one since yesterday. Before trying many things I found online I recreated the projects twice and they still won't work. I tried recreating from VS2022 and also from the command line on my macOS. I still get the error when I reference my mauilib from the maui app.

[davidfowl]

Why did you include ASP.NET Core if you're only trying to use dependency injection?

[eestein]

@davidfowl I didn't... I just created the maui lib using the provided template. And, I also tried removing that framework, I just couldn't find a way to do so.

I do need to use HttpClient, though

[Eilon]

@eestein is that the CSPROJ of the project that's failing, /Users/eestein/Documents/dev/smp/sample-repo/Sample/Sample.Mobile.Maui/Sample.Mobile.Maui.csproj? Is there any other .targets or .props file or a global.json that might be affecting things?

[eestein]

@Eilon let me take a closer look and I'll get back to you on that. Thanks.

I'm also looking for specific packages that could be adding the FW.

[davidfowl]

Maybe it's the SampleData project reference?

[Eilon]

A plain dotnet new mauilib should not reference AspNetCore in any way, so something else is bringing it in.

[eestein]

Thank you, gentlemen!
@davidfowl your comment made me realize there was one specific thing I hadn't tracked. The problem was that one of the libs had a reference to FluentValidations.AspNetCore instead of FluentValidations. That's what was loading the aspnetcore FW.

I'm sorry to have wasted your time. But I also think, if possible, a better error message could be provided. If in the message we could see the offending library, that would help a lot!

Thank you all, @danroth27 , @Eilon and @davidfowl

Please consider my suggestion for the error message.

[juwens]

Come on guys and gals, GRPC is THE strongly advertised tech from MS for IPC and SOA.
You really need to bring asp.net to Net 6 (Xamarin) iOS and Android Runtimes.

In the end, that was the promise MS made, one runtime for all Platforms, not: your lib might only run on one or two Net 6 runtimes (bot not on ios or android or uwp).

Today we can still use the "Grpc.Core" Server wich works without asp.net, but this will be deprecated in the near future.

rpc-dotnet (the Grpc.Net.Client and Grpc.AspNetCore.Server nuget packages) is now the recommended gRPC 
implementation for .NET/C#. The original gRPC C# implementation (the Grpc.Core nuget package)

https://grpc.io/blog/grpc-csharp-future/

[ramondeklein]

I am quite confused why this is still not supported. I already use the Kestrel webservice in my Xamarin app for a while. It seems that Microsoft.AspNetCore (v2.2.0) works fine in Xamarin and probably will work in MAUI too. Later versions don't work anymore, because they are not available as separate packages. I never understood why an application that exposes a web-service should be treated so special (I don't know of any other language that does this). ASP.NET core was just a bunch of packages with .NET core v2.2 and it worked fine.

I tested it with iOS, Android and UWP applications without any issues. I was hoping that MAUI and .NET 6 would really bring us one .NET.

[danroth27]

Hi folks. I'd like to collect some more details on the specific scenarios for using ASP.NET Core in a mobile app. So far from the feedback in this issue I've identified two scenarios:

• Building a mobile app as a locally hosted web app (Support for MAUI runtimes in ASP.NET Core? #35077 (comment))
• IPC between apps using gRPC (Support for MAUI runtimes in ASP.NET Core? #35077 (comment))

Anything else?

[juwens]

@danroth27 thanks for taking a look into this.

Additional to #35077 there is local network GRPC planned.
For example:

• GRPC call from a smartwatch to mobile-phone
• GRPC call from a pc to a mobile phone

tl/dr:

• case "smartwatch -> mobile" : ad-hoc controlling the app temporarily, when you need your hands and cannot hold the mobile phone at the moment; afterwards continuing on the phone
• case "pc -> mobile phone": use the convenience of a keyboard and big screen to enter data and review the result of the data collected with the mobile phone

It all boils down to one person continuously switching between 3 devices (mobile phone, pc, smartwatch) to do its work.
Functionality/state which is held on one "main" device (usually mobile phone), and depending the circumstances is controlled by phone itself, smartwatch, pc.

Usually you would do that with a central server/could service holding the state/functionality.
For privacy and ease of configuration reasons, we are bound to the solution of no-server/cloud solution, where the "main" device holds the state.

[nextfool]

Hi folks. I'd like to collect some more details on the specific scenarios for using ASP.NET Core in a mobile app. So far from the feedback in this issue I've identified two scenarios:

• Building a mobile app as a locally hosted web app (Support for MAUI runtimes in ASP.NET Core? #35077 (comment))
• IPC between apps using gRPC (Support for MAUI runtimes in ASP.NET Core? #35077 (comment))

Anything else?

This absolutely wonderful, thinking about a fully functioning backend web server (restful api, gRPC, signalR, database etc.) working with WebView, this gonna change the way people build mobile apps!!!

Really looking forward to this.

[dougbu]

Putting this on the @dotnet/aspnet-blazor-eng radar. This is not really a general area-infrastructure issue.

[ramondeklein]

@dougbu I’m not sure why this is marked a Blazor issue. It has nothing to do with Blazor. When you read my comment from December 7, then I try to explain that it is a fundamental .NET issue, because Kestrel isn’t an ordinary package anymore, but considered a “platform”. It”s not a real MAUI issue, but a fundamental ASP.NET issue.

We implemented a Kestrel based webserver (using ancient Kestrel package from the .NET Core 2.2 era) and have an Angular client on top of it. It works great, but not being able to upgrade Kestrel is not a sustainable solution.

[BretJohnson]

Would using https://github.com/microsoft/vs-streamjsonrpc meet the needs here, for many of the use cases like those described by @softworkz here #35077 (comment)? It seems like a good match and is in fact what I'm using currently for MAUI app to desktop RPC connectivity (over a socket connection). VS / VS Code brokered services also use JSON RPC heavily with this library. It works well. If there's a need for a web server, to serve up web pages, ASP.NET seems like a good match. But when the need is doing bidirectional RPC-style communication between a MAUI app and anything else, using JSON RPC seems like a better tool for the job.

[softworkz]

Would using strmprcjsn meet the needs here, for many of the use cases like those described by @softworkz here #35077 (comment)? It

In the comment you referenced, I wrote:

in most cases it's nothing more than having a replacement for the age-old and buggy HttpListenerHost implementation

and futher above:

as we just need a really small piece of the cake (i.e. a decent http and websocket server)

So I'm afraid, but "strmprcjsn" is far away from any of the use cases I have described.

If there's a need for a web server, to serve up web pages, ASP.NET seems like a good match.

Which is the actual (and only) subject of this conversation.

[BretJohnson]

@softworkz Thanks. I think I just misunderstood your use cases. Here's another summary comment #35077 (comment), identifying two main types of use cases:

• Building a mobile app as a locally hosted web app (Support for MAUI runtimes in ASP.NET Core? #35077 (comment))
• IPC between apps using gRPC (Support for MAUI runtimes in ASP.NET Core? #35077 (comment))

For the second use case (IPC) doing JSON-RPC, via streamjsonrpc or another library, is arguably a good choice, as is gRPC. No web server required.

For the first use case (building a mobile app as a web app), you of course need some kind of web server, ASP.NET being a candidate. Though for that use case, it's not (yet) clear to me why most folks wouldn't want to use MAUI Blazor Hybrid for this, as it's kind of made for that. I expect there are some good reasons, but I haven't read the full thread to understand them yet.

[softworkz]

Though for that use case, it's not (yet) clear to me why most folks wouldn't want to use MAUI Blazor Hybrid for this, as it's kind of made for that.

Maybe because some already have a mature application architecture running on a wide range of platforms and are looking for appropriate middleware which allows them to run their software on MAUI in a webview with little changes (and without redeveloping).
Or maybe, because Blazor/Hybrid doesn't allow to cover all use cases or is too specific and inflexible for your requirements.
Or maybe, becasue the primary purpose of the http server is not actually to drive an app's UI and you are not just serving to localhost but to the local network or even beyond.

Reading through the whole thread reveals, that the ones you quoted are not "the two main use cases". There are many different ones actually, and when you need a webserver, then you need a webserver and not Blazor hybrid and surely not streamrpc or something. There are plenty of ways to do network communication in some form and I think everybody how came here knows that and would have already chosen an alternative way when the requirement wouldn't be specifically about having an http server.

[BretJohnson]

@softworkz Thanks. I better understand where you're coming from now.

[JamesNK]

@BretJohnson Dan Roth asked for scenarios where this feature would be useful. I recommend looking at its replies as a good starting place: #35077 (comment)

[BretJohnson]

Thanks. I read thru all of the replies (there are so many!). Now I see that while streamjsonrpc (which doesn't require ASP.NET) may be a good choice for greenfield RPC needs, ASP.NET is so darn useful and widely used, including for support of gRPC, that there are lots of reasons to support it (or at least the most used subset of it) being embedded in MAUI apps.

[softworkz]

Bret - somehow I get the impression that you are on an advertising mission, trying to place as many sentences as possible containing strmprcjsn...

[BretJohnson]

That wasn't really my intention. We've been using it a lot for the Microsoft stuff I work on, including mobile, for IPC, and I rather like it, but folks should use whatever works best for them. If gRPC is a better choice, use it (though I guess it currently has the ASP.NET dependency). Or use something else. I'm on a MAUI tooling team at Microsoft btw - not MAUI itself, but kind of MAUI adjacent. Mostly I wanted to understand well customer needs here, for both IPC and non-IPC scenarios, to help us meet them. And I think I have a pretty good sense of that now.

[Falco20019]

Hey @JamesNK and @danroth27, any updates on a roadmap/plans for this?

[JamesNK]

Nothing will happen in .NET 9. Other work took priority.

We'll consider it for .NET 10.

[Falco20019]

Thanks for the Heads-up!

[JamesNK]

Stop adding +1 comments.

If you're interested in this feature then you can add a thumbs up reaction to the original issue. They're considered when gauging interest in a feature.

[JamesNK]

There is no stale bot here. Don't spam peoples notifications.

[softworkz]

There is no stale bot here. Don't spam peoples notifications.

If you hide my post and reply to it without quoting, your response appears a bit out of place...

Anyway, it was rather meant as a joke than condoning "+1" posts. But I think that when people would lay out their uses cases instead and explain why they need it for those, it would provide value to this thread and have more weight than a thumps-up.

[TechnikEmpire]

There is no stale bot here. Don't spam peoples notifications.

If you hide my post and reply to it without quoting, your response appears a bit out of place...

Anyway, it was rather meant as a joke than condoning "+1" posts. But I think that when people would lay out their uses cases instead and explain why they need it for those, it would provide value to this thread and have more weight than a thumps-up.

Sure. Because it's almost 2025, and HTTP 0.9 was released in 1991, along with the first HTTP 0.9 server, and .NET is not capable of letting me run its official HTTP 0.9 server on mobile platforms. I hope this explains the use case.

[ferhrosa]

The use case for the company I'm currently working on:
We have some POS software already made using .NET, for Windows. Some of these software have a web API and SignalR running on them, so they act as a local server.
But nowadays there are many Android POS devices. These devices are cheaper than PCs with Windows. So more and more customers want to use these devices instead.
So we would like to make some of these software to run on Android too.

[Falco20019]

As update to #35077 (comment):

With the deadline of https://groups.google.com/g/grpc-io/c/iEalUhV4VrU already passed again (promised to be supported until "at least October 2024") it's a gamble for our company to still have to rely on Grpc.Core to use for Android. grpc-dotnet is still not usable, so we are still out of migration paths forward. As long as no critical security issues arise, everything is fine and we (have to) stick with the available "experimental" implementation.

But it's still annoying as it makes us having to stick on a nearly 2 year old version also for Windows as we have to stick with it for cross-targeting reasons.

[juwens]

@Falco20019

Sadly everything related to maui is a gamble, and has underwhelming support by MSFT.

As update to #35077 (comment):

With the deadline of https://groups.google.com/g/grpc-io/c/iEalUhV4VrU already passed again (promised to be supported until "at least October 2024") it's a gamble for our company to still have to rely on Grpc.Core to use for Android. grpc-dotnet is still not usable, so we are still out of migration paths forward. As long as no critical security issues arise, everything is fine and we (have to) stick with the available "experimental" implementation.

But it's still annoying as it makes us having to stick on a nearly 2 year old version also for Windows as we have to stick with it for cross-targeting reasons.