> .NET Standard 1.6.1-preview1 was published as part of this release. .NET Standard 2.0 support is still coming.
I feel like the highlight of .NET Core will be when it finally implements .NET Standard 2.0. For those who haven't been following, .NET Standard 2.0 is basically the moment when .NET finally reaches cross platform consistency parity with Java.
For Java, if you want to have a cross platform app, you just target Java. For .NET versions pre-.NET Standard 2.0 you basically target a mishmash of platforms through "profiles". Imagine that when you're creating a Java app you'd be forced to chose a "profile" that says: this app supports JavaCombo12 (AIX, Solaris, Linux). Then once MacOS is available as a platform you have to choose JavaCombo13, that includes that. And then JavaCombo14, JavaCombo15, etc.
Oh, I almost forgot! To make things more interesting, each "combo" could have different APIs available! :)
Wait a few months. Then target your library development at .net standard 2.0. It will work across the classic .net framework (Windows), the new cross-platform .net core (Windows, Linux, OSX) as well as the Xamarin (iOS, Android, Windows UWP).
That's exciting. I applaud MS for openly expanding to other platforms but the confusing profile names need to be simplified. IMHO, there should be two profiles .NET Universal and .NET Windows (a superset of .NET Universal).
> Imagine that when you're creating a Java app you'd be forced to chose a "profile" that says
They are called:
- Android Java
- Java Micro Edition
- Java Embedded Edition with (compact profile 1, 2 and 3)
- Java Standard Edition
- Java Enterprise Edition
- MicroEJ Java
- Real Time Java
Ah, then there are the vendor specific features like AOT compilation to native code or value objects like the Packet Objects in J9, just to give a possible example.
I thought someone would nitpick that statement. Microsoft supposedly designed and built .NET as a cross platform framework, even though they only released it for Windows. Yet many years after .NET's release and the .NET Core announcement, they're still struggling to achieve parity with Java.
Meanwhile, many of the examples from your list don't compare 1:1 with .NET profiles, because... :
- Android Java
This was caused by Google, so not $VENDOR's fault (Sun/Oracle).
- Java Micro Edition
This is moribund these days.
- Java Embedded Edition with (compact profile 1, 2 and 3)
This targets a totally different use case than the average .NET profile (most .NET profiles are minor variations on a theme).
- Java Standard Edition
Let's just call this "Java" :)
- Java Enterprise Edition
Let's call this "Java" + libs. It's hardly a profile, it's just Java + stuff on top.
- MicroEJ Java
I don't really know about this one.
- Real Time Java
See my comment about Java Embedded.
.NET profiles are IMO, just an ugly hack to re-add portability to a platform that was designed with portability in mind but then lost it gradually as it became more and more integrated with Microsoft platforms.
As for the rest, we will have to agree to disagree. Regardless how it looks like in detail, in the daily work they are issues to take into account when trying to write portable Java code.
.NET was designed with portability across processors and Windows versions, not for other vendors. Even Rotor wasn't fully compliant with .NET 1.0.
When looking at the histories told by Don Syme related to the initial generics design and Ext-VOS, .NET genesis was to be a native platform based on COM. Actually something that was brought back to life as .NET Native + WinRT.
As for the .NET profiles, they aren't perfect, but as someone that works daily with Java and .NET, I look forward to them.
It'll almost have parity with Java once Core support .NET Standard 2.0.
One admittedly unpopular area it'll be missing is options for desktop development. I know that the trend these days is to use web interfaces, and web development makes up about 95% of my professional life.
But just out of curiosity, I picked up a WPF book from the library. And as I was reading through it, I remember thinking how nice it would be to be able to develop web apps with something like that. I suppose Silverlight would've been close, but it's dead these days.
It looks like JavaFX is broadly similar to WPF over in Java-land, and it appears to work fairly well cross platform. It doesn't look native on any platform, but that isn't always a deal breaker. Using Intellij's non-native looking Swing UI on my MacBook doesn't bother me, though I appreciate that not everyone feels that way.
I suppose this is my roundabout way of saying I'd love to have a decent cross platform .NET GUI framework. For anyone who wants this too, Avalonia looks like a good project to follow: https://github.com/AvaloniaUI/Avalonia
It doesn't appear to support .NET Core yet, but last time I checked they expected to be able to relatively soon.
I have been doing projects in the healthcare area.
In what concerns computers to control robots, measurement devices and doing ETL data processing of data readers, on the projects I have been involved it is 100% Windows native WPF applications, with the legacy ones being a mix of MFC and Windows Forms.
Despite the uncertainties I have about .NET's future, I'm very excited for the possibilities this will open up if they would continue this pace and just listen to the community. I myself can't wait for the freedom to choose a linux or windows server to deploy on
Question to the seasoned .NET devs - If you're planning to build a F# app that will eventually be deployed on Linux and developed on a Mac, what (& why) would be your choice - Mono or .NET Core?
My plan is to target .NET Core. I like the idea of being able to run on cheap Linux instances. Although Xamarin is part of Microsoft, I'm concerned Mono might end up being the red-headed stepchild, with Core getting better company backing. The only thing that sucks is that currently some of the larger cool projects (like Suave and Akka.net aren't ready for Core yet (I think)). So eventually: sweet, short-term might be a couple more headaches.
I agree! In the new scheme of things I'm not sure how Mono fits into the .NET landscape. I was eagerly waiting to get a answer in Changelog's latest episode[0] but sadly they didn't cover this at all.
It's even more confusing that there is absolutely no mention of .NET Core on the language's Github page - http://fsharp.github.io/
Depends on what APIs you need, and what your tolerance is for futzing around with things. If you need the larger API surface of the .NET Framework and you don't have time to be on the bleeding edge, go with Mono. Xamarin Studio has good support for it, and even if you're using some other editor (VSCode, Spacemacs, etc.) everything still generally works with the tooling for Mono.
There are basically two components that need polishing for .NET Core to be a reasonable choice - the implementation of NetStandard 2.0 for .NET Core (so you get all the old APIs back), and for the tooling to mature (transition from project.json back to fsproj). These efforts are coming along nicely [1][2], but still aren't ready for prime time.
And by the way, don't worry too much about switching over from Mono to .NET Core. With NetStandard 2.0 the API changes should be minimal. Similarly, once the cleaned up proj file format is out of preview the change in tooling from Mono to .NET Core should be minimal (or even non-existent).
I find all the terminology and tooling around .NET Core... confusing.
Let's say I want to target RHEL and CentOS, versions 5-7. If I build mono on a machine with an old enough glibc, that single build will run on all of these. What's the equivalent to run on all these platforms with .NET Core?
.NET Core is the equivalent to mono. However the .NET Core libraries were a bit painful to port to since they were limited. So they are expanding this with .NET Standard - which is an API specification - which you can use and work across all .NET platforms (.NET Framework, .NET Core, or Xamarin).
Keep in mind it sounds like .NET Standard basically is between the full .NET Framework and .NET Core. So if you have an existing .NET Framework app it's very possible it would just work on .NET Standard.
But what about runtimes? Can I have a single .NET runtime that will work with all of those Linux versions? With mono I have a single runtime that actually works across almost every Linux distro. Can I do this with .NET, have a generic runtime build that just works on everything?
.Net Core is the runtime. It's the cross platform version of the .NET Framework.
.Net Standard is just an API specification which will be implemented on the .NET Framework, .NET Core, or Xamarin runtimes. Technically it's a subset of the .NET Framework libraries. It's more of an improvement on .NET Core as it is bringing more APIs to that runtime.
So basically as long as you use the APIs in .NET Standard, your application can be compiled for any of those 3 runtimes.
There's a lot of popular nuget packages handling dependency injection, in fact, the ASP.NET docs encourage you to use one in place of their own rudimentary implementation.
The ones I'm aware of that have ported to .net core are StructureMap and Autofac.
30 comments
[ 4.1 ms ] story [ 75.9 ms ] thread>1380 APIs were added in this release
>Added support for Linux Mint 18, OpenSUSE 42.1, macOS 10.12, Windows Server 2016
> .NET Standard 1.6.1-preview1 was published as part of this release. .NET Standard 2.0 support is still coming.
I feel like the highlight of .NET Core will be when it finally implements .NET Standard 2.0. For those who haven't been following, .NET Standard 2.0 is basically the moment when .NET finally reaches cross platform consistency parity with Java.
For Java, if you want to have a cross platform app, you just target Java. For .NET versions pre-.NET Standard 2.0 you basically target a mishmash of platforms through "profiles". Imagine that when you're creating a Java app you'd be forced to chose a "profile" that says: this app supports JavaCombo12 (AIX, Solaris, Linux). Then once MacOS is available as a platform you have to choose JavaCombo13, that includes that. And then JavaCombo14, JavaCombo15, etc.
Oh, I almost forgot! To make things more interesting, each "combo" could have different APIs available! :)
They are called:
- Android Java
- Java Micro Edition
- Java Embedded Edition with (compact profile 1, 2 and 3)
- Java Standard Edition
- Java Enterprise Edition
- MicroEJ Java
- Real Time Java
Ah, then there are the vendor specific features like AOT compilation to native code or value objects like the Packet Objects in J9, just to give a possible example.
Meanwhile, many of the examples from your list don't compare 1:1 with .NET profiles, because... :
- Android Java
This was caused by Google, so not $VENDOR's fault (Sun/Oracle).
- Java Micro Edition
This is moribund these days.
- Java Embedded Edition with (compact profile 1, 2 and 3)
This targets a totally different use case than the average .NET profile (most .NET profiles are minor variations on a theme).
- Java Standard Edition
Let's just call this "Java" :)
- Java Enterprise Edition
Let's call this "Java" + libs. It's hardly a profile, it's just Java + stuff on top.
- MicroEJ Java
I don't really know about this one.
- Real Time Java
See my comment about Java Embedded.
.NET profiles are IMO, just an ugly hack to re-add portability to a platform that was designed with portability in mind but then lost it gradually as it became more and more integrated with Microsoft platforms.
A Java version produced by IS2T for micro-controllers, think cortex-M class.
http://www.microej.com/
http://www.stm32j.com/products/
As for the rest, we will have to agree to disagree. Regardless how it looks like in detail, in the daily work they are issues to take into account when trying to write portable Java code.
.NET was designed with portability across processors and Windows versions, not for other vendors. Even Rotor wasn't fully compliant with .NET 1.0.
When looking at the histories told by Don Syme related to the initial generics design and Ext-VOS, .NET genesis was to be a native platform based on COM. Actually something that was brought back to life as .NET Native + WinRT.
As for the .NET profiles, they aren't perfect, but as someone that works daily with Java and .NET, I look forward to them.
One admittedly unpopular area it'll be missing is options for desktop development. I know that the trend these days is to use web interfaces, and web development makes up about 95% of my professional life.
But just out of curiosity, I picked up a WPF book from the library. And as I was reading through it, I remember thinking how nice it would be to be able to develop web apps with something like that. I suppose Silverlight would've been close, but it's dead these days.
It looks like JavaFX is broadly similar to WPF over in Java-land, and it appears to work fairly well cross platform. It doesn't look native on any platform, but that isn't always a deal breaker. Using Intellij's non-native looking Swing UI on my MacBook doesn't bother me, though I appreciate that not everyone feels that way.
I suppose this is my roundabout way of saying I'd love to have a decent cross platform .NET GUI framework. For anyone who wants this too, Avalonia looks like a good project to follow: https://github.com/AvaloniaUI/Avalonia
It doesn't appear to support .NET Core yet, but last time I checked they expected to be able to relatively soon.
In what concerns computers to control robots, measurement devices and doing ETL data processing of data readers, on the projects I have been involved it is 100% Windows native WPF applications, with the legacy ones being a mix of MFC and Windows Forms.
It's even more confusing that there is absolutely no mention of .NET Core on the language's Github page - http://fsharp.github.io/
[0] - https://changelog.com/podcast/224
Also, .net Core does not have feature parity with .net4.6/mono, so you may want to know the gaps depending on the type of application being built.
There are basically two components that need polishing for .NET Core to be a reasonable choice - the implementation of NetStandard 2.0 for .NET Core (so you get all the old APIs back), and for the tooling to mature (transition from project.json back to fsproj). These efforts are coming along nicely [1][2], but still aren't ready for prime time.
Here's a roadmap that Enrico Sada has laid out to get the F# .NET Core situation to maturity: https://gist.github.com/enricosada/6f0a0424ca65b9d08e5a84f79...
And by the way, don't worry too much about switching over from Mono to .NET Core. With NetStandard 2.0 the API changes should be minimal. Similarly, once the cleaned up proj file format is out of preview the change in tooling from Mono to .NET Core should be minimal (or even non-existent).
[1] https://slack-files.com/T04BJKUMU-F2ST232AJ-6e68200a3d - Enrico Sada's work on getting dotnet cli to work with proj system for .NET Core [2] https://twitter.com/sforkmann/status/790488306991661056?s=09 - Steffen Forkmann getting Paket to work with new proj system
Let's say I want to target RHEL and CentOS, versions 5-7. If I build mono on a machine with an old enough glibc, that single build will run on all of these. What's the equivalent to run on all these platforms with .NET Core?
Keep in mind it sounds like .NET Standard basically is between the full .NET Framework and .NET Core. So if you have an existing .NET Framework app it's very possible it would just work on .NET Standard.
.Net Standard is just an API specification which will be implemented on the .NET Framework, .NET Core, or Xamarin runtimes. Technically it's a subset of the .NET Framework libraries. It's more of an improvement on .NET Core as it is bringing more APIs to that runtime.
So basically as long as you use the APIs in .NET Standard, your application can be compiled for any of those 3 runtimes.
The ones I'm aware of that have ported to .net core are StructureMap and Autofac.