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

Just curious what dependencies are causing you so many issues?

Skype for Business SDKs, primarily. That is basically our business. Teams is the new hotness, but doesn't have any Api access.

Makes 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").

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

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

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

EF6 is part of .NET Core 3.0: https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on...

Partially, there is no guarantee of all EF 6 related tooling like the data designers will fully work with the Core 3.0, just the actual code execution.

How is it nicer? It's a .NET shop but devs are free to use linux as their OS?

It 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/06221...

[0] https://code-maze.com/global-error-handling-aspnetcore/#buil...

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

Frankly 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,%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.

One 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-benchm...

As well as the underlying .NET Core framework, and .NET in general. We have great new memory types like Span<T> and Memory<T> and tiered compilation, along with thousands of other improvements that has made major improvements in performance.

Which aren't being fully backported to .NET Framework, whereas many libraries still don't run on Core.

So? We're talking about .NET Core here. These new APIs are compatible with netstandard, so they can still be used with Framework but wont be as fast. What libraries are using these newer APIs but refusing to target Core?

ODP.NET for example.

Managed ODP.NET for Core is a partial implementation of the ODP.NET for the full .NET Framework.

Libraries using EF 6, because EF Core is still playing catchup with EF 6, and even .NET Core 3.0 won't support 100% of the EF 6 tooling.

Libraries using WCF, which lack budget for anyone to rewrite them and the respective clients into other transport protocols.

Plenty of other examples.

Well 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-ar...

I think many were more concerned about .NET performance against tech in the same class, mainly the JVM, which previously blew .NET out of the water in the benchmarks for a number of years.

From 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."

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

I saw claims of a 30% perf increase moving to .net core for a major software company. Can't remember which one, but that's still pretty impressive...

Perhaps you're thinking of Microsoft moving Bing to ASP.NET Core 2.1, with a 34% performance improvement: https://blogs.msdn.microsoft.com/dotnet/2018/08/20/bing-com-...

I see - good point.

Mono has always had terrible performance. It was mostly useful as a way to sell developers who wouldn't normally go for a Windows-only solution on something that was effectively Windows-only in practice, if you cared about things like performance.

Also not tied to visual studio to build. `dotnet` is an node style command line tool.

You haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.

But 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).

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

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

Ah, 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.

Correct. It wasn't really usable.

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

You'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.

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

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

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

^ that's now how Docker works. aka, the whole point of Docker is it doesn't matter what the host OS is.

That'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.

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

I'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.

Docker can also make use of Windows containers.

I know, which is why I said Linux containers. Although, Docker on Linux can't run Windows containers, can it?

Certainly not, containers are a kernel level feature.

You're right on that, but there's no "OS" inside of a container to speak of.

A 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. :)

Yes, 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.

VS is a pain point? It remains one of the best IDEs out there IMO. What are your specific issues with it, aside from needing to run it on Windows?

I loved VS, having used it since it was MSVC.

The UX of VS2013 was the tipping point for me. And they removed macros. Dropped setup projects with no real upgrade path. The direction it moves is what benefits Microsoft.

And the cost has become unjustifiable, now that it's no longer a "must have".

Without ReSharper (which just adds to the bloat), it's primitive (but improving).

The debugger, however, has always been the best I've used.

I think VS is painful.

It's slow to open. It crashes frequently. It's hard to extend. It's absolutely AWFUL on system resources. Its settings are a complete clusterfuck (admittedly, mainly because it tries to be/do absolutely everything).

I also think VS is actually a bad teaching tool for new developers. It simply tries to hand-wave/magic away parts of the system you're working on that REALLY matter. It's like VS is stuck in the era where the idea of opening a configuration file in a text editor is "uncouth". Which is frankly insane, since navigating the frustrating and byzantine guis it throws up instead is an absolute nightmare. Worse, you really need to care about those config files and settings, having them hidden helps nobody.

Basically, I think VS Code is a better IDE (yes, IDE, not editor) in every way. It takes more work to get off the ground, but it's literally miles away a better experience.

Then use VS Code?

But as a .NET developer of over 15 years now I disagree. VS Code is currently using 1,200 MB of ram on my machine while Visual Studio is using 1,700 MB. I have a much larger project open in visual studio. Out of the 64 GB of ram on my machine, this isn't even a factor. What kind of machines are you running on where this is actually a problem?

VMs

VS + Resharper (or better yet + VsVim) is a miles better experience

next on the list after VS would be Rider,

then VScode...

I cannot remember the last time Vs crashed, a bit slower to open, but percentage wise, I spend hardly any time opening it. Extensions are sort of more involved to set up, but it's not that hard to do. It uses a bunch of resources, but I have lots of resources for it, settings don't seem too out of the ordinary, like most things, it just works out of the box and has a deep set of settings to customize it.

Resharper absolutely tanks my performance. Not only does it slow down cold start by ~5x, it introduces input lag on each keystroke. Back in VS2013, R# was indispensable, but with VS2017 the only feature I miss is namespace refactoring. It's also clunky how it gives you effectively two IDEs with two databases mushed into a single window.

I'm trying to wean myself onto VS code now (with vim keybindings), but being forced to stay in a single window is tough to swallow.

I keep being disappointed by performance on InteliJ products.

Maybe because I don't have 16 GB, Xeons with SSD at my disposal?

So far Eclipse and Netbeans still outperform them, unless I turn on laptop mode and disable the majority of plugins.

I have no clue why VS is so bad. You would hope that as a commercial and primary development tool for a company as large as MS, they would be able to make it stable and fast. It's horrible. But so is XCode... I guess both try to cram in too much features and developers will (have to in many cases) use it anyway.

What kind of requirements fit .NET best?

I'm trying to decide between .NET and Rails 4 for a new project.

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

Start by asking yourself whether you like static typing.

REST API + frontend framework => .NET

Greater than or equals..... ?

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

Looks like a Scala type alias to me.