Roundup #38: Port Desktop App to .NET Core 3, Building 300+ csproj, .NET Core 3 Progress, Four Languages from Forty Years Ago

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

How to port desktop applications to .NET Core 3.0

In this post, I will describe how to port a desktop application from .NET Framework to .NET Core. I picked a WinForms application as an example. Steps for WPF application are similar and I’ll describe what needs to be done different for WPF as we go. I will also show how you can keep using the WinForms designer in Visual Studio even though it is under development and is not yet available for .NET Core projects.

Link: https://devblogs.microsoft.com/dotnet/how-to-port-desktop-applications-to-net-core-3-0/

How do you all build really large .NET repos (like more than 300 .csproj)?

This is a really interesting thread. I can’t imagine building 300+ projects. I currently have a solution with just around 50 and I’m always trying to reduce it. What type of projects are people working that require 300+ projects?

Link: https://twitter.com/natemcmaster/status/1099021447920406529

.NET Core 3.0 Progress on Bugs

Link: https://twitter.com/ziki_cz/status/1100865306484850688

Four Languages from Forty Years Ago – Scott Wlaschin

The 1970’s were a golden age for new programming languages, but do they have any relevance to programming today? Can we still learn from them?

In this talk, we’ll look at four languages designed over forty years ago — SQL, Prolog, ML, and Smalltalk — and discuss their philosophy and approach to programming, which is very different from most popular languages today.

We’ll come away with some practical principles that are still very applicable to modern development. And you might discover your new favorite programming paradigm!

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

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #37: .NET Core 1.x End of Life, gRPC, GraphQL, Benchmarking, Life Beyond Distributed Transactions

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

.NET Core 1.0 and 1.1 will reach End of Life on June 27, 2019

.NET Core 1.0 was released on June 27, 2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reach end of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.

After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.

Link: https://devblogs.microsoft.com/dotnet/net-core-1-0-and-1-1-will-reach-end-of-life-on-june-27-2019/

gRPC for dotnet

https://twitter.com/davidfowl/status/109287056804556800

We plan to implement a fully-managed version of gRPC for .NET that will be built on top of ASP.NET Core HTTP/2 server. Here are some key features:

– API compatible with the existing gRPC C# implementation (your existing service implementations should work with minimal adjustments)
– Fully interoperable with other gRPC implementations (in other languages and other platforms)
– Good integration with the rest of ASP.NET Core ecosystem
– High-performance (we plan to utilize some of the cutting edge performance features from ASP.NET Core and in .NET plaform itself)
– We plan to provide a managed .NET Core client as well (possibly with limited feature set at first)

We are committed to delivering the managed server experience Microsoft.AspNetCore.Server functionalities in ASP.NET Core 3.0 timeframe. We will strive to also deliver the mananged client experience in 3.0.

Link: https://github.com/grpc/grpc-dotnet/

Adding a GraphQL Endpoint to Your ASP.NET Core API

Since GraphQL support is not provided within ASP.NET Core, you need a Nuget package. The one most commonly used is simply called GraphQL .NET. Which is available as open source thanks to Joe McBride and all contributors. When you install the package GraphQL.Server.Transports.AspNetCore you’ll get it as a dependency as well as everything you need to hook in into ASP.NET Core. Now that we’re here I also install GraphQL.Server.Ui.Playgroundwhich will enable me to test the API in the way I did when I showed you the products query.

Link: https://rolandguijt.com/adding-a-graphql-endpoint-to-your-api/

Introduction to Benchmarking C# Code with Benchmark .NET

Once you have narrowed your focus to particular areas of your code you start to get down to the method level. At this point, it’s useful to begin recording more accurate and specific benchmarks for your existing methods and code. This is where benchmarking should become your tool of choice. In C# we have a fantastic option in the form of Benchmark.NET. This library provides a vast array of benchmark tooling that can be used to measure and benchmark .NET Code. Benchmark .NET is now regularly used by the teams at Microsoft to measure their code.

Link: https://www.stevejgordon.co.uk/introduction-to-benchmarking-csharp-code-with-benchmark-dot-net

Life Beyond Distributed Transactions: An Apostate’s Implementation – Jimmy Bogard

Over a decade ago, Pat Helland authored his paper, “Life Beyond Distributed Transactions: An Apostate’s Opinion” describing a means to coordinate activities between entities in databases when a transaction encompassing those entities wasn’t feasible or possible. While the paper and subsequent talks provided great insight in the challenges of coordinating activities across entities in a single database, implementations were left as an exercise to the reader!

Fast forward to today, and now we have NoSQL databases, microservices, message queues and brokers, HTTP web services and more that don’t (and shouldn’t) support any kind of distributed transaction.

In this session, we’ll look at how to implement coordination between non-transactional resources using Pat’s paper as a guide, with examples in Azure Cosmos DB, Azure Service Bus, and Azure SQL Server. We’ll look at a real-world example where a codebase assumed everything would be transactional and always succeed, but production proved us wrong! Finally, we’ll look at advanced coordination workflows such as Sagas to achieve robust, scalable coordination across the enterprise.

Link: https://www.youtube.com/watch?v=IMvrg0bN9-o

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #36: Server GC in a Small Containers, Simple-Exec, Why your ASP.NET Core Application Won’t Scale

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

Running with Server GC in a Small Container Scenario Part 1 – Hard Limit for the GC Heap


I’ve checked in 2 configs related to specifying a hard limit for the GC heap memory usage so I wanted to describe them and how they are intended to be used. Feedback would be greatly appreciated.

In order to talk about the new configs it’s important to understand what consists of the memory usage in a process. When it comes to memory the terminology can be very confusing so it’s worth pointing out that by “memory” I meant private commit size. A process can have the following memory usage from the runtime’s POV:

-GC heap usage – this includes both the actual GC heap and the native memory used by the GC itself to do its bookkeeping;
-native memory used by other things in the runtime such as the jitted code heap;
-native memory used by something that’s not the runtime, eg, you are allocating native memory in your pinvoke calls;

We cannot control 3) and it could be significant. 2) is in general small compared to 1).

Link: https://blogs.msdn.microsoft.com/maoni/2019/02/04/running-with-server-gc-in-a-small-container-scenario-part-1-hard-limit-for-the-gc-heap/

simple-exec

SimpleExec is a .NET library that runs external commands. It wraps System.Diagnostics.Process to make things easier.

SimpleExec intentionally does not invoke the system shell.

The command is echoed to standard error (stderr) for visibility.

Platform support: .NET Standard 1.3 and upwards.

Link: https://github.com/adamralph/simple-exec

Why your ASP.NET Core application won’t scale – Damien Edwards, David Fowler

Hey my app doesn’t scale! ____ Framework sucks! Well, you can write a slow app in any language. David Fowler and Damian Edwards will show you why your app isn’t scaling and gives you the DOs and the DON’Ts of making big apps do big things in ASP.NET Core.

We’ll talk about async, parallelism, and appropriate use of multiple threads. Are you misusing some APIs and inadvertently crashing your apps?

David Fowler and Damian Edwards, will show you the errors of your ways and make sense out of these techniques and when they’re useful – or when they should be avoided.

This will be a demo-heavy and highly technical session.

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

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.