In the past, within my team at Innoveo, we had several discussions about the best way to unit test async WPF ICommand. We value quality, so testing is essential to us. We decided to make the methods called by the command internal so that our tests could call those.

What is the problem with unit testing an Async WPF ICommand? The problem is that the command is an async void method! So, you have no way to await the end of the execution of your command. So, your test might assert on things that are still executing.

Early in my journey in developing software, I used to start a project by setting first a way to build my software automatically each time I did a set of changes. Long, very long ago, I used scripts scheduled to run. When JetBrains shipped TeamCity I started to use it extensively for my projects, here is my first post about “Set Up a Build Computer using VisualSVN, Team City, MsTest, NUnit“ from March 21, 2008, but used it since version 1.0. Later on, I also used Azure Pipelines to build Git Diff Margin and also GitHub Actions, for example, to build and deploy those pages.

Till now, we have seen two Dapr building blocks which are the service to service invocation building block and the secrets building block. The secret building block serves to protect things like a database connection string, an API key… so that they’re never disclosed outside of the application. The service to service invocation building block serves to make calls between services in your distributed application easy. In this post, we will introduce a third one which is the bindings building block. The bindings building block enables your distributed application to handle external events or invoke external services.

In all previous posts, we were looking at the Dapr service invocation building block. We have seen how to expose and call HTTP and gRPC services using it. In this post, we will see how Dapr ease developers life when it comes to deal with secrets, thanks to the secrets management building block.

In previous posts, we focused on Dapr service invocation using the HTTP protocol. Dapr, through its service invocation, can also reliably and securely communicate with other applications using gRPC. We will have a look at this other capability in this post.

In the last post, we have seen how to call a service from another service using the Dapr .NET SDK. In this one, we will have a look at a possible way to simplify the development of the client code using Refit, the automatic type-safe REST library for .NET Core, Xamarin, and .NET.

In the previous two posts, we tackled the way to start with Dapr and how to call services. In this one, we will see how we can leverage the Dapr .NET SDK to handle service to service calls.

• Getting started with Dapr for .NET Developers
• Using Service Invocation from Dapr .NET SDK

In the previous post “Getting started with Dapr for .NET Developers“ we have seen how easy it was to expose a web API written in .NET and the power of exposing it through Dapr sidecar. In this post, we are looking at the different possible ways to invoke that service.

Dapr for .NET Developers is a great book, read in a weekend, to start gaining an understanding of what Dapr is and especially for .NET Developers. In this post, we will see how you can use .NET to create a service and run it with Dapr and what does this provides.

I am using Git for many, many years. I am a big fan of it. How could that be different when you had to use versioning systems like CVS, SVN… I even took influence so that the whole company I work for migrates to it.

Over the years, I have used different Git clients, tried to work only from my IDE without much liking it.