They seem to massively change something every 10 minutes.
I also don't get the 'massively productive' comment, in essence very little has changed since, hell even MVC 3, apart from the obsession with DI and a load of packages now don't work. If you weren't 'massively productive' before, you were probably doing something wrong. They just moved a couple of things around and now insist you use npm/bower/whatever hotness they latch onto next week instead of nuget. I'm sure we'll have another blog post about them ditching support for anything but yarn next week.
And how long before they change their minds about how controllers work again, it's been like 4 times in the last 5 years now. First MVC controllers, then Web API, then Web API 2, then OData, then .Net Core, all very similar but slightly different with slightly different ways to register them at startup and slightly different things available on the context. Apart from the utter madness that is OData, great for data tables, bloody awful for everything else.
It's getting almost as bad as javascript churn but it's one company so it doesn't make any sense.
Microsoft shouldn't push out an RTM product and call the broken bits "Preview" to absolve themselves of the responsibility to deliver a reliable product.
I was evangelical about .NET Core. I stuck with it for years. I stuck with it when Damian admitted that he "doesn't build web apps". I stuck with it during the Release Candidates. It's only when they pushed this out the door and called it RTM that the penny dropped and I accepted the project had been mismanaged.
Why complain if you understood the status and assumed the risk?
If you knew anything of the traditional release history for Microsoft you wouldn't have commented. All your post demonstrates is total ignorance of the context or history.
It was previously totally fine to use RCs for the last decade, probably way before that too, but I only have experience from then. RC in MS speak meant "pretty much finished, API won't change unless we find something desperately wrong".
Then it suddenly means basically pre-alpha, "anything can change, massively, between RC versions".
Moving to npm/bower for front end stuff makes perfect sense, NuGet is a horrible way to deliver client side code, wasn't supported by the majority of library producers and was unknown by anyone who didn't have a .Net background.
I think all the changes now are due to that late switch of direction. RC2 went straight to 1.0 but it was a major change and should probably have had some more beta/RC releases.
> in essence very little has changed since
?
The one thing Microsoft is great at is compatibility. Your existing projects can keep using the older frameworks and they're still supported and will run just fine. What is the issue? If it's about learning the new changes, then it's probably best to wait until everything (framework + tooling) are final so you only have to learn once.
The problem is that it's hard to understand what does what and how it does it. Things in even the same project behave differently. They introduce massive architectural changes and then abandon them. Searching for something in SO now is a crap shoot, which slightly in correct answer will you get because the asp.net team changed their mind again?
And you can have all these things running in one project, all acting differently.
I work with clients on MVC 3,4,5, with parts in web API 1 and 2 and parts in odata.
And they all behave differently.
For example, and this is just one of many, a JSON date from an MVC controller is 'Date(173737273)', from a web API it's '2016-12-26 23:00:00.0000', from an OData controller it's '2016-12-26 23:00:00.0000Z'. That Z changes behaviour btw and makes the terrible assumption your date is in the same TZ as your server.
All of them are parsed different and will return different dates in javascript.
I can actually tell you the exact software installed on the build server:
1.) Window Server 2016 (Base OS)
2.) SQL Server 2016 Express with LocalDB only (used for longer integration tests that need to validate migrations)
3.) DotNetCore.1.0.1-SDK.1.0.0.Preview2-003133-x64.exe (.NET core SDK 1.0.1 download from https://www.microsoft.com/net/download)
4.) BuildTools_Full.exe ("Microsoft Build Tools 2015 Update 3" https://www.visualstudio.com/downloads/#d-build-tools). If you have this, then you don't need the full VS install
5.) NodeJs (for running webpack as part of 'dotnet publish')
6.) TeamCity and Octopus Deploy agents
Huh?
`docker run microsoft/dotnet`. Took about 2 seconds to get it running on my Jenkins build server. In reality, it took literally no effort. My entire full stack app requires `make` and `docker` to build and nothing else. The backend is an AspNetCore API.
What about security vulnerabilities? Unless the developers redeploy the application we will be left with an unpatched .net stack and unpatched web server?
How is that a good idea? In an ideal world there would be an active dev team busy redeploying and patching every day behind each website. But people who think we live in this world haven't really followed the pretty much constant stream of news about major breaches because of unpatched versions of software being used everywhere.
Or am I missing something?
Portable: runtime must be installed on target machine Standalone: runtime bundled with application
Portable is how non-Core .NET apps have always been, and I believe all the templates in the Visual Studio preview tooling are setup as portable apps.
The docs have a good explanation of the differences, and how to configure a project to support either deployment strategy:
https://docs.microsoft.com/en-us/dotnet/articles/core/deploy...
Not too hard, if you have some standard practices in place.
But yeah, if that's too much to ask for, just don't ship the framework in your project. You can still have it installed as a system package. But to be frank, it's nearly the same problem, just in a different spot.
I obviously didn't downvote but I do understand the downvotes: it is unrealistic to expect every website to be actively maintained forever. I am sure he deploys a new version every 20 minutes of his current project. I would be curious to know how many versions a year he deploys of the projects on which he worked 5 or 7 years ago and from which he moved on.
The world is filled with legacy applications, libraries and websites. Pretending that the code we write today will always be actively maintained and supported is just unrealistic.
I've done it in multiple projects, only problems I've encountered were nuget restoring which was easily fixable.