WebAssembly (WASM) and WebAssembly System Interface (WASI) are opening new opportunities for developers. .NET developers became familiar with WASM when Blazor WebAssembly was released. Blazor WebAssembly runs client-side in the browser on a WebAssembly-based .NET runtime. WASI is bringing WASM out of the browser world by providing a system interface to run WebAssembly outside the web. It is a standard for how WASM modules interact with the host environment. This post will show you how to run .NET 7 on a Raspberry PI Zero 2 W using WASM and WASI.

I am using a tool called logseq to manage my notes. It is a fantastic tool, and I would like to be able to extend it. I am not an expert web developer, but I am a .NET developer. I would like to be able to write plugins for logseq using .NET and C#. I have found a way to do it using WebAssembly. In this post, I am going to show you how to do it.

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.