It's only "wed to GDI+" because the current implementation is. Nothing's preventing them from implementing a cross-platform System.Drawing. There's no magic involved in what it does that requires GDI+.
I find it unbelievable that they would even consider releasing this without System.Drawing or equivalent being available.
So many people would embrace a truly cross platform framework will all bells and whistles. But instead we have this disturbing split between .NET, .NET Core and Mono.
.NET Core is slowly reimplementing/integrating all truly cross platform .NET classic APIs (https://github.com/dotnet/core/blob/master/roadmap.md). My guess is that at this point they didn't have the bandwidth to include what you're talking about in the first version but they will include it later on.
Long term Mono is probably just going to become a sort of .NET "distribution" on top of .NET Core, it will include things which Microsoft deprecated such as Winform. And it will probably be not maintained at the same level .NET Core itself is. I don't think there will be any reason to use Mono in the future, except for legacy Mono apps...
In the last presentation that I saw, the line was that Mono would continue to exist as a full .NET implementation to support Xamarin mobile apps. The reason given was that .NET Core was scoped as a run-time for server applications, so no work had been done on making it run on mobile devices, whilst Mono has been used in production on those platforms for some time.
That seems valid now. But developing two runtimes in parallel doesn't seem that great of an investment. Plus there are already dotnet core contributions regarding portability, for example from Samsung, it seems reasonable to think that 2-3-5 years from now dotnet core will power Mono as well.
You could be right, the current situation is unsettled, so I'm personally reluctant to predict anything much. The argument for Mono seems to boil down to the MS teams not having enough capacity to get .NET Core production-ready for mobile whilst doing everything else.
I'm going to be learning ASP.NET Core, but not even think about possible production use until after the next release. We will probably continue to avoid .NET for mobile, and I would not consider Mono for any other use case.
Well, .NET Core is probably still 1-1.5 years away from being fully production "friendly". Common Open Source .NET libraries have to be ported, .NET Core itself needs to reach base class library parity at least as far as its scope is concerned (including things such as System.Drawing based on Skia# or similar), the tooling around it needs to mature.
Anything outside of ASP.NET Core or small command-line tools is probably premature in 2016.
.NET Core has neither WinForms nor WPF. It's very much focused on web applications. System.Drawing might be useful for ... one in ten? web applications. And they have released it, and it's getting plenty of traction.
To re-use System.Drawing Microsoft would need to re-implement all those methods in a cross-platform, bug-compatible way. And there's a lot of code behind those methods.
In my opinion they made a reasonable decision to leave it out of v1.
No, my understanding of .Net core is that this is also the way they want to get back on devices. I think Xamarin will ultimately be based on .net Core. And for a mobile app, you bet you need a way to manipulate images.
Even for websites, depends on what sort of websites you do, but I often need to display charts, so being able to generate images on the fly.
Why are you generating images on the fly to display a chart? Why not send the data points and render a chart clientside using JavaScript? There are plenty of libraries for that.
A lot of clients want native PDF output for their reports. None of the PDF generating libraries I know of support running JS. So if you want the same charts in both, you need to generate the images server side.
I am sure there are other ways but I found using the native datavisualization library very useful and simple to use. I am one of these guys who do as little javascript as necessary.
If you want to draw the chart from scratch perhaps but I use a library to generate the chart then send it as an image to the client. Very few lines of code required in .net, no javascript required.
Indeed, but there's still a heavy focus on web applications.
I have written a few commercial cross-platform applications with Xamarin. They deal with images - and System.Drawing would not have been helpful to me. iOS has UIImage and Android has Bitmap.
I have not worked with a website yet that didn't have a need for image-handling code, either to resize uploaded images, handle avatar generation, draw charts (although I suppose that's moving to client-side for newer apps), etc.
Frankly, the thing I liked best about the whole .net ecosystem is that it didn't go for the open source "release early, release often, release incomplete and buggy" philosophy. I'm just very disappointed to see Microsoft going in this direction.
If Microsoft isn't providing a rock-solid, feature-ful framework with impeccable backwards compatibility, who will? Nobody will.
A lot of stuff in System.Drawing is pure algorithm and should be easy to port to other platforms. It will be tricky once you do screen output but the image processing routines shouldn't be too hard to port and they are super useful for a lot of web apps that do reporting and other things.
I do agree. When I spoke to one of the guys there a while back though they said they simply had too much on their plate at the time and were hoping the community would kick in and help.
Yes, I'm hugely impressed by how much the teams at Microsoft have accomplished in the time, and how they have managed to change the direction of the platform without making a big mess. .NET Core could never be feature-complete on version 1, and I think that the folks involved have been very candid about the fact that it may take a while longer before it is able to support everything that many real-world projects need.
Look. People are voting me down, probably because they disagree with me. Let me explain where I'm coming from.
There's two types of programming ecosystem:
1) The wild west world. where there's no good tooling (IDEs, debuggers, etc), all libraries are provided by hundreds of random individual developers and of varying quality, vital tools (such as build systems) are a constant juggle of whatever's trendy at the moment, etc.
2) The world where there's a single comprehensive framework of extremely high compatibility managed by a single party, where tooling is excellent, where backwards compatibility is of paramount importance, and where everything you write is on a solid foundation that's not going to move out from underneath you.
If you want environment 1), you have a ton of choices. You can use Node.JS, you can use Python, you can use Ruby, you can use GoLang, Java, etc. If you want environment 2), you have exactly one choice: .Net. And in a year, based on everything I'm reading about .Net Core, you'll have zero.
The only saving grace is, being Microsoft, I can be confident that the .Net 4.5 stuff will work for at least another decade. Even if it's not the "trendy new hotness".
Maybe I'm a freak outlier, but I much much prefer the old Microsoft that wouldn't even think about releasing the product until it was 100% complete, tested, stable. I think they're moving in the exactly wrong direction, and driving full speed away from everything that made .Net such a great platform in the first place.
-----
Every time I've had to use a language where a lot of functionality is provided by "the community", it's been a constant cascade of buggy and badly-designed libraries. "The community" doesn't test their stuff before releasing it. Or the library works for the one tiny purpose it was written for, but isn't generic enough to be useful to anybody else. It's nobody's job to ensure quality or completeness, so it simply does not happen.
I'd rather have good code, even if I have to wait longer, than code from "the community".
Comments
What the heck are you supposed to do without System.Drawing? I find it incredible they've just plain removed it altogether.
System.Drawing is wed to GDI+ so not cross platform. There are third party libraries that work just fine.
https://github.com/imazen/Graphics-vNext
If you don't care about .NET Core but you do care about ASP.NET Core you can always run ASP.NET Core on Windows and use System.Drawing.
It's only "wed to GDI+" because the current implementation is. Nothing's preventing them from implementing a cross-platform System.Drawing. There's no magic involved in what it does that requires GDI+.
I find it unbelievable that they would even consider releasing this without System.Drawing or equivalent being available.
I'm confused. Didn't Microsoft purchase Xamarin lately? There's http://www.mono-project.com/docs/gui/drawing/ and https://github.com/mono/mono/tree/master/mcs/class/System.Dr... all waiting to be integrated. But I guess, this won't happen.
So many people would embrace a truly cross platform framework will all bells and whistles. But instead we have this disturbing split between .NET, .NET Core and Mono.
.NET Core is slowly reimplementing/integrating all truly cross platform .NET classic APIs (https://github.com/dotnet/core/blob/master/roadmap.md). My guess is that at this point they didn't have the bandwidth to include what you're talking about in the first version but they will include it later on.
Long term Mono is probably just going to become a sort of .NET "distribution" on top of .NET Core, it will include things which Microsoft deprecated such as Winform. And it will probably be not maintained at the same level .NET Core itself is. I don't think there will be any reason to use Mono in the future, except for legacy Mono apps...
In the last presentation that I saw, the line was that Mono would continue to exist as a full .NET implementation to support Xamarin mobile apps. The reason given was that .NET Core was scoped as a run-time for server applications, so no work had been done on making it run on mobile devices, whilst Mono has been used in production on those platforms for some time.
That seems valid now. But developing two runtimes in parallel doesn't seem that great of an investment. Plus there are already dotnet core contributions regarding portability, for example from Samsung, it seems reasonable to think that 2-3-5 years from now dotnet core will power Mono as well.
You could be right, the current situation is unsettled, so I'm personally reluctant to predict anything much. The argument for Mono seems to boil down to the MS teams not having enough capacity to get .NET Core production-ready for mobile whilst doing everything else.
I'm going to be learning ASP.NET Core, but not even think about possible production use until after the next release. We will probably continue to avoid .NET for mobile, and I would not consider Mono for any other use case.
Well, .NET Core is probably still 1-1.5 years away from being fully production "friendly". Common Open Source .NET libraries have to be ported, .NET Core itself needs to reach base class library parity at least as far as its scope is concerned (including things such as System.Drawing based on Skia# or similar), the tooling around it needs to mature.
Anything outside of ASP.NET Core or small command-line tools is probably premature in 2016.
.NET Core has neither WinForms nor WPF. It's very much focused on web applications. System.Drawing might be useful for ... one in ten? web applications. And they have released it, and it's getting plenty of traction.
Take a quick scroll through here: http://referencesource.microsoft.com/#System.Drawing/commonu...
To re-use System.Drawing Microsoft would need to re-implement all those methods in a cross-platform, bug-compatible way. And there's a lot of code behind those methods.
In my opinion they made a reasonable decision to leave it out of v1.
No, my understanding of .Net core is that this is also the way they want to get back on devices. I think Xamarin will ultimately be based on .net Core. And for a mobile app, you bet you need a way to manipulate images.
Even for websites, depends on what sort of websites you do, but I often need to display charts, so being able to generate images on the fly.
Why are you generating images on the fly to display a chart? Why not send the data points and render a chart clientside using JavaScript? There are plenty of libraries for that.
A lot of clients want native PDF output for their reports. None of the PDF generating libraries I know of support running JS. So if you want the same charts in both, you need to generate the images server side.
I am sure there are other ways but I found using the native datavisualization library very useful and simple to use. I am one of these guys who do as little javascript as necessary.
Isn't SVG or canvas more suitable for that on the web?
If you want to draw the chart from scratch perhaps but I use a library to generate the chart then send it as an image to the client. Very few lines of code required in .net, no javascript required.
You don't need JS to generate SVG server-side either ...
Indeed, but there's still a heavy focus on web applications.
I have written a few commercial cross-platform applications with Xamarin. They deal with images - and System.Drawing would not have been helpful to me. iOS has UIImage and Android has Bitmap.
I have not worked with a website yet that didn't have a need for image-handling code, either to resize uploaded images, handle avatar generation, draw charts (although I suppose that's moving to client-side for newer apps), etc.
Frankly, the thing I liked best about the whole .net ecosystem is that it didn't go for the open source "release early, release often, release incomplete and buggy" philosophy. I'm just very disappointed to see Microsoft going in this direction.
If Microsoft isn't providing a rock-solid, feature-ful framework with impeccable backwards compatibility, who will? Nobody will.
A lot of stuff in System.Drawing is pure algorithm and should be easy to port to other platforms. It will be tricky once you do screen output but the image processing routines shouldn't be too hard to port and they are super useful for a lot of web apps that do reporting and other things.
I've been working on a solution to that. github.com/JimBobSquarePants/ImageProcessor
That's great, but it belongs in the framework. I'm incredibly disappointed by that decision.
I disagree, there is too much in the framework which ends up stuck there for ever, bloating the whole system.
System.Drawing is a good example, if you read the msdn docs it is clearly not supported on ASP.Net or from a Windows Service.
Libraries like imaging should be a nuget package.
The fix to "System.Drawing is not cross-platform" isn't just deleting it. It's to rewrite it so it is cross-platform.
I do agree. When I spoke to one of the guys there a while back though they said they simply had too much on their plate at the time and were hoping the community would kick in and help.
Yes, I'm hugely impressed by how much the teams at Microsoft have accomplished in the time, and how they have managed to change the direction of the platform without making a big mess. .NET Core could never be feature-complete on version 1, and I think that the folks involved have been very candid about the fact that it may take a while longer before it is able to support everything that many real-world projects need.
Look. People are voting me down, probably because they disagree with me. Let me explain where I'm coming from.
There's two types of programming ecosystem:
1) The wild west world. where there's no good tooling (IDEs, debuggers, etc), all libraries are provided by hundreds of random individual developers and of varying quality, vital tools (such as build systems) are a constant juggle of whatever's trendy at the moment, etc.
2) The world where there's a single comprehensive framework of extremely high compatibility managed by a single party, where tooling is excellent, where backwards compatibility is of paramount importance, and where everything you write is on a solid foundation that's not going to move out from underneath you.
If you want environment 1), you have a ton of choices. You can use Node.JS, you can use Python, you can use Ruby, you can use GoLang, Java, etc. If you want environment 2), you have exactly one choice: .Net. And in a year, based on everything I'm reading about .Net Core, you'll have zero.
The only saving grace is, being Microsoft, I can be confident that the .Net 4.5 stuff will work for at least another decade. Even if it's not the "trendy new hotness".
Maybe I'm a freak outlier, but I much much prefer the old Microsoft that wouldn't even think about releasing the product until it was 100% complete, tested, stable. I think they're moving in the exactly wrong direction, and driving full speed away from everything that made .Net such a great platform in the first place.
-----
Every time I've had to use a language where a lot of functionality is provided by "the community", it's been a constant cascade of buggy and badly-designed libraries. "The community" doesn't test their stuff before releasing it. Or the library works for the one tiny purpose it was written for, but isn't generic enough to be useful to anybody else. It's nobody's job to ensure quality or completeness, so it simply does not happen.
I'd rather have good code, even if I have to wait longer, than code from "the community".
A JAVA guy could probably make a good selection of corporate-supported frameworks that work as seamlessly as .NET.
And then, there's the Apple world, with their well designed mobile and desktop libraries, and a hot new C#-like language... Just saying.
Java might have the framework(s), but where's the tooling? Java doesn't have a single decent IDE.
The thought that Apple's Swift might actually come the closest to what I want after .Net occurred to me, also. Ugh.
https://www.jetbrains.com/idea/
Seriously, at this point, Jetbrains IDE-s are better than Visual Studio.
You use the superior ImageMagick instead.