Stay away from .NET Core! we've had nothing but issues and they can't even figure out what they want to do, they keep adding/removing/changing and renaming the api all the time.
It's Read the Docs - you can switch between versions at the bottom left.
Plus more generally it is a pre-1.0 product which, while having a go live licence, means it isn't for everyone especially if you're not happy potentially doing some digging through code to work out undocumented features.
The OP doesn't say if they are a C# dev or a Ruby dev or neither. To be honest that is likely to be the biggest driver of things. Both are good enough that it isn't really worth paying the price of switching between two ecosystems for.
What is the nature of your data? Is it highly structured, do you want to enforce a robust schema, is it financial? What language are you developing the client in? What other services (if any) are you talking to on the backend? From the client?
Why .NET Core instead of just .NET? Is Linux hosting of the backend a requirement?
It's okay. When .NET core RC 2 ships in the next few days, "good." After Azure and AWS ship compliant SDKs and the rest of the ecosystem wakes up, "great."
Even if it's not, I wouldn't put myself in the corner by being dependent on windows hosting. Linux on the server is a norm nowadays.
Also, .NET Core is obviously the future. Yeah, they will keep Full .NET around, but... It's the same story as it was with WebForms vs MVC. WebForms is still supported, but who starts new projects with it?
dotnet rc2 is close to release but I wouldn't treat it as an rc. rc1 and rc2 changes are considerable and I'd expect more changes whilst they figure out the rest.
Unless you are willing to wait for 1.0 release of ASP.NET Core (which will probably happen in the end of summer) go for Rails. It's not done yet and not working properly on Linux.
Been a .net MVC developer for 5 years. Lots of problems with Core right now (RC1 is pretty stable but lots has changed since then, so it is a bit of an uphill battle).
I would suggest looking into Django and Django REST Framework. I'm loving using it in my off-time. I'm personally not a fan of Ruby, so I wanted to through my personal suggestion out there.
Typically with ASP.Net, you will be writing a lot of your logic in a compiled, typed language (even if the types are mostly inferred). That removes one class of run time error from your application.
On the other hand, for the next year at least, non-IIS hosting for ASP is second class. You can host sites on Linux, but there will be gaps. When you upgrade the site, do you need to turn that server on and off again, or it manage the change in excusables automatically?
The opensource library scene for .net is not as good as for some other languages.
Finally, Microsoft has a plan for making money out of ASP.Net Core, and if it seems like a route to run ASP applications somewhere that isn't Azure, we are missing something.
Wait a bit until the RTM, right now it's a mess, but in 6 month frankly, you can consider starting new projects with asp.net core.
I successfully wrote an app with asp.net core, mvc6 , entity framework (ORM) backed by Postgresql from scratch on Linux and deployed it on Heroku (with Mono, I wasn't able to run all my dependencies with CoreCLR). The app was fairly complex, with a big DB schema, it wasn't a toy and I did it in a week (without the tests).
It worked great and was pretty fast, I used the RC1 release though, the RC2 has a completely different tool chain so everything breaks. But aside from breaking API, great experience. C# is great.
Frankly, no question, for me it's a replacement for PHP+Symfony, Rails and Java on the long run. I initially wanted to move to Go but I wont, I prefer to take a small hit in term of performances and use a good language, rather than having optimal performances with a language I fight every second.
I prefer C# to Ruby but .NET Core is still a Release Candidate and it's a v1 product. So in terms of support, documentation, stability, etc you'll probably be better off with Ruby.
If you're considering deploying to Windows/Azure then .NET Core is a little more temping but otherwise...
I used .NET Core for an application. It was the worst experience I've ever had with a framework in seventeen years. We had switch off it about four months in.
Performance was terrible, critical strange bugs were everywhere, and documentation was awful. But most importantly they would completely change important APIs every month. I'd have update almost every file in my project. And they would change the same API again the next month...
Rails, Django, Sinatra, Express, all started with a clear vision of what they wanted to be. This made all the little details support the frameworks big idea. You could use prerelease and beta versions and be fine.
.NET Core, though, hasn't decided yet whether it wants to be baboon or a firetruck.
And it was a valid Release Candidate, they could have gone live with it. A bigger strategic decision was made to take various concepts from it and apply them to .Net in general not just web specific things. At the same time it gave the ASP team more time to tidy things up and be more consistent in terms of new patterns in a few places.
Microsoft was open very quickly that they were making big changes and that RC1 was going to look very different from 1.0. There has been some chaos but it means we are all going to end up with a 1.0 release that is much better, rather than getting a breaking 2.0 release in short order afterwards.
It should never be assumed that a Release Candidate is going to make it into production, especially from an enterprise software vendor launching a new product. If the lasting legacy of this is more people taking that on board then that will be a good thing.
I think they messed up calling it a RC1 and leaving it as it is for so long. People started writing drivers and what not and were confident that the stack wouldn't change too much, now they are going to wait the official release (i.e. at least a year) because the trust is broken. They should have called it a beta and not let it live for like a year. You don't do that.
> It should never be assumed that a Release Candidate is going to make it into production
Of course, but release candidate also means that there wont be any significant change in the tooling or philosophy. RC2 has completely different tooling and the code is completely incompatible. It doesn't build up trust.
... or at least ask the developers how the roadmap looks like and what they intend to break, overhaul, etc.
For example, working with Roslyn was a great experience even though we started our project when it was still in beta. Simply because the developers noted that even though it's beta the API is already fairly stable. There were a few things that still changed, but nothing that wasn't fixed in our code ten minutes later.
However I've shipped a Rails application that's started from a zip file I begged off DHH before Rails was even publicly available, and maintained it for years. I've used Django for a real app within a month or two of the first available Django release, and maintained to this day. Etc.
.NET Core goes beyond bleeding edge to point at which you start to wonder in your more crazed hours if it's actually just a parody of a poorly developed node.js library.
Aside from the ServiceStack dude making an extended sales pitch for his overwrought schlocky toolkit, the most disturbing thing in there is the massive dissonance between the experience of professional programmers and what really appears to be an endless throng of happy hobbyists who are excited to "follow the ride" of this thing through clumsy (but Open--yay!) development.
You get the impression that people at Microsoft are being rewarded for the number of issues being raised on GitHub for a not-ready-for-prime-time technology ecosystem--under the guise of "building a community." It's... odd.
> the massive dissonance between the experience of professional programmers and what really appears to be an endless throng of chipper hobbyists who are excited to "follow the ride" of this thing through clumsy (but Open, yay!) development.
Do you think hobbyists would really waste their time with Linux and Command Line tools when they can just download Visual Studio on Windows ? You seem to misunderstand why asp.net chose to go open source at first place.
> You get the impression that people at Microsoft are being rewarded for the number of issues being raised on GitHub for a not-ready-for-prime-time technology ecosystem, in the guise of "building a community." It's... odd.
They basically had to rewrite the entire framework + .net to run it on Linux. I'm pretty sure they are working quite hard and not wasting their time on Github social gimmicks to try to deliver the product in time. Why are you so angry against MS ? Because they break stuff? they always did that. Except now it's open source so if you don't like where it is going you can fork it.
Look at the way they're approaching Bash on Windows (which was also defended by shanselman in that thread). This is a brain dead, check-off-the-boxes compatibility exercise. Instead they threw some half-baked crap on Github and said "Hey community, let us know what doesn't work!" They pulled the same nonsense with C99 support. I know it's dark and rainy and lonely in your office, but just do the work, m'kay?
Instead they got Redis limping on it and so decided to release everything as part of an extended tradeshow demo. But months later they realized that it can't handle files that end in a period -- after the community alerted them. This is an absurd way to approach building a critical compatibility layer. It's a waste of everyone's time.
But they're over-excited about community input now. They said they were listening with Windows 8, too -- and now Sinofsky's new career is writing LinkedIn articles all day, pretending he didn't drive a $100 billion ecosystem into the ground for three years. Likewise does the OneDrive team really need a UserVoice site to tell them the thing simply doesn't work? A terabyte an hour of error logs and telemetry isn't enough I guess.
So "happy hobbyists" is being used by you now rather than "unemployed hobbyists" which you mentioned in the other thread. I've sat through a workshop by Damian and David on ASP that was full of professional programmers from various companies who all seemed quite enthusiastic about the changes at the end of the process. For those of us using MVC 5 at the moment the changes coming in Core are going to make life an awful lot better, and that they have decided to reboot to 1.0 from the old MVC 6 is a fair description for what is happening.
What were you using? RC1 came with a go live licence and should not have been having constantly breaking changes. From what you're saying it sounds like you were hooking up to the MyGet streams for the RC2 work which has never been announced as production ready and the dev team have repeatedly said is only for those who really want to live on the bleeding edge.
When RC2 is released in the near future the upgrade path from RC1 currently isn't that bad as a one off process. That they produced something good enough that the rest of the .Net team wanted to make use of it as well is a good thing and is going to be of benefit to .Net devs in general.
As for upgrades looking back through things like Rails early release notes there were plenty of "you'll need to do these things to upgrade" notices.
Thank you for sticking your neck out and actually sharing your real-life practical experience, something that seems to be exactly what the submitter was looking for!
Too early for .Net Core. Not ready. RoR is what you want. If you have to learn RoR still then maybe that changes the story. Say you know C# and not Ruby- then you could just build your backend on standard .Net and move to .Net Core when it makes sense.
Use the tech you feel the most comfortable/productive to accomplish the task now. It if it's .NET, go with the standard .NET, don't provoke new issues with .NET Core. Test and see how your app will be doing. In three/six months re-evaluate your decision and come up with an improvement you shall be doing next. Perfection needs time.
ASP.NET Core is no where near ready now. Do it if you are building an experimental project. If you are planning on doing anything serious in next 6 months then better to stay away from it.
The author of JSON.NET has decided to "wait until there is documentation". I found out about this when another library author linked to this issue as his reason for not creating a NuGet package for .NET Core:
If your goal is to build robust, mature web services the Java (Java and the friendly neighbours Scala and Clojure) and .NET (C# and the friendly neighbour F#) ecosystems are very hard to beat.
Hell, if you're choosing the latter get yourself an Azure description, build a new Mobile Services host and off you go -- Everything you would ever want is included out of the box (including client to server datasync), you only need to figure out what storage and other services you want to use (e.g. Microsoft's PN service for easy crossplatform notifications) and bring along your business logic.
52 comments
[ 2.6 ms ] story [ 103 ms ] threadAlso, there is a new API-only mode in Rails 5 which could come in handy for your case (API development): http://edgeguides.rubyonrails.org/api_app.html
I expect the "issues" to be something related to development process and running the code in prod.
Plus more generally it is a pre-1.0 product which, while having a go live licence, means it isn't for everyone especially if you're not happy potentially doing some digging through code to work out undocumented features.
The OP doesn't say if they are a C# dev or a Ruby dev or neither. To be honest that is likely to be the biggest driver of things. Both are good enough that it isn't really worth paying the price of switching between two ecosystems for.
Why .NET Core instead of just .NET? Is Linux hosting of the backend a requirement?
Even if it's not, I wouldn't put myself in the corner by being dependent on windows hosting. Linux on the server is a norm nowadays.
Also, .NET Core is obviously the future. Yeah, they will keep Full .NET around, but... It's the same story as it was with WebForms vs MVC. WebForms is still supported, but who starts new projects with it?
I would go with rails or alternatively Java with jax-rs if you want something somewhat similar to .net.
EDIT: typo.
I would suggest looking into Django and Django REST Framework. I'm loving using it in my off-time. I'm personally not a fan of Ruby, so I wanted to through my personal suggestion out there.
On the other hand, for the next year at least, non-IIS hosting for ASP is second class. You can host sites on Linux, but there will be gaps. When you upgrade the site, do you need to turn that server on and off again, or it manage the change in excusables automatically?
The opensource library scene for .net is not as good as for some other languages.
Finally, Microsoft has a plan for making money out of ASP.Net Core, and if it seems like a route to run ASP applications somewhere that isn't Azure, we are missing something.
Wait a bit until the RTM, right now it's a mess, but in 6 month frankly, you can consider starting new projects with asp.net core.
I successfully wrote an app with asp.net core, mvc6 , entity framework (ORM) backed by Postgresql from scratch on Linux and deployed it on Heroku (with Mono, I wasn't able to run all my dependencies with CoreCLR). The app was fairly complex, with a big DB schema, it wasn't a toy and I did it in a week (without the tests).
It worked great and was pretty fast, I used the RC1 release though, the RC2 has a completely different tool chain so everything breaks. But aside from breaking API, great experience. C# is great.
Frankly, no question, for me it's a replacement for PHP+Symfony, Rails and Java on the long run. I initially wanted to move to Go but I wont, I prefer to take a small hit in term of performances and use a good language, rather than having optimal performances with a language I fight every second.
If you're considering deploying to Windows/Azure then .NET Core is a little more temping but otherwise...
Performance was terrible, critical strange bugs were everywhere, and documentation was awful. But most importantly they would completely change important APIs every month. I'd have update almost every file in my project. And they would change the same API again the next month...
Rails, Django, Sinatra, Express, all started with a clear vision of what they wanted to be. This made all the little details support the frameworks big idea. You could use prerelease and beta versions and be fine.
.NET Core, though, hasn't decided yet whether it wants to be baboon or a firetruck.
You should never rely on early versions of something for critical, production projects without recognizing the risk.
Microsoft was open very quickly that they were making big changes and that RC1 was going to look very different from 1.0. There has been some chaos but it means we are all going to end up with a 1.0 release that is much better, rather than getting a breaking 2.0 release in short order afterwards.
It should never be assumed that a Release Candidate is going to make it into production, especially from an enterprise software vendor launching a new product. If the lasting legacy of this is more people taking that on board then that will be a good thing.
I think they messed up calling it a RC1 and leaving it as it is for so long. People started writing drivers and what not and were confident that the stack wouldn't change too much, now they are going to wait the official release (i.e. at least a year) because the trust is broken. They should have called it a beta and not let it live for like a year. You don't do that.
> It should never be assumed that a Release Candidate is going to make it into production
Of course, but release candidate also means that there wont be any significant change in the tooling or philosophy. RC2 has completely different tooling and the code is completely incompatible. It doesn't build up trust.
For example, working with Roslyn was a great experience even though we started our project when it was still in beta. Simply because the developers noted that even though it's beta the API is already fairly stable. There were a few things that still changed, but nothing that wasn't fixed in our code ten minutes later.
However I've shipped a Rails application that's started from a zip file I begged off DHH before Rails was even publicly available, and maintained it for years. I've used Django for a real app within a month or two of the first available Django release, and maintained to this day. Etc.
.NET Core goes beyond bleeding edge to point at which you start to wonder in your more crazed hours if it's actually just a parody of a poorly developed node.js library.
They clearly stated that it is in development and would drastically change as the development went on.
Aside from the ServiceStack dude making an extended sales pitch for his overwrought schlocky toolkit, the most disturbing thing in there is the massive dissonance between the experience of professional programmers and what really appears to be an endless throng of happy hobbyists who are excited to "follow the ride" of this thing through clumsy (but Open--yay!) development.
You get the impression that people at Microsoft are being rewarded for the number of issues being raised on GitHub for a not-ready-for-prime-time technology ecosystem--under the guise of "building a community." It's... odd.
Do you think hobbyists would really waste their time with Linux and Command Line tools when they can just download Visual Studio on Windows ? You seem to misunderstand why asp.net chose to go open source at first place.
> You get the impression that people at Microsoft are being rewarded for the number of issues being raised on GitHub for a not-ready-for-prime-time technology ecosystem, in the guise of "building a community." It's... odd.
They basically had to rewrite the entire framework + .net to run it on Linux. I'm pretty sure they are working quite hard and not wasting their time on Github social gimmicks to try to deliver the product in time. Why are you so angry against MS ? Because they break stuff? they always did that. Except now it's open source so if you don't like where it is going you can fork it.
Instead they got Redis limping on it and so decided to release everything as part of an extended tradeshow demo. But months later they realized that it can't handle files that end in a period -- after the community alerted them. This is an absurd way to approach building a critical compatibility layer. It's a waste of everyone's time.
But they're over-excited about community input now. They said they were listening with Windows 8, too -- and now Sinofsky's new career is writing LinkedIn articles all day, pretending he didn't drive a $100 billion ecosystem into the ground for three years. Likewise does the OneDrive team really need a UserVoice site to tell them the thing simply doesn't work? A terabyte an hour of error logs and telemetry isn't enough I guess.
When RC2 is released in the near future the upgrade path from RC1 currently isn't that bad as a one off process. That they produced something good enough that the rest of the .Net team wanted to make use of it as well is a good thing and is going to be of benefit to .Net devs in general.
As for upgrades looking back through things like Rails early release notes there were plenty of "you'll need to do these things to upgrade" notices.
But working with .NET core was about an early rails year's worth of breakage every month.
[1]: https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-t...
For production use, wait a while to use .Net Core.. It's awesome, but not there yet.
Given your alternatives, Rails fits the bill.
https://github.com/JamesNK/Newtonsoft.Json/issues/618
Hell, if you're choosing the latter get yourself an Azure description, build a new Mobile Services host and off you go -- Everything you would ever want is included out of the box (including client to server datasync), you only need to figure out what storage and other services you want to use (e.g. Microsoft's PN service for easy crossplatform notifications) and bring along your business logic.