Just from the examples on this list, it sounds like the only winning move is not to play.
I have a handful of sites running ASP.NET 4.5. Migrating them would cost an unknown amount of time and require substantial rewriting of major components (such as all data access). It might not even be physically possible to do, given dependencies on libraries that are still 4.5 only.
It sounds like it would also kill our build process dead (adding another major rewrite to the tally). And of course, it would leave us reliant (correct me if I'm wrong here) on a lighter weight version of VS.NET so we'd roll back the clock about 10 years on ReSharper-like goodness.
As reward for this, migrating over to Core would gain me roughly $0 in business value.
The alternate course is to stay with 4.5 for as long as possible, eventually moving across when Microsoft decide to VB6 it.
Glad to hear. I hadn't seen them mention it anywhere, and since it was such an obvious dealbreaker, I would have expected it to be a major talking point.
I feel like you're conflating .NET Core and ASP.NET Core. You can use ASP.NET Core 1.0 on .NET 4.6.x today. If you don't need cross-plat, that's cool. But you have the full API surface area you have today, plus some significant new features and perf improvements.
> on a lighter weight version of VS.NET so we'd roll back the clock about 10 years on ReSharper-like goodness.
I've been using Rider from JetBrains on and off for a few months. I'd recommend it. It's great to just remove MS from the picture and come that much closer to using IntelliJ in my Windows-based job.
>We ended up using the JsonProperty attribute on some things to force their casing how we needed them.
That's a weird choice. It's a one-line modification to change back to the legacy naming scheme [1]. (Which is completely non-standard and doesn't follow what basically the entire rest of the web accepts as the standard method of naming js object keys. But hey, .NET people are really beholden to some strange things.)
I recently built a web app with the new dotnet core . the changes were not so bad, I even found that the docs were nicer than the ones you find for the "old" asp.
After having to configure camalCase for json a couple of times I like the new default.
But migrating an existing app at this point is out of the question, when I no longer need to have nugget packages with rc in the version name we might do it.
No I'm talking about the version numbers themselves, things like:
1.0.0-preview2-final
I will not take a working(and money-making) code base and migrate it to a platform where that is the version I need to use.
As for project.json. I actually liked using JSON over XML, but it's a personal preference thing, can't really make a case that it's better.
For me the big attraction to aspnetcore is not the aspnetcore MVC, but the new infrastructure that they build around it. I am working on a project right now going down to every single little tiny details of aspnetcore capabilities https://github.com/dodyg/practical-aspnetcore
.net core certainly does have security, logging etc. IIS, as opposed to kestral, has more features and you can host under IIS so this is a non issue.
The camelCase setting is a one line code change if you don't like it. Not at all a reason to avoid the framework. It's using newtonsoft for this so it may even be a change in the package itself? Anyway I changed the default and then ended up reverting back anyway since camelCase is a better format when using the objects in JavaScript.
It's not meant to support everything as the goal is cross platform. IMO it's a great platform if you understand its limits.
"As part of .NET Core, Microsoft (and the community) has created a whole new web server called Kestrel. The goal behind it has been to make it as lean, mean, and fast as possible. IIS is awesome but comes with a very dated pipeline model and carries a lot of bloat and weight with it. In some benchmarks, I have seen Kestrel handle up to 20x more requests per second. Yowzers!"
So the new Microsoft web server replacing IIS, Kestrel, is 20x faster in some circumstances? Wasn't IIS "state of the art"?
It isn't replacing IIS, and they're very clear that you almost certainly shouldn't be exposing Kestrel to the internet without going through something like nginx or IIS.
Kestrel does the bare basics of a web server, it goes a little bit further than the dev servers built into plenty of other language's web frameworks.
The same reasons that Python, Ruby, and Node are almost always reverse-proxied by a "bigger" web server. The "closer to the metal" server handles things like virtual hosts, load balancing, black lists/white lists, throttling, speaking to the kernel-layer about low level IP port specifics, while the "closer to the language" server deals with the realities of your business logic and application code.
That separation of concerns between two web servers in a reverse-proxy has become a very useful mainstay "Production best practice" in the Linux/Unix world, so it's nice to see Kestrel follow the larger trends there. It makes it easier to use Kestrel in most Linux/Unix deployments, but some of the reasons that it became best practice apply back to Windows. For instance, the principal of least privilege applies in that the application web server can run in a much more isolated process space than the kernel-level web server and the service boundary to secure between them in a reverse-proxy scenario is "just HTTP".
As for performance, IIS is a rather good reverse proxy and efforts to make it better for Kestrel have benefited Node, Python, and Ruby hosting on Windows, as well as vice versa.
I'm surprised that there's no DataTable in .NET Core. I've found them to be incredibly useful for ETL and other processes that involve ingesting or outputting tabular data. Are there any alternative 3rd party libraries out there that have similar functionality?
Stupid question. How do you share IPs if all the websites on a machine are running their own webserver? When running in IIS, IIS handles the virtual hosts. Unless we found a massive stach of IPv4 IPs?
So you set up the self hosted webservers on some non routable local IPs / ports, and set up IIS to map these IPs / ports to the external IP / hostname?
Sounds complicated. You have two states to maintain and keep synced. The .net core servers and IIS.
It's done with Node.js and nginx all the time. Other than the initial configuration nginx is essentially stateless, and there's simple setups out there to automate the nginx config as well, with docker for example: https://github.com/jwilder/nginx-proxy.
So deploying web apps now consists of deploying a service that uses kestrel and having a reverse proxy in front of it (IIS or nginx or something)as the first point of contact.
I have a side project with a couple of sites on a small Linux VPS, each one runs on port 5005, 5006, 5007, and so on. nginx passes requests to each different domain name onto the servers listening on their respective ports.
Another "little" one: Studio tooling is still in preview, so NCrunch cannot be used. It's been a moving target for a long time, and too hard to complete until locked down.
It's depressing to me that no talk about .Net Core even bothers to mention desktop apps. Winforms and co aren't even on the radar. I guess I'm stuck in the past.
All of the work in .NET Core benefits ".NET Native". .NET Native is what powers the .NET stack side for Universal Windows Platform (UWP) apps.
WinForms has been considered deprecated since WPF and WPF is essentially deprecated for UWP. (In an interesting historical aside, in some ways the UWP is what WPF was promised to be way back when WPF was still codenamed Avalon.)
Certainly WinForms and WPF aren't going anywhere any time soon (both in terms of backward compatibility will be stable for a long time still, but don't expect any new things), but UWP is clearly the way forward for new apps and it is benefiting from the work going into .NET Core.
The Desktop App Converter recently released (nee Project Centennial) can help if you've got a big investment in WinForms and wish to slowly migrate to UWP, so you aren't necessarily "stuck" in the past if you do want to try to move forward.
It supports UWP development. The .Net Framework isn't going anywhere though, if you're doing Windows desktop development in a legacy framework then you don't need the cross platform-ness of Core.
I could be totally wrong as I haven't really messed with it beyond dabbling, but from what I've heard, ASP.NET 4.? (6?) to ASP.NET Core is a pretty big shift which is why there's a lot of conversation around it. In fact, ASP.NET Core has a lot of changes vs the RCs (dipped toes into JSON configs, reverted back). Nuget has given up front end to bower now as well.
Perhaps that means desktop .NET Core is a more familiar experience? I'm not sure. But unless it is UWP or ASP.NET, I don't know how much we'll see coming as far as talk goes.
Honestly if I had to do a new desktop app project. I would probably go with nodejs + chromium + html (front end) & C# + .NET Core (backend). You get total control over the UI without having to deal with WPF, plus it runs cross platform.
For a website, not being able to manipulate files (no System.IO.File) or images (no System.Drawing) is a bit of a problem unless all you are doing is serve a database.
"Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. For a supported alternative, see Windows Imaging Components."
System.Drawing actually wraps GDI win32 calls, so while it works, running it on a server would be iffy, and running it on non Windows would be impossible.
Now, they could reimplement system.drawing using a different backend per platform, but I don't think the demand is high enough.
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".
I have a handful of sites running ASP.NET 4.5. Migrating them would cost an unknown amount of time and require substantial rewriting of major components (such as all data access). It might not even be physically possible to do, given dependencies on libraries that are still 4.5 only.
It sounds like it would also kill our build process dead (adding another major rewrite to the tally). And of course, it would leave us reliant (correct me if I'm wrong here) on a lighter weight version of VS.NET so we'd roll back the clock about 10 years on ReSharper-like goodness.
As reward for this, migrating over to Core would gain me roughly $0 in business value.
The alternate course is to stay with 4.5 for as long as possible, eventually moving across when Microsoft decide to VB6 it.
Sounds like a plan.