Setup the stage
After a while I today hat to open an UWP application and fix some issues there. After I created a PR which triggers my CI/CD I realized that this pipeline which ran last year stopped working. The error messages didn’t helped me out. The pipeline was basically complaining about namespaces it couldn’t find which all came from
Windows.UI.Xaml.*. Here is an extract of my crash log (I replaced some stuff with ”…” for brevity):
CoreCompile: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\csc.exe /noconfig /nowarn:2008,1701,1702 /nostdlib+ /platform:x64 ... Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn ##[error]Logic\Logic.Ui\ViewModels\BaseContentViewModel.cs(6,27): Error CS0234: The type or namespace name 'Navigation' does not exist in the namespace 'Windows.UI.Xaml' (are you missing an assembly reference?) ... ##[error]Logic\Logic.Ui\Extensions\DisplayOrientationsExtensions.cs(6,19): Error CS0234: The type or namespace name 'Graphics' does not exist in the namespace 'Windows' (are you missing an assembly reference?) ... ##[error]Logic\Logic.Ui\ViewModels\CameraViewModel.cs(8,19): Error CS0234: The type or namespace name 'Media' does not exist in the namespace 'Windows' (are you missing an assembly reference?) ...
I knew from earlier experiences that this behavior has something to do with the version of the Windows SDK installed on the build machine. So I first checked this on my local dev box where everything was working fine. I went into the Visual Studio Installer, clicked on the change button next to “Visual Studio 2019” and then clicked “Components” at the top. If you filter using the textbox there using “Windows 10 SDK” as your filter-text you get something like this:
As you can see I have a lot of SDKs installed on my local machine. The newest build would be
10.0.20348.0. The number
20348 stands for the build version which will become important soon.
My suspicion arose that there must be something different to this setup on the build agent in Azure DevOps.
After some thought I decided to get more information on the machine in the cloud. As the time of writing the build pipeline offered me some options for the OS image I could use for the agent:
At the time the error occured I had the option
vs2017-win2016 selected. In order to decide which image to take to get rid of the errors I decided to give PowerShell a try.
So the task is to retrieve a list of all currently installed Windows-SDK-versions on a machine. This turns out to be pretty easy:
Get-ChildItem "HKLM:\Software\Microsoft\Windows Kits\Installed Roots" | Select -Property PSChildName
PSChildName is the property which shows the version only.
If I run this on my local machine I get:
PSChildName ----------- 10.0.17763.0 10.0.18362.0 10.0.19041.0 10.0.20348.0
which matches the list you saw in Image 1. Cool!
BTW. I got the idea from a GitHub site (see links section above). The posh-script you see there helped me a lot in understanding the logic behind finding the SDK version. The script enables you to even install the SDK you want if it is missing. To give you a little kick-start I will post the following code-snippet here too:
$projectFile = 'THE PATH TO YOUR CSPROJ' $fileContent = Get-Content -Raw $projectFile $mySdkVersion = ($fileContent | Select-String -Pattern "<TargetPlatformVersion>(.*)<\/TargetPlatformVersion>" -AllMatches).Matches.Groups.Value
If you set the
$projectFile variable to your
csproj-path you’ll get the SDK version suitable for your project. In the script from GitHub you can now replace line 12 with
WindowsSdkVersion = $mySdkVersion. Afterwards you could commit the script to your repo and run it in your pipeline. Caution If you do this the pipeline runtime will be affected very heavily. So think about this for a minute!
Performing the task in Azure DevOps
The only thing left now was to insert one step in my CI/CD pipeline in Azure DevOps to determine which versions of the SDK is installed on the machines.
After I did this I can now come up with a list of SDKs installed on the images currently available in Azure DevOps. Here it is.
List of SDKs pre-installed in Azure DevOps
After I got this list I quickly decided to switch to the image
windows-2019. This immediately resulted working build.
I find it pretty hard to get decent and reliable information about actual setups of the build agents in Azure DevOps. This is why I share my results here. Microsoft should add these information on a prominent position in the docs.