Runtime: .Net Core vnext

[Pinox]

Reading blogs about .net core 3.0 becoming leaner and meaner without json depencies etc, I always wonder about the future possibilities of the framework. Currently Xamarin is running on mono and there is ongoing work where c# can also potentially work on WASM in the browser.

So on the one side you have Mono with all this cross platform capability and on the other side you have .Net Core that also runs cross platform. .Net Core 3.0 also enables a desktop layer in Windows where it can be used with UI libraries (UWP , Winforms & WPF).

I assume WASM and Xamarin will stay more Mono focused for the foreseeable future. My question is , if .net Core works cross platform on the server and within the desktop layer on Windows (with .net Core 3). What prevents .net Core vnext to work with native Android and iOS apps ?

Therefor on Windows => .Net Core =>Visual Studio- UWP (native windows app)
Android => .Net Core => Android Studio (native android app)
iOS => .Net Core => XCode (native iOS app)

Can we potentially move into a world where .Net Core works on the server and the business logic of all native apps ? (UWP , iOS , Android )

It would be absolutely awesome if we can simply use all the Native App UI's and then .Net Core everywhere else (therefor one code base for everything except the UI layer) !!!

[StingyJack]

Can we potentially move into a world where .Net Core rules

I'd like to pass on that. I don't want the framework that is less tested, less feature complete, and that requires that much effort to switch to to rule anything.

[Pinox]

@StingyJack Agree, probably a bit strong wording on my side. I edited the text. I simply want to know the hurdles .net core face to make this work. I see it as an potential alternative to all existing solutions in the market. Just think if MS is already planning .net core 3.0 on the desktop for Windows then making it work for iOS and Android looks like low hanging fruit to me and will give .net core a massive boost. Not too mention the potential payback for Azure Cloud services that's tightly integrated with .net core. We know Xamarin is a transpiled solution with Xamarin Forms giving developers the option of 1 code base for UI and business logic so that appeal won't disappear , but I think something like this will appeal to those that already has existing native solutions but wants to unify the business logic from server to client app or those that needs a no compromise native UI interface.

Looking at the performant nature of .net core I think it can be a huge drawing card for mobile developers not to mention enterprise solutions that normally have a wide variety of .net skills.

[svick]

making it work for iOS and Android looks like low hanging fruit

I don't believe it is. Porting to a new platform is always lots of work. The teams are working on reducing differences between Mono and .Net Core by sharing code, but I don't think there are any plans to go much further beyond that.

What exactly would be the advantage of migrating Xamarin to .Net Core, that would justify all of that work? Especially since you can already have a single codebase for business logic, if you use .Net Standard.

[Pinox]

What exactly would be the advantage of migrating Xamarin to .Net Core, that would justify all of that work?

@svick Not proposing that Xamarin convert to .net core just asking what the hurdles are to wire up an native Android / iOS app to .net core ?

So MS don't have to worry about the UI's , that has been taken cared of by google and apple , only about "wiring up" the existing native UI's to use .net core. I know nothing about this, but mapping XAML to underlying native api's looks way more complicated that just providing the infrastructure to use c# with native apps by means of .net core.

[svick]

@Pinox

Not proposing that Xamarin convert to .net core

Then I'm confused. What would be the advantage of having two separate ways to run C# code on iOS and Android?

just asking what the hurdles are to wire up an native Android / iOS app to .net core ?

