Automatic Visual Studio Update Reboot If Necessary

The patches for CVE-2020-0601, CVE-2020-0605 and CVE-2020-0606 caused a pending reboot on my build servers after updating visual studio.So my hope that the unattended visual studio updater script would be finished has not come true So I added a pending reboot detection: Additionally I wanted some more details in the event log regarding the version being updated and the version after the update. I added a few lines using the FileInfo class.Beside that I stop the build agent service during the update process, so that builds do not fail while MSBuild is not available. So here is the full script:

Updating Visual Studio Installer unattended, last episode, hopefully

I have written about keeping build agents up to date in the past and had issues with the vs_installer updating itself. Now again the latest updates were not deployed.After playing around with procmon and friend I found a way to remove its state, so that the installer thinks is starts from the beginning of time - so there is no update. To do so I delete a few folders before starting the installation. I updated my gist file, but cannot update or comment the VisualStudio developer community page, as the issue is closed.

Create a link to a UWP app to run as administrator

I’m a console enthusiast. I used to work with cmder over the last years. In general I was pretty happy. But the announcement of the Windows Terminal really caught my attention.One thing that annoyed me is the disabled checkbox, when creating a link, that does not allow to have it automatically prompt for elevation.So here is my work around. Open windows explorer and enter shell:AppsFolder into the address bar to open the apps folder:Drag‘n’drop the Windows Terminal to any folder.Now patch the lnk-file: Create another lnk file pointing to cmd {path to the first lnk file}, running minimized and having a nice icon.Now just use the second lnk file and it works as expected.Windows Terminal, PowerShell 6 and oh-my-posh up and running.

Remote Debugging Chrome on Android with Windows

I’m an IPhone user. I like the device. I’m not a fanboy. I’m curious. So I got myself an HUAWEI P smart with Android Oreo (Version 8).1. Lets set up developer mode by following the android studio guide…Open the Settings appSelect System (only on Android 8.0 or higher) Scroll to the bottom and select “About phone”Scroll to the bottom and tap “Build number” 7 times–Whaaaaat? Tap? Seven times? Really 7?Return to the previous screen to find “Developer options” near the bottom2. Connect to the PhoneDownload the Android SDK Platform-ToolsExtract the filesConnect the phone using USB cableRun the Android Device Bridge (ADB) on the computer “adb devices”Enable USB debugging on the device settings and authorize the computerRun “adb devices” againRun “& ./adb forward tcp:9222 localabstract:chrome_devtools_remote”3. Connect Chrome to the deviceOpen ChromeHit [F12] to open the DevToolsClick Settings | More Tools | Remote devices4. Start DebuggingClick on the device you connected in the DevTools remove devices windowOpen a new tab or select an existing oneClick Inspect to open the remote inspection windowHTH

W3C Server Timing Header and API

I used custom headers in the past to send some metrics over to the client–mostly for debugging purposes to quickly differentiate between client and server issues on slow web request and/or web application performance.While that was working out pretty well I like standards and even if I did not tell anybody I always wanted such a thing built into HTTP.A W3C standard is on the way: Server TimingIt consists of a spec how the HTTP Header is constructed: And a client side API for JavaScript: Of course not all browsers support it yetBut Chrome 65–at the time of writing in the beta channel–does so:Even without any extra JavaScript you can inspect the numbers sent with the header in the Network tab of the DevTools:

Builds with conditional NuGet publishing in Team Foundation Server

For a nightly build it makes no sense to publish a NuGet package as no code changed and therefore the same GitVersion is calculated.Since version 2017 Update 3 the on premise version of Microsoft's Team Foundation Server supports "Custom Conditions" on "Build Tasks" – but sadly not on "Task Groups".Here is what you need to exclude a step from a scheduled build: Here a screenshot of the condition in action:HTH