Roundup #23: Building Rider, Async Guidance and Mistakes, Local NuGet Cache

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Building a .NET IDE with JetBrains Rider

Before we get into the technology and architecture of Rider, we must look at where this IDE came from. As far back as 2004, JetBrains was looking at a stand-alone application for the Visual Studio add-in ReSharper. It was never released, but a fully functional prototype was around at that time.

Link: https://www.codemag.com/Article/1811091/Building-a-.NET-IDE-with-JetBrains-Rider

 

Async Guidance

Asynchronous programming has been around for several years on the .NET platform but has historically been very difficult to do well. Since the introduction of async/await in C# 5 asynchronous programming has become mainstream. Modern frameworks (like ASP.NET Core) are fully asynchronous and it’s very hard to avoid the async keyword when writing web services. As a result, there’s been lots of confusion on the best practices for async and how to use it properly. This section will try to lay out some guidance with examples of bad and good patterns of how to write asynchronous code.

Link: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md

 

Correcting Common Mistakes When Using Async/Await in .NET

I’m here to tell a scary story; one of inefficient code and unhandled exceptions. A story about a .NET developer who used async/await, but didn’t fully understand the framework. Their code started experiencing strange bugs. Their app size was strangely large. GASP! Don’t let this happen to you.

In this campfire session, we are diving deep into the world of asynchronous programming to dissect how the .NET compiler handles asynchronous code and we’ll learn how small improvements to our asynchronous code can create huge performance gains.

Link: https://www.youtube.com/watch?v=av5YNd4X3dY

Clear Local NuGet Cache

This is really helpful as your local NuGet cache can get massive (in the gigabytes) with old packages you no longer ever restore.

Link: https://twitter.com/onovotny/status/1054861969910652928

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #22: OSS Library Guidance, .NET Core ThreadPool Starvation, VS2019 Roadmap, Know the Flow!

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Open-source library guidance

This guidance provides recommendations for developers to create high-quality .NET libraries. This documentation focuses on the what and the why when building a .NET library, not the how.

The issue of strong naming is address and actual guidance is actually in the docs now.

Link: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/

Diagnosing .NET Core ThreadPool Starvation

This article is worth a read if you have

  1. A service written in .NET (and in particular .NET ASP.NET Core)
  2. Its ability to service incoming load has topped out
  3. But the machine’s CPUs are not fully utilized (often only using a small fraction of the total available CPU

Link: https://blogs.msdn.microsoft.com/vancem/2018/10/16/diagnosing-net-core-threadpool-starvation-with-perfview-why-my-service-is-not-saturating-all-cores-or-seems-to-stall/

 

Visual Studio 2019 Roadmap

Notable improvements are:

  • A better performing and more reliable debugger, moving to an out-of-process 64-bit process.
  • Improved search accuracy for menus, commands, options, and installable components.
  • Visual Studio tooling for Windows Forms and WPF development on .NET Core 3.

Link: https://blogs.msdn.microsoft.com/visualstudio/2018/10/17/visual-studio-roadmap-updates-and-visual-studio-2019-information/

 

Know the Flow! Events, Commands & Long-Running Services

Strategic design does not stop at defining boundaries around business capabilities – it should reach out for truly smart endpoints, emphasize autonomy and the need for more coarse-grained and asynchronous APIs. The long-running services behind such APIs feel responsible for their business and sort out most problems without leaking internal troubles and bothering their clients. While long-running services will leverage domain events for decoupling, they will often expose their core functions as commands – in order to minimise overall coupling! Extracting the customer-facing core processes of companies into dedicated, long-running services allows to keep sight of larger-scale flows – without violating bounded contexts or introducing god services. In this talk, Martin not only explores strategic design in the light of understanding the long-running nature of delivering many real-life business capabilities. He will also show the practical side of the equation: implementing long-running behaviour of services, requiring proper reactions on failures, timeouts and the compensating actions sagas are known for. A new generation of lightweight, embeddable and scalable saga managers and flow engines assist in that endeavour. Expect real-life experience and many examples!

Link: https://www.youtube.com/watch?v=uSF5hyfez60

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #21: Roslyn, .NET Updates, IMiddleware, Warp, DDD

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Note: I was away last week, hence no roundup.  This week is a bit of catch up.

How Microsoft rewrote its C# compiler in C# and made it open source

Roslyn is the codename-that-stuck for the open-source compiler for C# and Visual Basic.NET. Here’s how it started in the deepest darkness of last decade’s corporate Microsoft, and became an open source, cross-platform, public language engine for all things C# (and VB, which I’ll take as a given for the rest of this piece).

Really interesting read about the history and how it all came together.  I love reading these historical accounts.

Link: https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98

 

Update on .NET Core 3.0 and .NET Framework 4.8

In May, we announced .NET Core 3.0, the next major version of .NET Core that adds support for building desktop applications using WinForms, WPF, and Entity Framework 6. We also announced some exciting updates to .NET Framework which enable you to use the new modern controls from UWP in existing WinForms and WPF applications.

I think this is in a way trying to frame that .NET Framework isn’t dead, although I still feel differently.  Innovation is happening in .NET Core.  It’s ultimately the future even if .NET Framework will always be supported.

Link: https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

 

Why you aren’t using IMiddleware?

The IMiddleware interface is an extensibility point for middleware activation. It defines middleware for application’s request pipeline like the Conventional Middleware where InvokeAsync() handles the requests and returns a Task that represents the execution of the middleware.

Why have I never seen/heard IMiddleware before?  Have you?

Link: http://www.hishambinateya.com/why-you-arenot-using-imiddleware

Warp

Warp lets you create self-contained single binary applications making it simpler and more ergonomic to deliver your application to your customers. A self-contained binary is specially convenient when the technology you use, such as .NET Core, Java and others, contain many dependencies that must be shipped alongside your application.

Warp is written in Rust and is supported on Linux, Windows and macOS.

Pretty cool project for creating a single binary.  Very different then CoreRT however.

Link: https://github.com/dgiagio/warp

 

Eric Evans – Keynote: DDD Isn’t Done: A Skeptical, Optimistic, Pragmatic Look

DDD Isn’t Done. A Skeptical, Optimistic​, Pragmatic Look. We have more experience now. We have better tools now. We have an architectural environment better suited to DDD than the typical 2003 architecture. Certainly, some people are getting a lot out of DDD — but not so very many. DDD has always been difficult, and it still is. And we might be held back by some dogmatic notions of what it should look like.

Link: https://www.youtube.com/watch?v=R2IAgnpkBck

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.