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.
EDIT: more on this here https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0...
> There will be just one .NET going forward
> Additionally, we wanted to clearly communicate that .NET 5 is the future for the .NET platform.
If "one isn't going to be developed anymore" there there will be just one framework.
"Being" here means what's the official worked-on implementation. Not merely existing, obviously the code for 4.8 wont go anywhere, nor will existing deployments suddenly vanish.
I took "forever" to mean that they would still be issuing security patches to 4.8, for example. Given all that I don't know why you're insisting on phrasing it like that. There is only one future, sure. But you seem to be making it sound like 4.8 has a planned obsolescence date or something and Microsoft is saying the exact opposite.
Maybe a better analogy is that .NET Framework 1.x and .NET Framework 2-4.x are side-by-side installed still in Windows 10. If you wanted you could still target .NET 1.0 and it will run in an entirely different runtime (.NET 1.x and 2.x are hugely different). .NET was designed for that sort of side-by-side deployment, they just haven't done it in a while.
Yet I've not met a developer that still sees .NET 1.x as a viable Framework recently. Do you want .NET 4.8 applications to just break? What do you expect here? The "current framework" is always a combination of marketing and support and this article seems pretty clear that all marketing and support effort will be on .NET 5, and .NET 4.8 is "done".
That's not true at all. You can run any version of the framework side-by-side all the way back.
You can have .NET 2 or whatever older on the same machine too.
Doesn't change the fact that .NET 5 will be the single official .NET release onwards, where development efforts will be concentrated, etc. It's not like MS will support 2 different frameworks (except one as a legacy release).
Yes, some of those items are legacy, but not everyone enjoys paying to rewrite stuff from scratch.
I suppose their rationale is damage control ("Okay, they get the server, but the desktop is still firmly ours"), but it would certainly keep me from starting a personal project with a Microsoft Framework.
At this point I'm guessing that it's because there isn't a strong future for desktop apps written in native code. Even VSCode is written on top of Electron. Good, bad, or indifferent I think that there isn't a lot of point in developing a native GUI framework at this point.
(To be clear - I'm 100% sure that there are a lot of use cases that I'm blithely waving away, but I'm also sure that those use cases are currently being addressed with WinForms, Qt, GNOME, etc, etc, so why should MS invest in Yet Another GUI Framework?)
I also tend to agree that for good, or bad, that Electron will probably grow significantly as an application base. Like I see node becoming the defacto runtime for WebAssembly, I see Electron taking that place for WebAssembly + UI. And I don't think it's all that bad.
Even with MS, Electron seems to be their unified UI target for a lot of apps. VS Code, Teams, Azure SQL Studio (or whatever the name is now), and don't see that space shrinking. I'm only surprised that Teams doesn't have an official Linux version.
So it would make sense if they're pushing .Net Core to be cross-platform, that they want to eventually push the Microsoft App Store "buy" button to be cross-platform as well, with a GUI framework to support those apps. Speculation, but .. of course they will want to.
I don't want to be the one stating on RFP "it kind of works".
"Both .NET Framework and .NET Core will move forward, and both will be fully supported"
Which is why I found this one confusing... because it essentially says the opposite.
"We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes."
"We aren't ending full framework, we have .NET 5!"
If you are developing new apps in full framework, you are doing it wrong.
Thankfully, they finally got around to adding support in .NET 3.0 (https://www.strathweb.com/2019/01/collectible-assemblies-in-...).
Unless there is a newer version than last month, one of those is the Bot Framework extensions for Microsoft Teams, which they are just slamming ahead with.
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).
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.
Well, everything will move to 5. And the framework at 4.8 will stop being developed. And 5 ( Core, whatever you want to call it, ) is incompatible with the .Net 4.8.
How misleading is it?
Not likely. Many libraries (like web forms) will probably never be migrated. We will have two incompatible .net's for the foreseeable future. Changing a name does not change that.
I'm genuinely confused because the illustration shows .net standard as a layer between .net 5 and various platforms. But if that is the case, the platforms will not be able to take advantage of newer features, since .net standard is the API shared with .net 4.8. This does not seem likely.
After .NET Core 3.0, MS said new features will only be added in Core. And when they reach .NET 5, Standard and Core will be identical, with "Standard" being the library you link to regardless which specific .NET implementation you're running on: desktop, IoT, mobile, etc. I believe the diagram only means that "Standard" covers all of .NET 5, not some subset of Core. And .NET Framework is a separate, maintained legacy library off to the side.
Note, I don't work for Microsoft, this is just my understanding from reading their docs and talking with them about it online and at MS Build.
.NET Standard will be only one thing, if they end up retaining the name at all. It will be the the interface to everything in .NET 5. .NET Framework will just be its own thing maintained only for legacy compatibility. After .NET Core 3.0, new development will not be added to .NET Framework.
I do agree with you that it would be clearer if they only spoke of .NET 5 and .NET 4.8 Framework versions.
In the real world there are massive amounts of code in the .net framework. Because of the significant breaking changes between 4.x and core/5 it will take a long time before all this code is ported, and many application will probably never be ported, while still having to be maintained. So for the foreseeable future it is going to be very important whether libraries are 4.x compatible or not.
Consider Python had (IMHO) fewer breaking changes between 2 and 3, but still the migration took about a decade.
Right, I agree with everything you said here. That's exactly the reason why MS said at the Build conference that they will be supporting .NET Framework "forever". There is a lot of it out there and it will likely remain for a very long time.
When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away. There will be .NET 4.8 in maintenance mode and .NET 5 as the future, growth mode. Maintaining .NET Framework apps hopefully won't be a problem but if you're thinking of building a new app using .NET 4.8, you're likely making a big mistake unless it's to satisfy some immediate need that doesn't work on .NET Core. MS said they're committed to supporting people stuck in that position. Just don't expect new features that will appear in future .NET versions.
I'm really struggling to understand this. Can you explain how you would prepare to port a .net 4.x site to core/5, if the notion of a compatible intersection goes away? How would you even make a library which is compatible with both 4.x and 5?
This is pretty much like every other porting project where you have an old neglected project that you want to bring up to date. Maybe there is an easier way but I don't know what it is. Staying on the legacy .NET Framework isn't the end of the world, you're just committing to maintaining it as is. If you want new features as they become available, well... that's on you, don't wait.
Maybe you move some functionality out of your legacy GUI app to microservices written in .NET 5, parts that are unlikely to have any porting issues. In any case it's not like anyone is going to be surprised by what's going on. Maybe the community will back port some new things to .NET 4.8. MS will be devoting their efforts to enhancing the new platform while keeping the old one on life support. I think that's reasonable. (edit: typos)
Saying .net 5 is unifying .net is like saying Python 3 unified Python or that Angular 2 unified Angular.
> If you haven't been keeping the app up to date, say you're on 4.6.1,
Again, why the dishonest arguing? 4.6.1 is years old, but you will have exactly the same problem if you are on 4.8 which was just released. It has nothing to do with code not being updated.
> where you have an old neglected project that you want to bring up to date
Again, this has nothing to do with projects being old and neglected. It is a breaking change, it will affect all projects on .net framework if they want to upgrade. And you know that.
The plan for .NET 5 does, in fact, unify .NET Standard, Core and Xamarin. These will no longer be separate things but will go forward under one name.
I'm not sure what you're claiming as the _breaking change_. Can you be specific? It's not, in fact, going to break anything from what I can see. .NET Standard will simply continue to grow larger in .NET Core 3+ until it covers everything. This seems to me to be very different from the Python situation where you are (probably) forced to make code changes to compile with Python 3. If I have some code that compiles with .NET Standard 2.0, are you under the impression that it won't compile with .NET Core 3+ or .NET 5? If so, what leads you to think that?
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!
Remember 20 years ago, when .NET wasn't just a managed software development platform? It was a company-wide strategy 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.
There is not much of Windows team to wield the wrath:
Read towards the end.
This spawned a lot of interesting academic work that influenced languages such as Rust... trying to get high level features and safety without need for a runtime.
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
I have a hard time believing it would be easy. I use both Office for Windows and Mac, and the differences are great enough that I'm guessing that there's a huge amount of divergent code in the UIs. And both would be written against GUI toolkits that are not present on Linux, so a Linux port would be yet another major effort.
That said, I think that you're right that it's not going to happen. My understanding is that a major consideration for anyone looking to port a commercial desktop product to Linux is that Linux desktop users are, in the broad, very hesitant to spend $100s on a commercial product when open source alternatives exist. My guess would be that a Linux port of Office just isn't a proposition that is likely to generate positive profits.
But "Desktop Linux" will always be a million support headaches for no market share; which begs the question "Dear Lord, why?"
The only part of "Office" I really even use though is Outlook (at work), and it's pretty good at the job it does.
The actual problem is the lack of Group Policy support (or even a viable equivalent - preferably one that's cross-platform).
Enterprises don't just use free OSS software like that. They'll use Redhat or some other corporate-backed variant, and in the end the license cost will be the same but most software and drivers don't work, users will need to be retrained, and support costs will rise dramatically. They can't even use .NET to build any internal desktop apps either.
It's a terrible deal.
I tried some googling but the results seems to be all speculation. Is this really happening?
I thought they published an article that explicitly mentions RN but I can't find it at the moment. MS has also been heavily working on RN for Windows including a C++ bridge that significantly increases the performance of the JS to native bridge.
Surely they could make it performant in the default mode that everybody uses now that it’s 2019 and we have megahertz to spare? There is no excuse for Word’s atrocious performance.
The problem with page layout mode is that any non-trivial format change, insertion, or deletion requires repagination and the UI freezes until that is completed. Draft mode repaginates asynchronously so that it remains responsive. Comparing a WYSIWYG editor to a plain text editor is no contest as the former performs much more work to layout the text.
Painfully (and randomly shifting) inaccurate in print layout on documents that involve more than just text, sure, I see that every day.
For 95% of business users, these online editions have all the capabilities they need without the install headache and are much easier to maintain and update. Office Desktop just had a refresh too but there's basically 0% Linux business users to spend the millions in development costs for a variant.
I haven't used Office in years and don't know anyone who has, so I'm not sure how big of a priority it is to add platforms to a product like that.
Arguably a large part of the reason that Linux isn't used in offices is because MS Office isn't available. Of course it's in Microsoft's interest to keep it that way.
She didn't have to know anything about linux to use it. The same is true for a lot of people. More so in a corporate environment with dedicated staff to handle the harder problems. Hell, most people in offices could get away with a Chromebook and Office 365 today.
Of course, general use laptops and proper linux support are not things that are very common. That part truly sucks. And, yeah, it's not pre-installed for the most part except for some boutique vendors and a couple Dell offerings.
Have had a few looks at System 76 lately. May change out my mid-2014 rmbp next year. Unfortunately it's one of the last systems with NVidia, and the metal 2 support for the 750M doesn't work well at all. I'm also probably going to change my desktop to Linux in a few months. Hackintosh support is all but going away, and although I could change out my GTX 1080 with a next gen Navi for hackintosh, but I just don't want to support the mac platform anymore, and my 1080 has a lot of life left in it.
It only really breaks if you want to customise it (or your hardware is badly supported).
They have the right idea today, embrace server-side Linux with .Net Core, and soon, .Net 5. That's what Linux is primarily intended for, it's a server kernel and where the action is in regards to that ecosystem. There's a reason some of the code in X11 hasn't been touched in 20 years.
- 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.
If you mean .NET Core as official open source, that's true, but it's a relatively recent thing.
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?
Just to add to the confusion, you can target an ASP.Net Core Application to run using .Net Framework.
When re-reading the article, I think what they are implying is that they are ceasing support for .net full framework and just renaming .net core ".net". If it is the case it is kind of a big deal, there is ton of .net full code outthere, that no one has any appetite to convert. If it is not the case, are they going to rename .net full to something else?
This article does the opposite of solving any confusion.
 there is a session in a couple of hours at Build, perhaps it will add clarity: https://mybuild.techcommunity.microsoft.com/sessions/77031#t...
Moving projects from .Net Framework to .Net 5 should be as easy or hard as it was to go from Framework to Core. In my case, this isn't a problem for the current project that I'm working on, but thankfully Microsoft will support .Net Framework 4.8 in maintenance mode for a very long time.
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'm personally happy to see more of the .NET Core stuff end up in Mono since it usually is battle tested and has better compatibility, and I'm also happy to see more stuff approximating the existing .NET Framework and Mono workflows since .NET Core has historically been unable to do important things that netframework and mono can do.
bias disclosure: I work on Mono
Which you can use .NET Core with!
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.
There is still a long way to go for C# to be really "cross platform"
IMO, that's not entirely accurate, and does .NET a bit of a dis-service.
.NET Framework isn't cross-platform, and doesn't pretend to be - it's Windows only.
.NET Core is cross-platform, with runtimes for Windows, Linux and MacOS.
Regarding Xamarin, I guess you haven't used it for a while? Until very recently, I had the same opinion, but only because it was years since I had used it - turns out it's rather good now!
Where cross-platform ends is really with desktop GUIs - web apps, web APIs, console apps, backend processing services/daemons etc, all of these work very well across the supported platforms, and the only time you'll likely write platform-specific code is the rare cases when you need to pinvoke into native DLLs.
Aside from the likes of Electron, I'm not sure there really is a good cross-platform solution for desktop GUIs. Microsoft would be hailed as heros if they ever crack that one :)
And Java is fine, for varying definitions of "fine". I have yet to see any Java application that looks good, aside from a couple IDEs, and none that look good across platforms.
Microsoft used to follow the eat-your-own-dogfood rule, which would seem to indicate that the development tools should use the same run-time and run on all the targets, but the announcement only mentions linux as a target. As a hobby-only-on-linux-only developer who does not buy or sell any software or related services, I find this announcement a poke in the nose with a clue stick.
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.
I've found that .Net Core on Linux and in Windows are close enough that scaling should be the bigger concern. Unless you're tethered to windows, the broader tooling is much more mature with Linux containers/pods.
On the Java side though there is a hack in JRE which checks if JVM runs inside a Docker container in order to not get out of memory limit by cgroup.
Of course for now you always have the option of enabling desktop GC instead
With so much experience you must know how this sounds to someone not in the .net space.
You and your company are clearly well versed in .net and it's worked out for you -- take a person and a company equally experienced in Java and they'd achieve similar results (I have, companies I've worked at have). The systems you're describing are not extraordinarily large scale systems. You've failed to outline the gains here vs. another tech stack.
For example, this is the one about Chocolatey that I gave at Microsoft event few years back (other are similar, but all on Serbian ATM since I mostly do consulting locally and involve everything from Gitlab over InfluxDb over PowerShell to obscure languages such as Autohotkey):
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.
> Starting with .NET Core 2.2, you can deploy your app as an FDE, along with any required third-party dependencies. Your app will use the version of .NET Core that's installed on the target system.
> Your app can be run by calling the published executable without invoking the dotnet utility directly.
> The term is based on the perceived process of harvesting fruit, such as cherries. The picker would be expected to only select the ripest and healthiest fruits. An observer who only sees the selected fruit may thus wrongly conclude that most, or even all, of the tree's fruit is in a likewise good condition. This can also give a false impression of the quality of the fruit (since it is only a sample and is not a representative sample).
I understand how MS did it in the past with DOS/Windows and how Apple has done it between the 68K/PPC/Intel transitions.
They seem to implying that you can create one executable that you can distribute and it will be able to extract the needed parts on any supported platform.
And as much as people complain about Microsoft's messaging with respect to .Net, there isn't really a simple way to explain any of this -- even to people who are deep into the .Net ecosystem. I feel their pain.'
In many cases, this is the crucial difference between deciding to bundle the runtime yourself or not.
Typically the solution for this is to either sense what's installed (and use an installer) or just ship it and let the error messages help them figure out what to do.
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.)
If I were developing a program language and sought to attract more people I would consider seamless invocation of code written in other languages a strategic height.
And does this explain why they don't seem to care about making .NET Standard versions at all logical to developers (e.g. making a major breaking change, not supporting .NET Framework, to .NET Standard in a minor version)?
Edit: And before someone says ".NET Framework is choosing not to support .NET Standard, you shouldn't version based off implementations but off changes in the API": That only works if you have many implementations, .NET Standard has 3 major implementations! Losing 33% is pretty significant :)
I want to see .Net Standard die, not because of the technological merits of it or problems, but because you guys have created such a confusing mess and .Net Standard is perhaps one of the worst examples.
.Net Standard seemingly exists to consolidate compatibility between Core/Framework/whatever, but with you consolidating them under the "Framework" branding anyway there's no reason it should exist except to confuse further.
Either something is or isn't .Net 5 compatible. The end.
You're in luck because that's the way it is. The .Net Standard is on the list of being .Net 5 compatible, because it's intended for shared libraries.
I want libraries written for .Net Framework, Core and .Net 5 to be cross-compatible. Targeting the .Net Standard is the only way to do that. That's easily worth putting others, who aren't even using it, through mental turmoil.
It won't be going away because the .Net Standard is an absolute must-have for the health of the ecosystem, and the most important underpinning to the entire Framework->Core->.Net 5 effort. As the grandparent comment said, it won't be as important going forward (.Net 5, 6, 7 etc) but won't be going away until the .Net Framework does. It's likely the .Net Standard will outlive you.
For now, it's a vital bridge between .Net Framework and .Net Core. It's something I make use of regularly.
The updated image is this:
Which seems to have removed the implementations (mono/.NET Framework) and implies .NET 5 will be targeted by all platforms directly?
So what is .NET Standard needed for anymore, platforms now target .NET 5 versions instead of .NET Standard versions right?