Demystifying .NET Core and .NET Standard

There has been much confusion about .Net Core and .Net Standard and why they have come about, I have added a good article by Microsoft about how to demystify the difference between them.

.Net Core 1 was release first and was the first iteration in the .Net Core stack to offer a new approach to developing using the .Net technology. Recently however .Net Standard has been introduced in order to provide some cross compatibly between various mobile technologies and applications. When this was announced many of the early adopter of .Net Core questioned this and the amount of time and resources already invested in applications, they demanded that .Net Standard be integrated with .Net Core.


When would we use one over the other?

This decision hinges on the technology requirement of compatibility that .Net Standard provides over the vast number of APIs available to .Net Core.
.Net Core increases the Api access surface area available however its implementation allows only those that target .Net Core applications.

.Net Standard however can be used by any application that targets the specific .Net Standard version but has a decreased Api access surface area.
An example of this would be if the .Net Standard version 1.4 was being used in a specific application, then all those applications that also target that version are able to support the .Net Standard version. On the other hand they will not have access to some Api parts such as the microsoft.netcore.coreclr.


What are the differences in the Api surface area?

.Net Standard applications include the netstandard.library, whereas .Net Core includes which has around 20 additional libraries that’s available to it. 
.Net standard can be added manually but some functionality will not be compatible such as Microsoft.NETCore.CoreCLR. However the trade-off is that .Net Standard increases portability and all the benefits it brings is this new age of mobile first development. It also provides a contract agreement between applications as to what versions they are targeting agree to. .Net Standard exists to run on multiple runtimes whereas .Net Core provides an increased surface area and have to specify the platform that the application is run against.


Read original article

Eliding Async and Await

Being able to elide Async and Await can provide application efficiency benefits that at first may seem minimal but in the big picture will result in the compiler being able to skip the generation of the async state machine and result in fewer compiler generated types in the assembly as well as fewer items added to the GC and CPU computations.

When a async state machine is generated for a single await, you can effectively get a few extra IL instructions created as a result. In my opinion it is a benefit to elide await where possible but in some cases it isnt such as using statements.

Async does have great benefits such as performing code executions in parallel requests but it does however perform in a much more inefficient way than using synchronous code. Adding more awaits and async’s to an application ends up multiplying the cost at each point.

You can read more about it here:-