It would be a lot of work. MS is not going to do that work, unless there is a clear benefit. The community might and I believe .Net Core already works in a limited fashion on Android (see qmfrederik/coredroid and https://github.com/dotnet/coreclr/issues/1097).

[Pinox]

Then I'm confused. What would be the advantage of having two separate ways to run C# code on iOS and Android?

@svick Performance with native UI. - running native UI's integrated with performant .net core on one code base.

I see this (.net core working with native iOS / Android ) as the equivalent of Mono running in the browser through WASM and using any front end framework like React or Angular. That is how web front end frameworks are going to achieve "near native performance" with all the benefits of the respective UI communities. (obviously running any binary code in WASM not c# per se.)

So with Blazor the end goal I assume is "front end rendering" in the browser using c# with Mono.

Why not give all Android / iOS developers the option to use .net core with their existing front end investments. With .net core being way more performant than NodeJS I think many developers would luv this. One of the advantages of Node is you can use one language on client and server. Currently .net core can work on server with native apps but you have nothing on the client side. It can potentially put .net core on equivalent footing to Node (mind the wiring-up part)

[svick]

I still don't understand why Xamarin is not an acceptable solution for you.

Even if it doesn't support the kind of mixing of native code with .Net that you want today (or maybe it does?), I think it would be much more easier to add that one capability to Xamarin, than adding full support for iOS and Android to .Net Core.

And if Xamarin is not performant enough for you, then I think the solution is to improve Xamarin's performance, instead of switching to a completely different framework.

[Pinox]

@svick It's not about replacing Xamarin. It's rather why can't it be done ?

For me, this completes the picture.

[svick]

It's rather why can't it be done ?

That's never the question. The question that has to be answered is: Why should it be done?

There are lots of things that can be done and limited resources to do them. Because of that, any reasonable team will choose to do things that have good reasons in favor of doing them, not those that don't have any reasons against doing them.

[lextm]

If you read threads like https://github.com/aspnet/Blazor/issues/286 you know that both .NET Core team and Mono team are fully aware of the situation.

.NET Core and Mono converge to each other already like never before, by sharing BCL code and compliant to .NET Standard 2.0 (and upcoming 2.1).

If you are impatient to wait, send pull requests to conquer the challenges please.

[Pinox]

@svick Limited resources are a relative concept when you pay $7.5 Billion for GitHub. The reality is each audience has a market value. How much did MS pay for Xamarin ? I don't know. What I can say is if MS can get .Net Core working on native mobile apps that can in my opinion even be bigger than Xamarin itself.

The Xamarin user IMO is totally different market segment than a typical native mobile app developer that prefers a native UI no compromise and no MS transpilation , and yes Xamarin might lose some customers but MS will have a much bigger share of the market and that has lots of "value". The benefit for a cloud service like Azure can be absolutely enormous. The cherry on the cake, you never have to maintain the UI components ever. To me this looks and feels like WASM on the browser. Ideal I would say.

BTW I'm a Xamarin user and I only have the highest respect for the whole team , but the question that I ask here is probing the future and when you do that there should be no "holy cows".

If I had a wish list I will make Mono/.Net Core an absolute first class citizen in WASM and I will take that concept and apply it to native apps as I suggested above in my diagram. Thanks for sharing your thoughts.

[svick]

@Pinox You're saying there's a market gap that should be filled. I think that's a good reason to do something.

What I still don't understand is: Why do you keep insisting it has to be .Net Core that fills that gap, not Xamarin?

Look at it this way:

To make Xamarin work for your use case, you need to:

1. Ignore its UI components, and possibly others, which should be easy.
2. Modify it so that it works well for your use case. Let's say that's medium amount of work.

To make .Net Core work, you need to:

1. Port .Net Core to Android and iOS. I think this would be a huge amount of work.
2. Modify it so that it works well for your use case. This would still be a medium amount of work.

Based on that, I think Xamarin is a much better choice for your use case than .Net Core. Why do you think it's not? Yes, Xamarin is currently targeted at a different market segment, but .Net Core is targeted at a completely different market segment, so I don't think that's a hurdle.

[Pinox]

@svick

Why do you keep insisting it has to be .Net Core that fills that gap, not Xamarin?

Very good question, I think my biased tendencies are based on a mix of perception and factual.

Let me start off and define a litmus test for "extremely performant & clever engineering":
(Native UI's and .net core) are faster or equal to a ( standard native application)

The above statement should never be valid except if .net core is so performant that it offsets the extra layer of interaction. If MS ever manage to attain such status, it will change the "status quo" fundamentally in all platforms as it alludes to "brilliance" unseen before.

Also, the native crowd is by it's very nature extremely performant orientated, no shortcuts in performance accepted.

Based on the above 2 ideals of targeting such a "market segment" my tendency towards .net core is based I think mainly on performance and perception.

• .net core is way more performant than Mono.
• .net core has a "first mover" advantage in that they are currently targeting UWP on the desktop with hopefully performance as a feature
• my perception is .net core wants to remove the shackles of .net framework that is holding it back
• it's already working on Linux, MacOS , Windows and soon Desktop UWP.
• performance credential is a stated feature.
• most importantly, server and client will then use the same library.

Now Mono is amazing , versatile , works on more architectures but it lacks one key ingredient - performance as a feature. Also, it might create a perception at/about Xamarin that Xamarin is "cool no more" and that will be a huge mistake.

So short-term, yes you are probably right working in the constraints of "limited resources" Xamarin is probably the go to as they are currently working on getting Mono to work in WASM. Porting it then to Android / iOS might be logical as per your example.

The thing is, I can't help but think what MS needs is a "properly engineered solution" from WASM all the way to Android / iOS. and "not just something that works" It's not OK if it just works, it must work well especially taking into account the target audience.

Get Mono working with WASM , Android / iOS , but once it works then let .net core take over with a "lazer focused" solution that pulls MS closer to my stated litmus test above or give the .net core team wings to make this work from the start.

For interest sake would Xamarin still be your choice if performance was the "primary goal" ?

Port .Net Core to Android and iOS. I think this would be a huge amount of work

I don't know enough about this but the way I see this is Mono / .Net Core is working on Linux and MacOS. Why would Xamarin have an advantage here?

[ysmoradi]

• most importantly, server and client will then use the same library.

Xamarin (Mono) and .NET Core are re-using the same base class library. If you mean runtime, then you're right.

Mono has interpreter mode. It also has full AOT support on top of iOS, Android and web assembly (soon).

.NET core has no interpreter mode and its AOT mode is not production ready.

I'm aware that mono has no RyuJIT and tiered JIT, but those are good to have but not necessary in client side applications. Important parts of mono are also developed by C instead of C#, they should fix this too.

If someday .net core finds its way to iOS and WASM, it comes with a completly different runtime. At server side, JIT is a prefered solution. At client side, AOT is a prefered solution. There won't be one thing on both client side and server side. There is nothing special to share really. They have to re invent the debugger for iOS, you can't use the same debugger you already have in your .net core on Windows. These are some examples only.

[Pinox]

thanks @ysmoradi , I understand now the current view that Mono is further down the path regarding interpreter and full AOT on Android/iOS.

[Simon-Miller]

Thought I might chime in on this one, and share a nickle/penny/cent worth of thoughts.
I think another issue is the debugging experience. Code development and performance are definitely key concerns. Let me lay out a few as bullet points:

• C# versus Java. If we can't run as fast, there's yet another reason not to use C#.
• If we can't run on as many native platforms (current ones anyway) then again, C# would not be seen as quite so cross-platform.
• If we have to use cut down frameworks, is that such a bad thing?
• If we use C#, we can take the moral high-ground!

Let me expand on those, and assure you I'm giving personal views only. So shoot me down if you choose, but my opinion is exactly that. If you agree, all the better. If not, convince me your opinion is the better one.

C# vs Java has been going on since the inception of C#. In the end, Microsoft focused on Windows only for so long, that C# never really got the market share it deserves. (See moral high ground). To that end, I realise that it is rather like comparing apples to oranges, but in the end, the commonality is that we write one language, and it executes as another. So it has always been since the days as assembly language, although that admittedly was more like a translation than a compilation. But I digress. I'm not going to tell you how to compare languages from the developer's point of view - but tooling goes a long way too. Fortunately, C# does well in that department, but so too does Java. So what makes Java more compelling? In this case, from our developing for platforms perspective, we know Android sits on top of Java which sits on top of Linux. So to cross-compile C# to run on a java virtual machine is rather painful. Performance benefits are definitely lost along the way, and you can't expect C# to run faster Java than Java code would. So this comes back to the performance concerns which .NetCore 2+ bridges.

Native platforms: Well, Blazor or not - Xamarin or not. .NetCore 2+ ?? Blazor and Xamarin are all about turning C# into some other JIT'd language. In the case of Blazor, it's trying to make C# smell like javascript or more precisely, WebAssembly / ASM.js. In the case of Xamarin for this discussion about Android, we cross-compile C# into Java binaries, and that's what gets deployed.
So if we consider C# proliferation, I think Xamarin does a sterling job. The cost of which comes down to compilation times, and debugging experiences, which differ greatly from a native Windows or Web development experience. From my own experiences, I don't find the exceptions as helpful as I'm used to when targetting a Windows platform, with IIS, etc. So the development experience is a little muted. Having said that, the ability to debug and single step code that's running on a different platform, and via an emulator truly is staggeringly good. It amazes me every time I think about it.
I do feel that C# is a distant cousin and black sheep of the C family of languages. There's never a question of IF you can run C or C++ somewhere, it is just accepted as such that it is a given. Target your processor, and Make that executable! Because of how .NetCore works, it seems we've the potential to join that family again (a re-union?) and as such, have all the benefits C# touted from day 1, but for many processors and platforms. Woo! But we're coming in at a lower level than Android, and that's the problem, but also the solution, I think. I believe this is why .NetCore has gained a lot of interest from developers outside of the Windows C# full .NET platform developer guys.

Cut down framework? Who remembers the Windows Compact Framework (Windows CF) ?? I think Microsoft learned from that one, so as cut down as .NET Core is, it really is about NOT having the Windows ONLY stuff in there. That's why .NetCore is so limited, but I'm sure you guys already knew that. It gains power from communicating with outside api's. It gains power from its deployment pattern - and it would seem to me that because .NetCore developers are already using, accepting, and wanting more from it - that it should have a healthy future, and indeed perhaps be the key to C# and .Net's future. To that end, I don't think having platform agnostic features is such a bad idea. indeed, C# guys are quite familiar with it. In the first couple of years (think Windows Xp) we were talking about assemblies, Com+ and interop libraries. So when we look at operations like creating windows, and adding buttons (WinForms or WPF) you'll not find the code that draws controls, because it sits in the operating system, and we're just communicating by throwing messages over the walls of our CLR garden / sandbox.
To that end, we come parallel with Xamarin, and where Xamarin comes into the equation. In essence, when we don't know what the UI platform is, and we just talk through something that will wire things up, or make sensible substitutions, we have something of value. (Xamarin). We also know that Xamarin offers us the ability to create platform specific assemblies so the UI elements can have a truly platform specific aimed and targeted experience. Awesome! But the path taken by traditional Xamarin sacrifices performance for convenience, which it would seem to many companies as an acceptable trade-off.
But Xamarin is not alone in what it's trying to do. Google in beginning to push it's own tech for cross-platform (ios/andriod/fuscia) developoment - and guess what language they're not using? Yeah.

For me, C# is the moral high-ground. It's a really good way of describing objects and interactions. It's flavour of OO is very powerful indeed, and doesn't exactly sacrifice performance. Quite often I see really elegant C# code that can achieve a lot with very little, and you have to take a second look. I usually do that after saying "Is that all I need to do?"... For me, C# should be taught in every school, and should be the measuring stick of elegant programming. I'm not saying there isn't room for improvements - there always is. But C# really does seem to walk the fine line, and pleases most developers, most of the time. That's not mentioning the .NET libraries, be it core, or otherwise. So long as we're programming C#, I think we can point a finger in the Java direction, and say "you wish you were this good!". But a word of warning: You can write shit code in any language. I say that a lot to younger developers.

Wrapping it all up then, I think Pinox's diagram makes it clear - we write .Net Core, and hope it will run anywhere. What we want, using interop libraries I guess, for Android. Funny that - doesn't Xamarin have those? Can we use them for .Net Core? I think Pinox would want to see custom written highly optimised code though, for performance reasons. In saying that, Once your C# is running, the chances are, so long as your interactions with the outside world (Android) is limited, I doubt C# performance is really the issue.

[Pinox]

MS Build 2019 - it's great to see that MS is indeed unifying everything into "best of breed" components that will be used by all platforms in the new .NET 5 version. Xamarin for instance will also use highly performant corefx code in the base .NET 5. AOT and JIT standard features in .NET 5. Awesome stuff MS !!

Quote from MS blog :
"All .NET 5 applications will use the CoreFX framework. We will ensure that CoreFX works well in the places it is not used today, which is primarily the Xamarin and client-side Blazor workloads"

If we could only get a React Native type framework now that's using XAML where each platform compiles to their respective native platform then my dream came true =>>> full circle cross platform XAML / c# , native apps on each platform and highly performant code. baby steps I guess ;)

I see MS started a new open source project React Native for Windows , that I think is great but I would also run a parallel project to use the existing React Native project from Facebook. Rip out javascript and put in the glue from .NET5 / CoreFX to React Native without the javascript. To me this look like low hanging fruit or am I missing something here ?

You can even keep the existing react web components then you dont have to touch the GUI part as you can leverage from the existing mature web assets to make this an easier transition. (it's like React Native using .NET by means of WASM)

If MS can use Chromium from Google for the new Edge browser , why not use the existing React Native framework from Facebook and port it for .net developers ?

I know this is in competition to Xamarin but it's another segment of an existing huge market of developers and will make MS even stronger.

[lextm]

@Pinox third party UI frameworks like Uno are on their way to enable XAML based cross platform UI apps, https://platform.uno . There are possibly other options in the near future.

[stephentoub]

Closing given announced direction with .NET 5. Thanks.