azure

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: