A nice and simple way to expose static files is through Azure blob storage. If you are already using API Management you might want to have requests to through there, in order to ensure you can move it to somewhere else in the future. It requires a few steps to get it to work though.

First of all Managed Identities should be enabled in API management and Access Control (IAM) should be configured for the container to allow API management to access the file. In API management the endpoint is added with authentication-managed-identity policy to allow authentication is passes through. After that a number of headers should be removed and the x-ms-version, which is required to do AD authentication, should be set when forwarding the request from API Management to the blob storage endpoint. 

In my case I also wanted to avoid the .json extension in the endpoint, so the configuration ended up looking something like this.

<policies>
    <inbound>        
        <set-header name="Ocp-Apim-Subscription-Key" exists-action="delete" />
        <set-header name="Sec-Fetch-Site" exists-action="delete" />
        <set-header name="Sec-Fetch-Mode" exists-action="delete" />
        <set-header name="Sec-Fetch-Dest" exists-action="delete" />
        <set-header name="Accept" exists-action="delete" />
        <set-header name="Accept-Encoding" exists-action="delete" />
        <set-header name="Referer" exists-action="delete" />
        <set-header name="X-Forwarded-For" exists-action="delete" />
        <set-header name="x-ms-version" exists-action="override">
            <value>@{string version = "2017-11-09"; return version;}</value>
        </set-header>        
        <rewrite-uri template="/settings.json" copy-unmatched-params="true" />
        <authentication-managed-identity resource="https://storage.azure.com/" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Recently I needed to update Azure Management API based on the swagger specifications when our services were deployed. It seems like a pretty standard thing that there would be  a task for, but it turned out to require a bit of Powershell - it i still fairly simple though.

A general function to acccomplish it could look like this bit of code.

[CmdletBinding()]
Param(
    [string] [Parameter(Mandatory=$true)] $ResourceGroupName,
    [string] [Parameter(Mandatory=$true)] $ServiceName,
    [string] [Parameter(Mandatory=$true)] $ApiName,
    [string] [Parameter(Mandatory=$true)] $SpecificationFilePath
)

$apiMgmtContext = New-AzApiManagementContext -ResourceGroupName $ResourceGroupName -ServiceName $ServiceName
$api = Get-AzApiManagementApi -Context $apiMgmtContext -ApiId $ApiName

if ($null -eq $api) {
    Write-Error "Failed to get API with name $ApiName"
    exit(1)
}

$apiVersionSetId = $api.ApiVersionSetId.Substring($api.ApiVersionSetId.LastIndexOf("/")+1)
$apiVersionSet = Get-AzApiManagementApiVersionSet -Context $apiMgmtContext -ApiVersionSetId $apiVersionSetId

Import-AzApiManagementApi -Context $apiMgmtContext `
                        -SpecificationUrl $SpecificationFilePath `
                        -SpecificationFormat 'OpenApi' `
                        -Path $api.Path `
                        -ApiId $api.ApiId `
                        -ServiceUrl $api.ServiceUrl`
                        -ApiVersionSetId $apiVersionSet.Id

This can of course be used locally, but to run it from a release pipeline, the cleanest way I have found, is to add it to a separate repository, and include it as an artifact. From there we just need a Azure Powershell build step, configured as shown by the YAML below.

variables:
  swaggerUrl: 'https://my_appservice.azurewebsites.net/swagger/1.0.0/swagger.json'

steps:
- task: AzurePowerShell@5
  displayName: 'Azure PowerShell script: Update API Management'
  inputs:
    azureSubscription: 'xxx'
    ScriptPath: '$(System.DefaultWorkingDirectory)/_MyCompany.BuildScripts/UpdateApiManagement.ps1'
    ScriptArguments: '-ResourceGroupName "resource_group_name" -ServiceName "management_api_service_name" -ApiName "unique_api_id" -SpecificationFilePath $(swaggerUrl)'
    azurePowerShellVersion: LatestVersion

And that is all that is required, to automate it and make it update along with the build. Nice and easy.

OAuth is one of those things where I always wonder about how bad the state of libraries etc are. It seems like a problem pretty much everyone will tackle, but I am still not able to find a simple, library that works well with .NET Core HttpClient without being a whole framework in itself or at least very framework dependent.More...

On my current project we started seeing issues with images, especially when taken using an IPhone, that were shown as being rotated. Reading up on it I found that this is due to IOS using EXIF orientation, which is not always handled the same way on eg. Windows.

I found a couple of functions, that I modified to work with our TypeScript codebase, so that it utilizes async/await and has a minimum of type information. I suspect they might be useful for others, or myself later on, so here they are.

I have recently been looking at copying entire collections of data on Azure, in a way that should run as either Azure Functions or Webjobs. This is useful for backups, and simply moving data between environments. I didn't come across too many good samples of how to do this, so I expect it can be a useful topic for others who need to do the same thing.

More...

Recently I ran into a task that I had encountered less than a year ago with another client. In both cases the client was using Bootstrap CSS for their grid layout, but didn’t have much need for the Bootstrap JavaScript bits. After a while the need for type ahead functionality arose, so the first time around we agreed to include the Bootstrap JavaScript so we could use the Bootstrap Typeahead plugin.

However having to include jQuery, Bootstrap JavaScript and a plugin, which still required me to make some tweeks to work properly, didn’t sit well with me. So the second time around I opted to implement type ahead on my own. More...

I recently worked on a long running migration project, where we needed to ensure that some of the sql migration scripts were only called once per entity that was migrated, in a threadsafe manner. I looked to the System.Collections.Concurrent namespace, but none of the classes were really a good match. Basically what I needed was the ability to run a part of the migration that was identified by key, but ensure that it would only run once, although different parent strategies might try and run it.