Jon Bock - Development Tech Blog

Today I was lucky enough to attend Microsofts future decoded event in London excel centre, as usual there was numerous talks that were of interest but as always, I had to diligently choose the ones that were of more interest to me.

For those who haven’t attended this Microsoft event before, this offers Microsofts insight into their vision of tomorrow, talks centre around what technologies and strategies Microsoft are investing in and that they would like us to pay attention to.

The keynote delivered essentially Microsofts sales pitch on their new surface, surface book and Microsoft hub devices and how they can leverage Microsoft collaborative web spaces to bring teams together from different locals. They gave a demonstration on the hub of how an individual in the audience is able to create story board sketches to the workspace, adding drawings and updating ordering of the drawings. At the same time, another team in the US is able to upload various photos to the same work space and rearrange them in any particular order.

This collaborative and seemingly lag free workspace sharing looks like an ideal solution to bring various teams together, and as I have found when working with various personnel spread over multiple locations this real-time update helps to not create bottlenecks in waiting for / delivering information to each other.

We also had a glimpse of HoloLens and Microsoft leveraging augmented reality and how it can be used in the business place. Panos Panay demonstrated how simply using the surface and the AR app, we are able to drop an augmented hub into the room, and side by side with a real hub, we can see how realistic it is and envision what it would actually look like in real life.

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 microsoft.netcore.app 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 https://msdn.microsoft.com/en-us/magazine/mt842506

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

https://blog.stephencleary.com/2016/12/eliding-async-await.html