A little over a year ago I wrote up a tutorial on how to visually highlight blocked work items on a sprint board for Visual Studio Team Services. VSTS re-branded as Azure DevOps soon after I published that post and so some of the UI instructions have changed slightly now. I decided to make a follow up that runs through the exact same procedure but under the newer Azure DevOps re-branded UI.
Visually highlighting blocked work items is great way for developers, PMs, and the product owner to glance at the board to see blockers without having to deep dive into work items or run extra queries. Read on to find out how it’s done.
I recently completed work on a my first compiled binary PowerShell module– these are modules built with C#/.Net code instead of PowerShell code. A few module development basics like project setup, handling help files, and writing unit tests did take some work to figure out. In this article I provide some tips for how to handle these common scenarios to help you get started on new projects.
Windows PowerShell’s execution policy is well known feature that helps prevent users from accidentally running malicious scripts. I hit an interesting situation recently where Get-ExecutionPolicy showed that I was allowed to run scripts, but in practice I still couldn’t execute scripts from a .NET application’s hosted runspace. What was the problem? The execution policy settings differed across x64 and x86 processes. Since this problem isn’t covered in the official documentation I figured it deserved a quick write-up.
If you’ve ever run a database package (.dacpac) publish against a SQL Server or Azure SQL database, chances are good that you have run into the following error when changing the schema for a table that contains data:
SQL72014: .Net SqlClient Data Provider: Msg 50000, Level 16, State 127, Line 6 Rows were detected.
The schema update is terminating because data loss might occur.