Result of my configuration in Windows Terminal Preview

My Powershell Setup

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": " {{ ....

March 11, 2022 · 3 min · Me

Running the Azurite Emulator as a Windows Service with NSSM - a self-contained script

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....

March 7, 2022 · 2 min · Me

Setting Application Insights cloud_RoleName without custom ITelemetryInitializer

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:

March 4, 2022 · 1 min · Me