Lessons Learned while Converting from ASP.NET to .NET Core
stackify.com
stackify.com
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.
Prefix is on there so I'll update it to support .NET Core in addition to the ASP.NET Core it already supported (on .NET 4.5).
Migrating anything big is probably a bad idea but for new projects Core might be a good option.
No, you can just use the normal Visual Studio, with ReSharper support.
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.
So why would you do it in the first place? Because "It's the Future"?
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.)
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.
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.
> Things like virtual hosts, logging, security, etc.
> Newtonsoft now defaults to camelCase
> Log4net doesn’t work and neither do countless other dependencies, unless you target .NET 4.5
I mean a lot of those things are the reason we're using .Net over more other technologies to begin with.
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
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.
So the new Microsoft web server replacing IIS, Kestrel, is 20x faster in some circumstances? Wasn't IIS "state of the art"?
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.
Why is that? Will you still have the performance benefit of Kestrel if you use IIS in front of it? How would that work?
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.
IIS as a reverse proxy in front of kestrel should be very fast.
AFAIK even venerable Apache performed better than IIS, and Apache is not the fastest web server out there.
There's even some docs straight from the asp.net site[0].
It's a bit of a paradigm shift from the "old" way but it's quite a normal thing to do with Node.js for example.
[0] - https://docs.asp.net/en/latest/publishing/linuxproduction.ht...
Sounds complicated. You have two states to maintain and keep synced. The .net core servers and IIS.
Is that correct?
That's the recommended way to deploy?
[1] http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteT...
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.
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.
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.
That said, check out Avalonia and some other OSS experiments.
"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."
Now, they could reimplement system.drawing using a different backend per platform, but I don't think the demand is high enough.
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.
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.
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...
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.
Anything outside of ASP.NET Core or small command-line tools is probably premature in 2016.
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.
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.
Isn't SVG or canvas more suitable for that on the web?
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.
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.
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.
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.
The thought that Apple's Swift might actually come the closest to what I want after .Net occurred to me, also. Ugh.
Seriously, at this point, Jetbrains IDE-s are better than Visual Studio.