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?
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.
