Just from the examples on this list, it sounds like the only winning move is not to play.<p>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.<p>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.<p>As reward for this, migrating over to Core would gain me roughly $0 in business value.<p>The alternate course is to stay with 4.5 for as long as possible, eventually moving across when Microsoft decide to VB6 it.<p>Sounds like a plan.
>We ended up using the JsonProperty attribute on some things to force their casing how we needed them.<p>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.)<p>[1]: <a href="https://github.com/aspnet/Mvc/issues/4842" rel="nofollow">https://github.com/aspnet/Mvc/issues/4842</a>
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.<p>After having to configure camalCase for json a couple of times I like the new default.<p>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.
This is quite frankly an excellent list of why we won't be changing any time soon, with key points being:<p>> Things like virtual hosts, logging, security, etc.<p>> Newtonsoft now defaults to camelCase<p>> Log4net doesn’t work and neither do countless other dependencies, unless you target .NET 4.5<p>I mean a lot of those things are the reason we're using .Net over more other technologies to begin with.
"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!"<p>So the new Microsoft web server replacing IIS, Kestrel, is 20x faster in some circumstances? Wasn't IIS "state of the art"?
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 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.<p>Is that correct?<p>That's the recommended way to deploy?
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.
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.