9 ms·
This is good news I think. The fragmentation is quite annoying and not needed I believe. We moved everything (15 years of code) to Core 2 and it was not a lot o
by tluyben2 8y ago
This is good news I think. The fragmentation is quite annoying and not needed I believe. We moved everything (15 years of code) to Core 2 and it was not a lot of work. I could not be happier; the experience for developers is so much nicer.
- nobody271 8y agoHow is it nicer? It's a .NET shop but devs are free to use linux as their OS?
- SolarNet 8y agoAlso not tied to visual studio to build. `dotnet` is an node style command line tool.
- lkitching 8y agoYou haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.
- hermitdev 8y agoYou've never needed Visual Studio to build .Net projects. They have supported MSBuild from v1.0, you just needed to write the project files by hand - a very tedious process. It's just that building from Visual Studio is by far the most convenient method.
- pjmlp 8y agoMSBuild was introduced around .NET 2.0 after Ant's introduction in the Java world. Before there was a project format, callable with devenv command line tool.
- rblatz 8y agoSpeaking of the project files, the new csproj format is my favorite thing. We used to always get conflicts in them, and now we basically never do.
- svick 8y agoBut there was no good way to edit .csproj files without an IDE and you needed to edit them for every source file you added (or moved). Now you don't have to edit them as often (wildcards for files), they're easier to edit by hand (because they contain almost no clutter) and there are also command line tools to edit them (like dotnet add package).
- SuddsMcDuff 8y agoWildcards have been supported for source files for many years. <Compile Include="**/*.cs" /> I was doing this back in the .NET 3.5 days. But nitpicking aside your point is well taken, the developer experience is far better with dotnet core.
- svick 8y agoAs I understand it, if you ever opened such project in VS, it would replace the wildcard with the current list of files. So the usability of that approach was very limited.
- moogly 8y agoCorrect. It wasn't really usable.
- SuddsMcDuff 8y agoAh, I see. I wasn't using VS (which is why I found the wildcard trick). It seems like VS was the issue then, and one of the reasons donet core has a better experience is because it's much less bound to VS.
- sorrymate 8y agoIt also makes running Docker a whole lot easier. I know there is Docker for Windows, but it feels like a red headed step child compared to Docker on Linux.
- coreyh14444 8y ago^ that's now how Docker works. aka, the whole point of Docker is it doesn't matter what the host OS is.
- nchie 8y agoThat's not really true, OS definitely matters with Docker, both on the host and the container. Docker for Windows uses a VM to run Linux containers.
- danielhlockard 8y ago> OS definitely matters with Docker, both on the host and the container. What OS in the container? A docker container is not a VM. Most of my containers are on the order of 10s of MB, and just contain a single binary.
- nchie 8y agoI'm not disagreeing to any of that, what I'm saying is that to run a Linux Docker container on Windows, you'll need a Linux VM which runs Docker, which is exactly what Docker for Windows does for you using HyperV.
- danielhlockard 8y agoYou're right on that, but there's no "OS" inside of a container to speak of.
- nchie 8y agoA 10mb Linux container will still share the Linux kernel with the host, hence it's still running on Linux, even if it doesn't have any dynamic dependencies. There's no OS "inside" the container, no, but it's still dependent on an OS. I think we agree. :)
- tluyben2 8y agoAnd Mac OS X, also a lot of work was done to make Core nice; it builds fast, low latency for ASP.NET and more. I use vim under Linux and I could not be happier. I was always against the choice for .NET because of the lock in; now that that is gone, it is great.
- mr_overalls 8y agoOne improvement that doesn't get enough attention, IMHO, is that Asp.net core is now performant as hell. https://www.techempower.com/blog/2016/11/16/framework-benchmarks-round-13/ https://www.techempower.com/blog/2016/11/16/framework-benchm...
- ksec 8y agoWell it has always been performant. The whole Stackexchange is built with ASP.net, and it render things 10x faster than Ruby Rails while requiring 10x less hardware resources. [1]https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
- mr_overalls 8y agoFrom the Techempower blog post I linked to above: "The degree of improvement is absolutely astonishing, going from 2,120 requests per second on Mono in Round 11 to 1,822,366 requests per second on ASP.NET Core in Round 13. That’s an approximately 85,900% improvement, and that doesn’t even account for Round 11’s hardware being faster than our new hardware. That is not a typo, it's 859 times faster! We believe this to be the most significant performance improvement that this project has ever seen."
- svick 8y agoIn the past, TechEmpower benchmarks only ran on Linux, so their benchmarks for .Net actually used the Mono project's implementation of ASP.NET, which was slow. That's why the increase was so significant. If they were comparing ASP.NET Core with .Net Framework on Windows, the difference would have almost certainly been much smaller.
- mr_overalls 8y agoI see - good point.
- nicoburns 8y ago
- Someone1234 8y agoIt is a completely different architecture from the ground up, completely re-written with modern development in mind. For one example it has native support for dependency injection, and in general testability has massively improved since it was a core design goal. They've also de-coupled several layers, which is hugely powerful since you can write your own middleware. For example check out this article on "Handling Errors Globally with the Custom Middleware"[0]. If you want to see how different it is from .Net Framework look at this diagram: https://msdnshared.blob.core.windows.net/media/2017/06/062217_2209_ThenewNETAp12.png https://msdnshared.blob.core.windows.net/media/2017/06/06221... [0] https://code-maze.com/global-error-handling-aspnetcore/#builtinmiddleware https://code-maze.com/global-error-handling-aspnetcore/#buil...
- sk5t 8y agoThe diagram (and your comment) appear to be about ASP.NET and don't tell anything about .NET Core compared to, say, .NET Framework 4.5.
- Someone1234 8y agoFrankly because nothing outside of the .Net Core's Web/Asp.net/MVC/WebAPI improvements actually matters. And the changes there are massive and significant. While you can technically create Forms, WPF, and UWP applications using .Net Core on Windows, that isn't really the direction or focus of the framework. Just a niche for legacy software or people who continue to need Windows specific desktop applications. https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2Fm%2F03f8ny,Windows%20Presentation%20Foundation,uwp,%2Fm%2F07sb4tb https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2F... Console applications might have a future for cross-platform headless sever loads. But outside of that it is a web framework that happens to support non-web projects on the side. It is competing primarily with e.g. Java, Ruby on Rails, Node.js, PHP, etc.
- thrower123 8y agoIt really depends on how much you are dependent on third parties that don't update. I've been stalled at 3.5 then 4.5 waiting on my dependencies in the past.
- Someone1234 8y agoJust curious what dependencies are causing you so many issues?
- thrower123 8y agoSkype for Business SDKs, primarily. That is basically our business. Teams is the new hotness, but doesn't have any Api access.
- Someone1234 8y agoMakes sense. They keep claiming Skype for Business is dead, but Teams in my opinion is very far away from being a realistic replacement. I've not been very impressed with the desktop application at all (although the web-site is "fine").
- jgalentine007 8y agoI have deployed teams in 'island' mode for our org and I'm a bit disappointed with it - we've had firewall problems with external attendees and have had to switch back to skype for that case. A few users have had the teams client crash repeatedly during calls. I don't see how anyone will move to it with issues like these.
- maxxxxx 8y agoCould you encapsulate these dependencies into a separate service? I did that a while ago in a similar situation but as always it depends on your specific situation.
- breakingcups 8y agoOne big one that isn't mentioned yet is Entity Framework. Now, before you say "But there's an Entity Framework Core!" it's not the same at all. It has nowhere near the same amount of features and performance nor integration into Visual Studio like EF has. This is the biggest blocker for us to move completely to .NET Core.
- jenscow 8y agoYes, I'm glad of it too. I no longer need Windows to develop nor host, while keeping on a platform which is hard to beat (for my requirements). This isn't change for the sake of it, it's to keep .NET relevant. VS and Windows have become pain points.
- copperx 8y agoWhat kind of requirements fit .NET best? I'm trying to decide between .NET and Rails 4 for a new project.
- jenscow 8y agoI chose core over node, because it has a better standard library with less 3rd party reliance. On my last project, dealing with the multiple layers of dependencies with node became troublesome. (static vs dynamic has equal balance, in my experience) However, if it where not for Linux support (and Rider), I would have gone with node.
- oblio 8y agoREST API + frontend framework => .NET
- abledon 8y agoGreater than or equals..... ?
- jbigelow76 8y agoHow soon we forget. That is obviously a CoffeeScript fat arrow function, after you're done adding the Rest API to the front end you callback to the .NET framework to execute it.
- sk5t 8y agoLooks like a Scala type alias to me.