I'll be honest, as much as I love the improvements with .NET Core/.NET Standard, Microsoft's branding strategy leaves a lot to be desired.
vNext has already been historically used in the context of ASP.NET to refer to ASP.NET (not to be confused with ASP.NET MVC) v6. We restarted the versioning back with ASP.NET Core, now on version 2. Entity Framework used to be a .NET framework component but is now standalone, and has a Core version? Does Blazor (or is it Razor Components now) share the .NET branding?
Separate to the web stuff, we have the .NET platform - .NET framework is the non-cross platform version for which we're on version 4, but it implements .NET Standard v2 along with .NET Core, which has a Linux runtime. Mono also implements .NET Standard v2 and has a Linux runtime.
I remember many years ago when we also had Microsoft .NET Passport.. which was completely unrelated to everything else that I've mentioned related to the .NET brand.
And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?
> And now we have .NET 5 which is neither Framework nor Core
Just to note, the blog post explicitly says that .NET 5 is the next version of .NET Core. It's where .NET Core is going, and given that so much more of the .NET "picture" is being realized with it, the name is changing to be more reflective of the fact that it's not really a "core" (small) thing anymore.
Yes, indeed. But will that change also apply to the other projects that target .NET Core (now ".NET")? Will Entity Framework Core become Entity Framework and clash with the 'full-fat' Entity Framework? The blog post suggests this won't happen by referencing ASP.NET Core 3.
And where does this leave the legacy .NET Framework? It reads as a sub-project of '.NET' (previously .NET Core) but it very much isn't because it provides a set of older APIs. We seemingly have two meanings for .NET now, referring to .NET Core (which I guess only applies when suffixed with v5+) and the wider array of .NET projects, whatever they are.
Yes, the branding is terrible and has been for some time. It's good that most of it is merging but this is still years away and will create a lot of historical churn in its wake.
Even with the tremendous strides in tooling and docs, the naming and runtime complexity is the biggest hurdle in getting new developers to the ecosystem. Just about every other major stack has a far simpler setup. Even ".NET" is hard to search for.
> And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?
My understanding is .NET 5 is both. Previously .net framework and .net core were both implementations but also api surfaces. And it's my understanding that .Net 5 will basically "implement" both. So .net standard won't be necessary because if all implementations(.net core + mono) implement all the difference api surfaces then you don't need a "common" api surface.
So there will only be two implementations. Mono and .NET core which will provide all the same api surface as .net framework + .net core(and therefore .net standard).
.NET Standard will probably still be necessary due to the fact that Mono will still continue to exist separately thanks to products which embed it (such as Unity).
The first two sentences of the article sum up the announcement and eliminates most of the confusion:
Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.
There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.
I think Microsoft has been guilty of what you say in the past but this announcement and their product offering going forward could not be more clear.
It is quite confusing and misleading to say "There will be just one .NET going forward" since this will not affect the .net framework at all - there will still be two incompatible platforms (4.8 and 5/core) for the foreseeable future. They just changed the name of one of them.
I think the problem with MS is they want a simple name change to look like some new unifying strategy. Developers would be much happier if they just cut out the bullshit and made it clear this is just a name change of .net core. The name change in itself is fine.
MS is just FUD'ing themselves with these confusing messages.
As I have gathered from talking to former Microsoft developers and evangelists, vNext is generally embraced to mean "the next great version", maybe primarily for developer centric stuff.
Personally, I've been hearing about MS Build vNext and TFS vNext for the last 8 years, and there's been several releases since then. Maybe that's why I kind of associate it with vaporware, even though that's probably unfair.
What would be a great naming schemes for retro fitting an open standard with a new, open implementation for a subset of the existing framework?
To draw an analogy to Debian, vNext is somewhat similar to Sid. The name is a moving pointer. In a Microsoft context, there is not an unstable connotation like Debian's Sid is.
vNext is a term used across much of the Microsoft ecosystem to denote the current WIP version of a specific technology. SQL Server vNext has pointed variously at what became the 2017 release and currently points at the 2019 release (and will soon point to the next release after that).
Excellent recall--I had almost entirely forgotten about ".NET Passport," one of Microsoft's many premature plays at being an identity provider. This certainly added to confusion at the time about .NET's actual form... something to do with XML, or web services? And an awkward new ORM that will definitely not become well-loathed in near-record time?
Given the embracing of other platgforms, and the convergance aspect of one .NET to rule them all. WHy they didn't rebrand it is a mistake they will probably end up doing if they want to pull in dev's on other platforms. Many who's exposure to .NET will be of a legacy flavour and maybe left a sour taste. A taste that will stick with them upon anything .NET.
I'd vote for .ONE, one API to rule them all.
Though convoluted does sell books, I'm sure we will see a title "When is .NET not .NET" soon.
"There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more."
This is remarkable, and impossible to predict from the Microsoft of 10 or 20 years ago. Satya seems to be the rare visionary CEO of a megacorp, instead of just defaulting to a defensive and reactionary stance like most other leaders.
My guess is that it's also at least partially reflective of how .NET's status at Microsoft has changed over the past two decades.
Remember 20 years ago, when .NET wasn't just a managed software development platform? It was a company-wide strategy[1] that was meant to encompass more-or-less their entire product line. The whole Microsoft future was .NET, and they were going to have a .NET edition of Windows, SQL Server, Exchange, etc.
Since then, those plans have been dropped, Microsoft's (.NET-based) preferred GUI toolkits, WinForms and WPF, were replaced by one that is .NET-compatible but not .NET-native, etc. etc. .NET just isn't as central to Microsoft's identity as it was 20 years ago.
Which, I'm guessing, means that the .NET team is now a lot freer to go cross-platform without inviting the wrath of the Windows team.
He understand that Microsoft is a software company, and makes money selling software and software services. Steve Ballmer, for all his good attributes, was stuck seeing Microsoft as a Windows company, thinking everything had to relate back to Windows. Nadella understand that companies change or die. Ballmer just thought that meant finding new places to shove Windows.
I'm pretty skeptical of all the Microsoft praise lately, but if this is indeed true, it's a big deal. And probably a management feat somewhere (CEO or otherwise).
I worked on dev tools at Google and recall many efforts over the years to try to unify the customer experience -- between internal and external tools, Go and Dart, Android and Chrome devtools, etc. Things always lurched in one direction or another, but never consistently. It was always above someone's pay grade to choose one or the other, so you ended up with both.
Convincing engineers on devtools to abandon their babies is indeed hard!
On the other hand, I think if you dig deep, Microsoft still has all the legacy, but they cover it up with a lot of branding. Hence the top comment in this thread about confusing branding.
Older execs probably had to be defensive and reactionary because they had to protect their main source of income, Windows.
But it's clear now that 1) Windows has zero chance of taking a significant market share away from Linux in the cloud and 2) cloud technology is an important area of growth for MS.
Satya probably sees that stubbornly sticking to Windows just isn't going to work anymore, so it's better to play nice with the others.
What? Satya didn't invent .Net. The idea of .Net, like the JRE, was to write once and run everywhere. What's visionary about it?
It's sad how so many articles and comments come off just pure PR now. Not saying your comment is, but I have to wonder how much of the "news", comments and internet content is now just PR.
I don't know about that. I thought I kind of understood the mess of the .net framework until now but now I am really lost.
Like asp.net core was meant to be incompatible with .net full framework because of inconsistent featureset, is that going away? For applications, .Net core binaries are different from .net full binaries, they compile to a .dll, not an executable .exe, you have to run them with a command line (and if you choose the option to create an exe it comes with lots of additional binaries that aren't required in full .net framework, plus I understand some additional problems of version compatibility with the installed .net framework). So is .net 5 going to be one or the other? Or is .net 5 just another way of saying that they are discontinuing the full .net framework and that now everything will have to be .net core? But then is a simple full .net framework 4.7.1 .exe run on .net 5?
WPF will still be Windows exclusive, though. Like many other things. What they really mean is BCL+Runtime+Compiler, and not .NET (read as: the whole ecosystem).
> how I can build a minimal app that works on all those platforms
That's perfectly normal.
There is no such thing as "Cross Platform .NET"
The C# language and the.NET Framework does indeed run on almost all platforms, but that pretty much ends here in terms of "portability".
Anything beyond that is "platform specific"
For instance, building "desktop" applications is either UWP with advanced styling and reactive data binding but only for Windows or GTK# with Mono which is very limited.
For Mobile either Xamarins.Forms for Android + iOS but it's very limited in terms of features, or it's Xamarin.iOS + Xamarin.Android which require platform specific code for UI / Routing and many others OS specific functions.
For Web , the WASM Binary is something like 5MB+ which makes it not reasonable compared to an app written in Plain JavaScript or TypeScript.
There is still a long way to go for C# to be really "cross platform"
Yeah, I'm seriously still dumbfounded by this. I mean, it's such a positive, future-aware decision, it's confounding. Impossible to say how relevant .NET it will be in, say, 4 years time, but development will certainly be much better than today when you have several disparate runtimes to target depending on the platform.
I have extensive XP with .NET Core 2 in production on huge services with 1M+ users - we started making some stuff before 1.0 and had it in production after having few sessions with local MS.
WebAPI, APS.NET Core, Pwsh, C# 7... I dont work for MS, but that is some seriously good tech stack. Performance is amazing too. I highly recommend it. Worked in 50+ environments so far but this is top stuff. MS really nailed it this time. No, don't tell me that JAVA is comparable to C# in elegance, that linux dudes had python/ruby/perl/whatever before Powershell etc.
The only problem we had so far was with the Oracle db drivers which were non existent until several months back, but that is on Oracle... which sux more and more each day - commercializing java for example will just give a boost to .NET now, a lot of it - who at Oracle made up such decision escapes me, but maybe he works for MS.
I have a project in the early design phase that I was thinking of going with .Net Core on Linux. I've thought about going with Java, but with all the recent Java licensing changes don't think I want to go that route anymore.
I currently run on Windows servers, some of which are Core. Tried nano but its terrible as there is no package manager and no support for msi files. If you install anything in docker it takes GB's so we used VM's for bakcend/frontend running Windows Server 2016 behind IIS/kestrel/nginx and every other supporting tech on Linux (not core). One of the reasons to use Windows was Sql Server but mostly PowerShell which we do all automation in. Backend service is used to register invoices for entire country and it has 1M+ users, we have 60-100 logins per minute and 500+ concurent actions. Backend is served by single server (!) and never gets more then 10% CPU load and 20% memory with that load. I am amazed honestly. Zero dev fucktitude (once we ditched Angular, but that is another story). Almost zero downtime (30-50s to build and deploy with db migrations).
Now, we use Linux alpine docker containers, use postgre instead Sql Server and pwsh with Invoke-Build to run CI/CD stuff. Sworm for orchestrations and compose for local.
Have 2 incoming country-level services this year for production. Currently on dev/stage it works really fast but load is trivial.
We did a lot of performance test on Windows and achieved 1.5-2K req/s with hello world and our setup on IIS/kestrel. Did no test for linux variant so far.
> I've thought about going with Java,
Java compared to latest C# is like ... Clojure to VBA. No brainner really, plus Oracle (sure, there are alternatives).
Also, entire Java enterprise stack is overengineered beyond repair. I need 77 classes for basic stuff. Take .NET core you wont regret it.
Today there is an Oracle driver for .NET Core, BUT this fucking driver doesn't support async/await calls!!! To archive the max performance .NET Core has to offer, you do have to use async/await all the way from the coming request to the database calls. With Oracle databases, it is not possible yet.
I am very pleased with the direction Microsoft has been moving the last few years. Every release of .Net has incrementally made our lives easier.
We are already on top of .Net Standard/Core 2.0 and are building successfully against 3.0 prerelease targets without modification. I would anticipate the move from Core 3.0 to .NET 5.0 would be trivial for us, and as long as self-contained deployments are still around in 2020 our build & publish pipeline won't know the difference (aside from msbuild & SDK updates on Jenkins).
So, does this also replace/update the .NET Framework that is bundled with Windows 10, meaning that you can release a .NET EXE and ask people to use the latest version of the .NET like you can release a .JAR and you can ask people to have the latest version of Java, or you have to bundle the entire runtime (be it via a fat compiled AOT or regular bundling) with your application?
I ask because one of the positive things about .NET Framework 4 is that i can create a tiny .EXE and give it away and expect that people will have the runtime to run it since it is already part of Windows.
>You can now publish a single-file executable with `dotnet publish`. This form of single EXE is effectively a self-extracting executable. It contains all dependencies, including native dependencies, as resources. At startup, it copies all dependencies to a temp directory, and loads them for there. It only needs to unpack dependencies once. After that, startup is fast, without any penalty.
This is for .NET Core 3, not for .NET 5. While .NET 5 might provide the same tool, it doesn't answer if it will also provide a .NET Framework 4-like functionality where the .EXE relies on a runtime already installed on the user's system and if that framework will be something the developer will need to provide and/or be part of Windows 10 like .NET Framework 4.
I don’t get it. How can one executable even know how to bootstrap itself enough to know how to run a self extracting archive across Windows,MacOS,Linux?
I understand how MS did it in the past with DOS/Windows and how Apple has done it between the 68K/PPC/Intel transitions.
Yes but will this 'required runtime provided by the system' be part of Windows like it is with .NET Framework 4 (that is also updated automatically via Windows updates) or something that the user will have to go out of their way to install like Java?
In many cases, this is the crucial difference between deciding to bundle the runtime yourself or not.
The F# repl (FSI as fsharp interactive) works in .net core 3.0 preview already, you can do `dotnet fsi` to run it
Type providers works in general, but depends if the type provider library was updated to use latest type provider sdk.
Also generative type provider may not works, erasing works
Enrico answered to question w.r.t where F# is now, but F# is going to also be a big part of .NET 5. The only reason it's not mentioned in the post is that we haven't firmly decided on if the F# release that corresponds with .NET 5 will version in lockstep like C# is planned to do.
I was really excited to see this; finally a consolidated .NET. Then I read this...
Taken together, the .NET Core and Mono runtimes have a lot of similarities (they are both .NET runtimes after all) but also valuable unique capabilities. It makes sense to make it possible to pick the runtime experience you want. We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.
Mono is a large part of mobile and Unity for gaming. It's not going to disappear anytime soon and they can't go back to it being completely separate. This is the best compromise to keep the runtimes the same but share as much as possible between them.
There are not really any yet. We intend to take the Java interop that Mono already supports, improve it as needed, and make it available to other scenarios beyond just Android. If there are certain things you would like to see, I'd love to know.
I'll read up on how Mono handles it. I've never done too much .NET and I'm a recovering JVM dev, I was just asking out of curiosity since that is a pretty thorny feature to tackle. I can think of a number of dangers/shortcomings with any approach I can think of.
I would like to know more too. Not being able to call java libraries is one of the biggest problems with .NET. There are a ton of java libraries that don’t have good .NET equivalents.
If only they could just add a very easy way to invoke functions (at least those with simple interfaces, i.e. taking just simple value types as inputs and returning a simple value type) from other languages (incl. Java and Python) this would already be a huge value boost even if performance would be not perfect.
Well, if you can get a C-compatible pointer to those functions you're already ready to go, and the inverse is true if those languages can consume C-compatible function pointers.
So from python you could probably flex to use ctypes, and from java, JNI. Naturally this is a bit awkward but I expect the mono binding tools would help smooth it over for Java (I have no idea about Python there.)
Readit News
vNext has already been historically used in the context of ASP.NET to refer to ASP.NET (not to be confused with ASP.NET MVC) v6. We restarted the versioning back with ASP.NET Core, now on version 2. Entity Framework used to be a .NET framework component but is now standalone, and has a Core version? Does Blazor (or is it Razor Components now) share the .NET branding?
Separate to the web stuff, we have the .NET platform - .NET framework is the non-cross platform version for which we're on version 4, but it implements .NET Standard v2 along with .NET Core, which has a Linux runtime. Mono also implements .NET Standard v2 and has a Linux runtime.
I remember many years ago when we also had Microsoft .NET Passport.. which was completely unrelated to everything else that I've mentioned related to the .NET brand.
And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?
Just to note, the blog post explicitly says that .NET 5 is the next version of .NET Core. It's where .NET Core is going, and given that so much more of the .NET "picture" is being realized with it, the name is changing to be more reflective of the fact that it's not really a "core" (small) thing anymore.
And where does this leave the legacy .NET Framework? It reads as a sub-project of '.NET' (previously .NET Core) but it very much isn't because it provides a set of older APIs. We seemingly have two meanings for .NET now, referring to .NET Core (which I guess only applies when suffixed with v5+) and the wider array of .NET projects, whatever they are.
"We aren't ending full framework, we have .NET 5!"
If you are developing new apps in full framework, you are doing it wrong.
Even with the tremendous strides in tooling and docs, the naming and runtime complexity is the biggest hurdle in getting new developers to the ecosystem. Just about every other major stack has a far simpler setup. Even ".NET" is hard to search for.
Not to mention the fact that the whole thing was named after an experience that to me at least has always meant "Shoot, .com isn't available!"
My understanding is .NET 5 is both. Previously .net framework and .net core were both implementations but also api surfaces. And it's my understanding that .Net 5 will basically "implement" both. So .net standard won't be necessary because if all implementations(.net core + mono) implement all the difference api surfaces then you don't need a "common" api surface.
So there will only be two implementations. Mono and .NET core which will provide all the same api surface as .net framework + .net core(and therefore .net standard).
Deleted Comment
Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.
There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.
I think Microsoft has been guilty of what you say in the past but this announcement and their product offering going forward could not be more clear.
I think the problem with MS is they want a simple name change to look like some new unifying strategy. Developers would be much happier if they just cut out the bullshit and made it clear this is just a name change of .net core. The name change in itself is fine.
MS is just FUD'ing themselves with these confusing messages.
Personally, I've been hearing about MS Build vNext and TFS vNext for the last 8 years, and there's been several releases since then. Maybe that's why I kind of associate it with vaporware, even though that's probably unfair.
What would be a great naming schemes for retro fitting an open standard with a new, open implementation for a subset of the existing framework?
But yeah, it got a little crazy with divergent visions there.
vNext is a term used across much of the Microsoft ecosystem to denote the current WIP version of a specific technology. SQL Server vNext has pointed variously at what became the 2017 release and currently points at the 2019 release (and will soon point to the next release after that).
On the bright side unifying products and libraries and stuff will mean it doesn't have to confuse me anymore (:
I'd vote for .ONE, one API to rule them all.
Though convoluted does sell books, I'm sure we will see a title "When is .NET not .NET" soon.
Yeah, that's easy to search for!
/end sarcasm
Remember 20 years ago, when .NET wasn't just a managed software development platform? It was a company-wide strategy[1] that was meant to encompass more-or-less their entire product line. The whole Microsoft future was .NET, and they were going to have a .NET edition of Windows, SQL Server, Exchange, etc.
Since then, those plans have been dropped, Microsoft's (.NET-based) preferred GUI toolkits, WinForms and WPF, were replaced by one that is .NET-compatible but not .NET-native, etc. etc. .NET just isn't as central to Microsoft's identity as it was 20 years ago.
Which, I'm guessing, means that the .NET team is now a lot freer to go cross-platform without inviting the wrath of the Windows team.
[1]: https://en.wikipedia.org/wiki/Microsoft_.NET_strategy
I worked on dev tools at Google and recall many efforts over the years to try to unify the customer experience -- between internal and external tools, Go and Dart, Android and Chrome devtools, etc. Things always lurched in one direction or another, but never consistently. It was always above someone's pay grade to choose one or the other, so you ended up with both.
Convincing engineers on devtools to abandon their babies is indeed hard!
On the other hand, I think if you dig deep, Microsoft still has all the legacy, but they cover it up with a lot of branding. Hence the top comment in this thread about confusing branding.
But it's clear now that 1) Windows has zero chance of taking a significant market share away from Linux in the cloud and 2) cloud technology is an important area of growth for MS.
Satya probably sees that stubbornly sticking to Windows just isn't going to work anymore, so it's better to play nice with the others.
Office for Linux would be easy, but that’s not going to happen.
My companies online outlook shows that MS is adding clones of all the tools (slack/trello).
They’ve been successful and monitizing in this new era
- Netflix - moved from delivering discs to streaming and moved their entire infrastructure to AWS and CDNs
- Amazon - went from just being a first party retailer to being a marketplace, AWS, and Alexa.
- Apple - as of last quarter all five of their major verticals are large enough to be a F200 company by itself.
- Facebook -- Instagram and WhatsApp were acquisitions but it didn't ruin either and they are both larger than they would have been.
- Google -- well still just a one trick pony - search ads (as far as profits) no matter how many things they against a wall.
It's sad how so many articles and comments come off just pure PR now. Not saying your comment is, but I have to wonder how much of the "news", comments and internet content is now just PR.
Like asp.net core was meant to be incompatible with .net full framework because of inconsistent featureset, is that going away? For applications, .Net core binaries are different from .net full binaries, they compile to a .dll, not an executable .exe, you have to run them with a command line (and if you choose the option to create an exe it comes with lots of additional binaries that aren't required in full .net framework, plus I understand some additional problems of version compatibility with the installed .net framework). So is .net 5 going to be one or the other? Or is .net 5 just another way of saying that they are discontinuing the full .net framework and that now everything will have to be .net core? But then is a simple full .net framework 4.7.1 .exe run on .net 5?
They are achieving this by bringing Mono more "in-the-fold", making it interchangeable with CoreCLR, and ensuring CoreFX runs on every runtime.
It seems that are leaning on Mono because of it's AOT abilities, which doesn't say good things about the future for CoreRT.
I like the idea of using Mono though, it's easier to embed in native applications.
I tried about 5 searches but didn't find anything useful so far.
That's perfectly normal.
There is no such thing as "Cross Platform .NET"
The C# language and the.NET Framework does indeed run on almost all platforms, but that pretty much ends here in terms of "portability".
Anything beyond that is "platform specific"
For instance, building "desktop" applications is either UWP with advanced styling and reactive data binding but only for Windows or GTK# with Mono which is very limited.
For Mobile either Xamarins.Forms for Android + iOS but it's very limited in terms of features, or it's Xamarin.iOS + Xamarin.Android which require platform specific code for UI / Routing and many others OS specific functions.
For Web , the WASM Binary is something like 5MB+ which makes it not reasonable compared to an app written in Plain JavaScript or TypeScript.
There is still a long way to go for C# to be really "cross platform"
WebAPI, APS.NET Core, Pwsh, C# 7... I dont work for MS, but that is some seriously good tech stack. Performance is amazing too. I highly recommend it. Worked in 50+ environments so far but this is top stuff. MS really nailed it this time. No, don't tell me that JAVA is comparable to C# in elegance, that linux dudes had python/ruby/perl/whatever before Powershell etc.
The only problem we had so far was with the Oracle db drivers which were non existent until several months back, but that is on Oracle... which sux more and more each day - commercializing java for example will just give a boost to .NET now, a lot of it - who at Oracle made up such decision escapes me, but maybe he works for MS.
I have a project in the early design phase that I was thinking of going with .Net Core on Linux. I've thought about going with Java, but with all the recent Java licensing changes don't think I want to go that route anymore.
Now, we use Linux alpine docker containers, use postgre instead Sql Server and pwsh with Invoke-Build to run CI/CD stuff. Sworm for orchestrations and compose for local. Have 2 incoming country-level services this year for production. Currently on dev/stage it works really fast but load is trivial.
We did a lot of performance test on Windows and achieved 1.5-2K req/s with hello world and our setup on IIS/kestrel. Did no test for linux variant so far.
> I've thought about going with Java,
Java compared to latest C# is like ... Clojure to VBA. No brainner really, plus Oracle (sure, there are alternatives).
Also, entire Java enterprise stack is overengineered beyond repair. I need 77 classes for basic stuff. Take .NET core you wont regret it.
That being said, both .NET and the JVM are great platforms. You'll have to evaluate both platforms and see which one benefits your project more.
We are already on top of .Net Standard/Core 2.0 and are building successfully against 3.0 prerelease targets without modification. I would anticipate the move from Core 3.0 to .NET 5.0 would be trivial for us, and as long as self-contained deployments are still around in 2020 our build & publish pipeline won't know the difference (aside from msbuild & SDK updates on Jenkins).
Exciting times ahead.
I ask because one of the positive things about .NET Framework 4 is that i can create a tiny .EXE and give it away and expect that people will have the runtime to run it since it is already part of Windows.
>You can now publish a single-file executable with `dotnet publish`. This form of single EXE is effectively a self-extracting executable. It contains all dependencies, including native dependencies, as resources. At startup, it copies all dependencies to a temp directory, and loads them for there. It only needs to unpack dependencies once. After that, startup is fast, without any penalty.
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-...
I understand how MS did it in the past with DOS/Windows and how Apple has done it between the 68K/PPC/Intel transitions.
In many cases, this is the crucial difference between deciding to bundle the runtime yourself or not.
Type providers works in general, but depends if the type provider library was updated to use latest type provider sdk. Also generative type provider may not works, erasing works
`dotnet fsi` is planned to be fully released later this year with the .NET Core 3.0 release.
Taken together, the .NET Core and Mono runtimes have a lot of similarities (they are both .NET runtimes after all) but also valuable unique capabilities. It makes sense to make it possible to pick the runtime experience you want. We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.
Where can I find more details on this?
So from python you could probably flex to use ctypes, and from java, JNI. Naturally this is a bit awkward but I expect the mono binding tools would help smooth it over for Java (I have no idea about Python there.)