Announcing .NET Core 2.1

> If you write code on .NET, you should adopt this release ASAP.

That really depends what classes you use. There are still a lot of classes that haven't been implemented in .Net Core and many of them supposedly won't be implemented. Others were re-implemented and renamed and might not match features. You'll want to move to .Net Core eventually, but not every .Net release is going to be easy to move. Moving from .Net Framework to .Net Core is like moving from .Net Framework to mono. It's mostly similar, but it's still wholly different and not intended to be a 100% drop in replacement.

The Microsoft.Windows.Compatibility namespace isn't new at all. At least that's what the Windows Compatibility Pack for .Net Core [0] used at the end of 2017. It looks like it might just finally be out of the preview stages.

[0]: https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcin...

> If you write code on .NET, you should adopt this release ASAP.

If you require the new features maybe, but if you are writing enterprise code, you shouldn't rush into things.

> Doubly so if you care about runtime performance.

Everyone cares about runtime performance, but if your software isn't experiencing performance issues, there is no need to rush into things. Or at the very least, reach out to your clients to get a feel about their schedules and expectations.

#1 rule: if it ain't broke, don't fix it.

> If you write code on .NET, you should adopt this release ASAP. Doubly so if you care about runtime performance.

I care about performance, but:

Still have customers on .NET 4.0.

.NET Core 2.1 doesn't do EF6, Forms or WPF, need to wait for 3.0 for that.

Not all third party libraries are already on Core.

Given all that, Core 2.1 is full of goodies that I will surely play around with.

Where can I find out more about Channel<T>? I've been googling but it's hard to find anything (especially as Channel 9, and old WCF channels comes up a lot in the results).

Unfortunately it's still a non-starter, because so many things I need that are also Microsoft SDKs are not ported, nor are they likely to ever be.

Also, we need a GUI, of some kind.

Thanks for the gist with the channels implementation.

I wish they worked on their release notes with samples for all the smaller features like formatters, pooling and channels. Too much of it is buried in github issues.

Channel<T>? Where is anything on that please?

is Span<T>/Memory<T> and Channel<T> supported for use in F#?

wow, this is huge for some use cases!

If you are at the application level then you can use whatever, but Span<T> is pretty handy. If you are calling an method that has both Span and Array overloads, prefer the Span version since it is less likely to copy or allocate.

The real selling point is that Span is much more flexible than an Array. Both Managed and Unmanged memory can work with it. If you load a big string and need to get each line from it, you can slice into the middle of the string safely and get a ReadOnlySpan<char> that supports most 'string' operations without allocating any memory.

Or imagine you need to process some huge file, typically you would read it chunk by chunk copying the data from the Stream into some byte[]. But with Span you could open a Memory Mapped File and work on segments of the file without copying into temp buffers.

You gain a lot by avoiding memory copies and by allocating fewer objects (less work for the GC). For some workloads then can be a huge speedup.

If you take substrings of strings; using string.AsSpan() then allows you to work it as a Span<T> and take windows of the string without allocating an new string for the substrings.

Also it means you can now pass readonly arrays (the elements) to things using ReadOnlySpan<T>; so don't have to do defensive copies

Span (safely refers to data anywhere) and Memory (safely refers to data on the heap only) have a much nicer API than arrays. ArraySegment has had a facelift but to nit: ArraySegment is a pain to type. Also, unlike arrays, there are read-only variants - which are good for rich type checking. In addition you can easily reinterpret cast between blittable types (the new 'unmanaged' generic constraint) for when you are participating in mortal sins such as directly serializing byte representations.

Tons of reasons to use them besides performance. We use them for those reasons and if there is a performance boon, great bonus!

Correct. Most developers will not deal with it much directly, particularly not in the way that it is used in the "guts" of the product.

It can help prevent allocations if you work with large arrays or strings

Few points:

- Deployments: https://www.microsoft.com/net/customers

- Monthly engaged developers is >500k for NET Core.

- >50% of developers are on Windows.

It's growing rapidly and .NET Core is definitely ready for production, has been for the last 2 years.

It's not a simple subset of .NET Framework, there are distinct differences and cross-platform is just one ability. It's also smaller, faster, and allows for self-contained deployments that can run with other apps using different framework versions on the same machine. Also very simple to use in containers.

https://docs.microsoft.com/en-us/dotnet/standard/choosing-co...

> Is there any data on the size of the .NET Core user base? It was my impression that .NET Core was unsuitable for production deployments so far.

.NET core is a fully supported option on Google's AppEngine via flexible instances, so I think it's stable enough for production deployments.

UWP uses .NET Core alongside .NET Native toolchain.

Now with .NET Core 3.0 roadmap and MSIX containers, their are slowly merging Win32 and UWP worlds.

I've been moving some libraries over from T[] to Memory<T> and Span<T>.

I've found it's a little tricky to get used to calling Slice() all the time. But it opens up so many doors for allocation reduction and perf improvement.

Also, it is so nice to not have to pass (array, offset, length) around everywhere

No relationship to the 18.04 LTS, but we were following that release closely. We started testing on 18.04 at the start of the year, and offering Docker images for it at around the same time. We're also watching the Alpine 3.8 release closely.

What do the two have to do with each other? I'd say it's a coincidence, I don't think MS is trying to steal Canonical's thunder or anything.

Sorry! Poor wording on my part.

I updated the wording to: "Much easier to manage .NET Core and ASP.NET Core versions in project files and with self-contained application publishing."

The thing that you are talking about still needs to be improved. Sadly, that didn't happen in this release.

Why more if you have good oo, procedurel and functional contenders :). C# and F# are top contenders in their areas.

Language alternatives show up by need (not given here) or specialization (niche you never heard of).

There are scattered few. Leppie has maintained IronScheme for years now and the good folks as Peachpie have PHP running on CoreClr(via Roslyn even!)

So the .NET Core SDK and command line tools do not require VS at all. VSCode works fine or whatever editor you like that supports omnisharp.

But if you are using VS you will need to update to 15.7 to take advantage of some of the features/

Core is a portable re-implementation of the Framework

https://docs.microsoft.com/en-us/dotnet/standard/choosing-co...

Biggest difference is core is cross platform.

For Channel<T>, you can take a look at https://github.com/dotnet/corefx/tree/v2.1.0/src/System.Thre...

It depends on your app. We've seen massive improvements for webservers and long-running apps. Short-lived apps don't benefit. We'll be posting more on it soon. Give it a try!

Right now I wouldn't expect much. I did some very very rudimentary benchmarks and saw a slight drop in perf using Tiered Compilation.

But now that it exists we can expect regular improvements with every point release.