Earlier this year the Microsoft Identity Platform team shared new guidance that recommends using the OAuth 2.0 Authorization Code flow for browser based web applications. The reason for this is that new browser security changes are going to cause problems for the commonly used implicit grant flow pattern.
Although I found plenty of great code samples and quickstart material for using the authorization code flow with graph API, it took me a while to figure out how to use it against an ASP.NET Core Web API. The goal of this post is to provide an end-to-end setup guide with source code for the protected web API resource scenario that uses RBAC roles.
One of the most common ways to implement PowerShell error handling is to set the ErrorActionPreference variable (or ErrorAction parameter) to Stop, and capture these errors with a surrounding try/catch block.
This works perfectly fine in many situations. However one problematic use is when a cmdlet needs to write multiple unique errors to the error stream. One specific example is New-AzResourceGroupDeployment, which can write multiple validation or deployment errors if they are encountered.
If you use the standard try/catch approach here then the cmdlet stops after writing the first error (by design– because you set the action preference). This post provides some tips to handle this scenario to ensure you don’t miss the additional error stream records.
In this post we will do a complete walkthrough for configuring a new continuous integration (CI) pipeline that builds PowerShell modules in Azure DevOps Pipelines. Formalizing your PowerShell build steps into a CI pipeline helps enforce code quality standards and setup a fully automated process for publishing.
I have covered some of these pieces individually in other posts; for example my module starter kit and linting configurations. However a full post is helpful to tie all the pieces together in a detailed guide.
Power BI makes it really easy to import data, create reports with rich visuals, and then gain insights to make decisions. However one of the tricky things that I found when learning Power BI was that most of the example datasets were for sales and marketing data.
When should you use a bar chart? A donut chart? A funnel chart? Existing tutorials answer these questions fine– but what if you have telemetry or metrics for software projects?
In this post I share some Power BI chart and data model examples that are bit more relevant for software engineers. This makes it easier to build the best possible dashboards for your software or production systems telemetry.