Snippets

The issue Today, I got hit with a strange issue when trying to restore a NuGet package in a project. I had just updated a package version to a new prerelease version (with, granted, a pretty long name along the lines of MyCompany.MyDepartment.MyPackage.Something.OpenTelemetry.Common.1.5.0-FEATURE-BRANCH-NAME_TICKET-NAME-12345.BUILD_NUMBER) and was trying to restore when - well, nothing happened. The Visual Studio Package Manager output just said: Could not find part of the path 'C:\Users\vinkemeier\AppData\Local\NuGet\v3-cache\7c65f951c65b434c5601ab3dd905646debe8d198$_api_nuget_v3_nuget-feed-name\list_mycompany.mydepartment.mypackage.something.common_range_1.2.0-FEATURE-BRANCH-NAME_TICKET-NAME-12345.BUILD_NUMBER-1.3.0FEATURE-BRANCH-NAME_TICKET-NAME-12345.BUILD_NUMBER.dat-new' I was first thinking that the issue might be in package availability in the custom NuGet feed, but I could access the package via the browser UI. I also tried to clear the NuGet cache with dotnet nuget locals all --clear, but that didn’t help either. After some time, it occurred to me that the path length of the cache file might be the issue. And, of course, when googling for path length issues, you quickly find a GitHub issue from 2019 in the NuGet repository that describes this behaviour. The workaround Sadly, although being closed, the issue is still present in the current Visual Studio 2022 preview. However, a “workaround” is available: Change the NuGet HTTP cache path to a shorter one. So, I changed the NUGET_HTTP_CACHE_PATH environment variable to a shorter path (e.g. C:\NuGetCache), restarted Visual Studio and it worked normally again. Let’s hope this works long enough and our paths don’t keep getting longer. If I have that issue again on a new machine, I at least now have this documented for my future self :)

I have a Raspberry Pi 4 that I use as a PiHole server for my home network (which I can’t recommend enough doing). It has been running for a while now, but after the last updates it was not booting anymore. I checked the (arguably pretty cheap) MicroSD card that I used and it was dead. So, I decided to get a new one and set up the PiHole server again - since I was pretty sure that I did not need to configure a lot. However, after installing Raspbian Lite via the Raspberry Pi Imager and booting the Pi, I noticed that the network LEDs on the Pi turned off periodically. Like, they were blinking (indicating activity) for 1-2 seconds and then turn off for 1-2 seconds. I also got a host of networking issues inside the Pi, like ping not working, apt-get not working, DNS resolution failures, etc.. After tons of research, trial-and-error and frustration, multiple re-imaging-procedures and different cables, I found a solution that worked for me - so I need to note it down for my future self 😄 This post on the Raspberry Pi forums was the key to my solution. I ran the suggested command journalctl -b to look through the system logs and found a lot of occurrences of messages indicating eth0 being connected and then down again 2 lines afterwards. Then I used sudo nano /boot/firmware/config.txt (the path mentioned on the forums has changed to this one) and added the following line near the beginning of the file:...

This snippet stores my current PowerShell setup, consisting of posh-git, Terminal-Icons, ZLocation, oh-my-posh and PSReadLine. Also, I use a customized oh-my-posh theme that I am still fiddling with (see below). To properly render all glyphs, I use the Caskaydia Cove Nerd Font, a Nerd-Font-variant of Cacadia Code (which I use in the VS and VS Code editors), inside of Windows Terminal. I use the CurrentUserAllHosts profile, which you can find at $PROFILE.CurrentUserAllHosts. If available, I install the modules via winget or Chocolatey, otherwise via the PowerShell gallery. # Put this in Microsoft.PowerShell_profile.ps1 ($PROFILE.CurrentUserAllHosts) # Posh-Git displays git information within the terminal Import-Module posh-git # Terminal-Icons shows file and folder icons Import-Module Terminal-Icons # ZLocation allows for quick navigation Import-Module ZLocation # Oh-My-Posh was installed via winget # The customized theme was put next to the profile $ohMyPoshThemeConfigPath = "$($PROFILE.CurrentUserAllHosts)\..\custom-theme-tnv.omp.json" oh-my-posh --init --shell pwsh --config $ohMyPoshThemeConfigPath | Invoke-Expression Enable-PoshTooltips if ($host.Name -eq 'ConsoleHost') { # PSReadLine improves shortcut handling Import-Module PSReadLine Set-PSReadLineKeyHandler -Key UpArrow -Function HistorySearchBackward Set-PSReadLineKeyHandler -Key DownArrow -Function HistorySearchForward } Then put this in a file named custom-theme-tnv.omp.json next to the profile: { "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json", "blocks": [{ "alignment": "left", "segments": [{ "background": "#000000", "foreground": "#dd1e1e", "properties": { "template": " \u26a1" }, "style": "plain", "type": "root" }, { "background": "#000000", "foreground": "#ffffff", "properties": { "alpine": "\uf300", "arch": "\uf303", "centos": "\uf304", "debian": "\uf306", "elementary": "\uf309", "fedora": "\uf30a", "gentoo": "\uf30d", "linux": "\ue712", "macos": "\ue711", "manjaro": "\uf312", "mint": "\uf30f", "opensuse": "\uf314", "raspbian": "\uf315", "template": " {{ if .WSL }}WSL at {{ end }}{{.Icon}} ", "ubuntu": "\uf31c", "windows": "", "wsl": "\ue712" }, "style": "plain", "type": "os" }, { "background": "#4d4d4d", "foreground": "#43CCEA", "properties": { "folder_icon": "\ue5fe", "folder_separator_icon": "<transparent> \ue0bd </>", "home_icon": "\uf7db", "style": "agnoster_short", "template": " {{ ....

