The art of simplicity

So far I’ve always used ProxyKit to create a reverse proxy in ASP.NET Core. But with the announcement of Yarp , it is time to try this alternative… I created a new ASP.NET Core “empty” project: dotnet new web -n ProxyTest -f netcoreapp3.1 The template "ASP.NET Core Empty" was created successfully. Processing post-creation actions... Running 'dotnet restore' on ProxyTest\ProxyTest.csproj...   Restore completed in 278,54 ms for C:\Projects\test\yarptest\ProxyTest\ProxyTest.csproj. Restore succeeded. Next step is to reference the Microsoft.ReverseProxy preview nuget package: <ItemGroup> <PackageReference Include="Microsoft.ReverseProxy" Version="1.0.0-preview.1.*" /> </ItemGroup> Now it is time to update our Startup.cs. This is what I had when using Proxykit: And here is the updated Startup.cs after switching to Yarp: In Yarp everything ...

While in traditional REST API’s versioning is a hot topic, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema. As GraphQL only returns the data that is explicitly requested, it becomes easier to introduce new functionality by adding new types and fields without introducing breaking changes. As you know what fields are used by which clients you can have a lot more knowledge in your hands to prevent breaking your clients. For small schema’s it can be feasible to inspect your schema for changes manually but for larger schemas or federated schema’s good tooling becomes a necessity. A tool that can help you to achieve this is GraphQL Inspector . It offers the following (free) features: Compares schemas Detect breaking or dangerous changes Schema change notifications Use serverless functions validate changes Validates Operations and Fragments against a schema Finds similar / duplicated...

A colleague shared the following hands-on-lab with me: https://github.com/microsoft/MCW-App-modernization It’s a great starting point to learn about the cloud and take your first steps towards it. It combines a whiteboard design session and a hands-on-lab. This is wat you will design and build:

Although I try to make my API’s as descriptive as possible, sometimes good documentation can still make a difference. One way to enable documentation generation is through Visual Studio: Right click on your project and select Properties . On the Properties window go to the Build tab. Check the XML documentation file checkbox Don’t forget to save these changes. As a result the following is added to your csproj file: There are a few things I don’t like about this: First a condition is applied to the PropertyGroup which doesn’t seem necessary Second an absolute path is used to define where to generate the documentation XML So I would recommend no longer to use this approach. What you can do instead is directly manipulate the csproj file and add the following line to a PropertyGroup:

With the growing usage of mono-repositories the standard git checkout or git status no longer work and become frustrating slow. A solution would be to use Git LFS (Large File Storage) but not all repositories have this extension installed. An alternative solution can be provided through the (new) git sparse-checkout command. To restrict your working directory to a set of directories, run the following commands: git sparse-checkout init git sparse-checkout set <dir1> <dir2> ... If you get stuck, run git sparse-checkout disable to return to a full working directory. Remark: this feature is part of git 2.25 . So if the command is not recognized check your git version and update first. More information: https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/

When trying to execute dotnet restore during a build it failed with the following error message: 2020-05-12T18:14:36.8332220Z C:\Program Files\dotnet\sdk\3.1.201\NuGet.targets(536,5): error :   The '@' character, hexadecimal value 0x40, cannot be included in a name. Line 6, position 35. [D:\b\4\agent\_work\200\s\IAM.Core\IAM.Core.csproj] 2020-05-12T18:14:36.8820520Z      2>Done Building Project "D:\b\4\agent\_work\200\s\IAM.Core\IAM.Core.csproj" (_GenerateRestoreGraphProjectEntry target(s)) -- FAILED. 2020-05-12T18:14:36.9152564Z      1>Project "D:\b\4\agent\_work\200\s\IAM.Core.Tests\VLM.IAM.Core.Tests.csproj" (1) is building "D:\b\4\agent\_work\200\s\IAM.Core.Tests\IAM.Core.Tests.csproj" (1:5) on node 1 (_GenerateRestoreGraphProjectEntry target(s)). 2020-05-12T18:14:36.9162330Z      1>C:\Program Files\dotnet\sdk\3.1.201\NuGet.targets(536,5): erro...

I created a small security library in .NET Core that simplifies the rather complex security setup we have at one of my clients. Inside this library I’m using the IMemoryCache to cache some non-volatile data. When a colleague tried to use this library he told me that he had to add the following line This doesn’t seem unexpected but the strange this was that in my example project I nowhere added this!? Time to investigate… A walk through the ASP.NET Core source code (always a fun experience to discover and learn something new about the framework) learned me the following; when you call AddMvc() or AddResponseCaching() the framework will register for you an IMemoryCache behind the scenes. If you are using a lower level method like AddControllers() this is not the case. Learned something? Check!