Skip to main content


Visual Studio–Share your settings

In VSCode you can share your settings through profiles . This allows you to easily apply your UI layout, settings and extensions to multiple VSCode instances. A similar thing is possible in Visual Studio. Settings can be exported through the Import and Export Settings Wizard: Go to Tools –> Import and Export Settings Choose Export selected environment settings and click on Next > Now you can choose which settings should be exported. Check or uncheck the settings you want to export and click on Next > Specify where you want to store your .vssettingsfile file and click on Finish You can now close the wizard. Remark: When you sign in to Visual Studio on multiple computers using the same personalization account, your settings can be synchronized across the computers. Although the .vssettings file allows you to share a lot of configuration settings, it cannot be used to share the installed features and extensions. However this is possible through an
Recent posts

Property based testing in C#–CsCheck

Almost a year ago I wrote a series of blog posts on how to use property-based tests in C#. Part 1 – Introduction Part 2 – An example Part 3 – Finding edge cases Part 4 – Writing your own generators Part 5 – Locking input In this series I used FsC heck as the library of my choice. Although originally created for F#, it also works for C# as I have demonstrated. However as it was originally created for F#, it sometimes feels strange when using FsCheck in C#. If you prefer a more idiomatic alternative, you can have a look at CsCheck , also inspired by QuickCheck but specifically created for C#. CsCheck offers no specific integration but can be used with any testing framework(XUnit, NUnit, MSTest, …). Here is a small example: CsCheck does it really well in the shrinking challenge and offers support for multiple types of tests including concurrency testing . This is a feature I really like as concurrency related issues

Share a private key without using passwords

If you follow security best practices, you are not re-using the same password for multiple purposes. As a consequence you end up with a long list of passwords that you need to secure and manage. Although the use of a password vault certainly improved the experience, I still try to avoid the usage of passwords as much as possible. Today I want to share a ‘trick’ I discovered that allows you to share(export/import) a PFX file without using passwords. No clue what a pfx is? Let me explain that first… A PFX file, also known as a PKCS#12 file , is a binary format used to store certificates and their associated private keys . It combines 2 parts: A certificate part : A certificate is a digital document that contains information about an entity (such as a person, organization, or server). It is used for authentication, encryption, and secure communication. Certificates are issued by a Certificate Authority (CA) . A private key part : The private key is a cryptographic key

The importance of the ubiquitous language

We all know that the hardest thing in software development is naming things . Domain Driven Design tries to tackle this by focusing on the 'ubiquitous language'. The "ubiquitous language" refers to a shared language that is used by all team members, including domain experts, developers, and stakeholders, to discuss the domain and the software being developed. This language is designed to bridge the communication gap between technical and non-technical team members, ensuring that everyone has a clear understanding of the domain concepts and requirements. The ubiquitous language consists of domain-specific terms and concepts that are defined collaboratively and consistently used across all artifacts of the software development process, including code, documentation, and discussions. By using a common language, DDD aims to reduce misunderstandings and ambiguities, leading to more effective collaboration and better software designs. The best way to emphasize the imp

Azure Static Web App–Authorization

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V – Traffic splitting Part VI – Authentication using pre-configured providers Part VII – Application configuration using staticwebapp.config.json Part VIII – API Configuration Part IX – Injecting snippets Part X – Custom authentication Part XI(this post) – Authorization If we talk about authentication, we also have to talk about authorization. Authorization is role based and every user gets at least one role for free: the “anonymous” role. Once you are authenticated, a second role is assigned; the “authenticated” role. You can see this by browsing to the .auth/me endpoint after authenticating. You’ll get a response back similar to this

Implement the mediator pattern using MassTransit

The mediator pattern is a behavioral design pattern used in software engineering. It defines an object that encapsulates how a set of objects interact .  In object-oriented programming, programs often consist of many classes. As more classes are added to a program, especially during maintenance or refactoring, the problem of communication between these classes becomes complex. Direct communication between objects can lead to tight coupling, making the program harder to read, maintain, and change. The mediator pattern introduces a mediator object that acts as an intermediary between interacting objects. Instead of direct communication, objects now communicate through the mediator. This reduces dependencies between objects and promotes loose coupling. A popular way to implement the mediator pattern in .NET is through the popular MediatR library . But if you are already using Masstransit ,  there is no need to introduce an extra dependency as Masstransit has built-in support for

Don’t be a feature team

I saw the following quote passing when watching a presentation by Nick Tune : The best single source for innovation is your engineers (because  they’re working with the enabling technology every day, so they’re in the best position to see what’s just now possible). This quote comes from Marty Cagan who makes the distinction between product teams and feature teams. What is the difference between the 2? Empowerment! Marty Cagan explains empowerment like this in one of his articles : Empowerment of an engineer means that you provide the engineers with the problem to solve, and the strategic context, and they are able to leverage technology to figure out the best solution to the problem. An easy way to tell whether you have empowered engineers or not, is if the first time your engineers see a product idea is at sprint planning, you are clearly a feature team, and your engineers are not empowered in any meaningful sense. The reality is that most teams freedom is limi