You can use the following script to install NSSM and Azurite, as well as install Azurite as windows service. Of course, after some adjustments, it can also be used to run any powershell script snippet as windows service. Usage: To install NSSM from Chocolatey and Azurite from NPM, use script.ps1 install-dependencies To install Azurite as Service, use script.ps1 install To uninstall the service, use script.ps1 uninstall # Can be used to run the Azurite Emulator as a Windows Service via NSSM # Make sure to have NSSM installed (e.g. via "choco install nssm") # Also make sure to have Azurite installed ("npm install -g azurite") # You can also use the "install-dependencies" command [cmdletbinding()] param($command, $azuritePath) # Service configuration $serviceName = "AzuriteEmulator" $serviceDisplayName = "Azurite Emulator as Windows Service" $logsDirectory = "C:\azurite\logs" # Setup of dynamic paths $nssm = (Get-Command nssm).Source $powershell = (Get-Command pwsh).Source $scriptPath = $MyInvocation.MyCommand.Path # Azurite-specific handling - we pass the Azurite path to the service so that it can be run under a different user account if ($azuritePath -eq "" -Or $null -eq $azuritePath) { $azuritePath = (Get-Command azurite).Source } $arguments = '-ExecutionPolicy Bypass -File "{0}" --command runservice -azuritePath "{1}"' -f $scriptPath, $azuritePath if ($command -eq "runservice") { # This is the script part we actually want to run inside the service Write-Host ("Starting Azurite from '{0}'..." -f $azuritePath) & $azuritePath --silent --location c:\azurite --debug c:\azurite\logs\azurite.log --loose } elseif ($command -eq "install") { # Ensure logs directory exists mkdir $logsDirectory -f # Install service, set DisplayName and redirect outputs to logs & $nssm install "$serviceName" "$powershell" "$arguments" & $nssm set "$serviceName" DisplayName $serviceDisplayName & $nssm set "$serviceName" AppStdout "$logsDirectory\service....

When using Azure Application Insights, it is helpful to identify the components of your application by setting the cloud_RoleName field for telemetry. This makes it easy to filter telemetry data to specific components, e.g. “api” or “worker”, such as in Live Metrics: To do this, most search results suggest to implement a custom ITelemetryInitializer and initialize each telemetry item with a value from configuration. While that, of course, works, there is also a helpful but little-known class named AzureWebAppRoleEnvironmentTelemetryInitializer, which is part of the Microsoft.ApplicationInsights.WindowsServer namespace. It is included in both the Application Insights integration for ASP.Net Core as well as that for .Net Worker Services. You just register it as a telemetry initializer with the service collection before calling the appropriate method to register Application Insights. Like so: // in ConfigureServices of your ASP.Net Core Startup.cs services.AddSingleton<ITelemetryInitializer, AzureWebAppRoleEnvironmentTelemetryInitializer>(); services.AddApplicationInsightsTelemetry(); // or for worker services, using the Microsoft.ApplicationInsights.WorkerService NuGet package services.AddSingleton<ITelemetryInitializer, AzureWebAppRoleEnvironmentTelemetryInitializer>(); services.AddApplicationInsightsTelemetryWorkerService(); Then, on your host environment, just set the WEBSITE_CLOUD_ROLENAME environment variable and the value will be relayed to your telemetry. This works everywhere, but is especially helpful on Azure App Service, where this initializer will also collect additional information like the host URL. The result in your telemetry should look something like this: