Forem: Justin Yoo

One Command Deploying .NET Apps to Azure Container Apps: azd up

Justin Yoo — Fri, 06 Sep 2024 16:13:09 +0000

In my previous blog posts of containerising .NET apps and Function apps, I discussed how to containerise .NET apps and Azure Functions apps with and without Dockerfile. However, deploying these containerised apps to Azure Container Apps (ACA) is a different story.

Since its release in May 2023, Azure Developer CLI (azd) has evolved significantly. azd nowadays even automatically generates Bicep files for us to immediately provision and deploy applications to Azure. With this feature, you only need the azd up command for provisioning and deployment.

Throughout this post, I'm going to discuss how to provision and deploy .NET apps including Azure Functions to ACA through just one command, azd up.

You can find a sample code from:
devkimchi / azdevfying-dotnet-apps-on-aca

This provides sample .NET apps to be deployed onto Azure Container Apps through azd CLI
azdevfying .NET apps on Azure Container Apps

This provides sample .NET apps to be deployed onto Azure Container Apps through Azure Developer CLI.

Prerequisites

Visual Studio 2022 17.10+ or Visual Studio Code with C# Dev Kit

Azure Developer CLI

Azure Functions Core Tools

Docker Desktop

Architecture

Three .NET apps are provided in this repository:

Blazor web app as a frontend

ASP.NET Core Web API as a backend

Azure Functions as a backend

Getting Started

NOTE: You can see the complete example including all the Bicep files by switching to the azdevfied branch.
Login to Azure through Azure Developer CLI.
azd auth login
Run the following command to initialise azd. It will ask you to choose options how to initialise. Follow the instructions.
azd init
Once initialised, you will have both .azure and infra directories and both next-steps.md and azure.yaml files.

At this stage, the web app doesn't…
View on GitHub

Prerequisites

There are a few prerequisites to containerise .NET apps effectively.

Running the app locally

The sample app repository already includes the following apps:

Blazor app as a frontend
ASP.NET Core Web API app as a backend
Azure Functions app as another backend

Let's make sure those apps running properly on your local machine. In order to run those apps locally, open three terminal windows and run the following commands on each terminal:

# Terminal 1 - ASP.NET Core Web API
dotnet run --project ./ApiApp

# Terminal 2 - Azure Functions
cd ./FuncApp
dotnet clean && func start

# Terminal 3 - Blazor app
dotnet run --project ./WebApp

Open your web browser and navigate to https://localhost:5001 to see the Blazor app running. Then navigate to https://localhost:5001/weather to see the weather data fetched from the ApiApp and the greetings populated from the FuncApp.

Now, let's start using azd to provision and deploy these apps to ACA. Make sure that you've already logged in to Azure with the azd auth login command.

`azd init` – Initialisation

In order to provision and deploy the apps to ACA, you need to initialise the azd configuration. Run the following command:

azd init

You'll be prompted to initialise the app. Choose the Use code in the current directory option.

azd automatically detects your three apps as shown below. In addition to that, it says it will use Azure Container Apps. Choose the Confirm and continue initializing my app option.

The function app asks the target port number. Enter 80.

And finally, it asks the environment name. Enter any name you want. I just entered aca0906 for now.

Now, you've got two directories and two files generated:

.azure directory
infra directory
next-steps.md file
azure.yaml file

Under the infra directory, there are bunch of Bicep files automatically generated through azd init.

As a result of running the command, azd init, you don't have to write all necessary Bicep files. Instead, it generates them for you, which significantly reduces the time for infrastructure provisioning. Now, you're ready to provision and deploy your apps to ACA. Let's move on.

`azd up` – Provision and deployment

All you need to run at this stage is:

azd up

Then, it asks you to confirm the subscription and location to provision the resources. Choose the appropriate options and continue.

All apps are containerised and deployed to ACA. Once the deployment is done, you can see the output as shown below:

Click the web app URL and navigate to the /weather page. But you will see the error as shown below:

This is because each app doesn't know where each other is. Therefore, you should update the Bicep files to let the web app know where the other apps are.

Update Bicep files – Service discovery

Open the infra/main.bicep file and update the webApp resource:

module webApp './app/WebApp.bicep' = {
  name: 'WebApp'
  params: {
    ...
    // Add these two lines
    apiAppEndpoint: apiApp.outputs.uri
    funcAppEndpoint: funcApp.outputs.uri
  }
  scope: rg
}

Then, open the infra/app/WebApp.bicep file and add both apiAppEndpoint and funcAppEndpoint parameters:

...
@secure()
param appDefinition object

// Add these two lines
param apiAppEndpoint string
param funcAppEndpoint string
...

In the same file, change the env variable:

// Before
var env = map(filter(appSettingsArray, i => i.?secret == null), i => {
  name: i.name
  value: i.value
})

// After
var env = union(map(filter(appSettingsArray, i => i.?secret == null), i => {
  name: i.name
  value: i.value
}), [
  {
    name: 'API_ENDPOINT_URL'
    value: apiAppEndpoint
  }
  {
    name: 'FUNC_ENDPOINT_URL'
    value: funcAppEndpoint
  }
])

This change passes the API and Function app endpoints to the web app as environment variables, so that the web app knows where the other apps are.

Once you've made the changes, run the azd up command again. It will update the resources in ACA. After that, go to the web app URL and navigate to the /weather page. You will see the weather data and greetings fetched from the API and Function apps.

So far, I've discussed how to provision and deploy .NET apps including Azure Functions to ACA with just one command, azd up. This is a very convenient way to deploy apps to Azure. However, to let the apps know each other, you should slightly tweak the auto-generated Bicep files. With this little tweak, all your .NET apps will be seamlessly provisioned and deployed to ACA.

One more thing I'd like to mention here, though, is that, if you use .NET Aspire, this sort of service discovery is automatically handled.

More about deploying .NET apps to ACA?

If you want to learn more options about deploying .NET apps to ACA, the following links might be helpful.

You don't need Dockerfile to containerise Azure Functions

Justin Yoo — Fri, 23 Aug 2024 10:10:10 +0000

In my previous post, I discussed different containerising options for .NET developers. Now, let's slightly move the focus to Azure Functions app. How can you containerise the Azure Functions app? Fortunately, Azure Functions Core Tools natively support it with Dockerfile. But is the Dockerfile the only option for containerising your .NET-based Azure Functions apps? Throughout this post, I'm going to discuss how Azure Functions apps can be containerised both with and without Dockerfile.

You can find a sample code from:
devkimchi / msbuild-for-functions-on-containers

This provides sample .NET function apps using container images with Dockerfile and with MSBuild on Docker Desktop.
MSBuild for Azure Functions on Containers

As a .NET developer, when you build a container image for your Azure Functions app, you can use the Dockerfile to define the container image. However, you can also use the dotnet publish command to build and publish the container image without a Dockerfile. This repository provides sample .NET function apps using container images with Dockerfile and with dotnet publish.

Prerequisites

.NET SDK 8.0+ with .NET Aspire workload

Visual Studio or Visual Studio Code + C# Dev Kit + Azure Functions

Azure Functions Core Tools

Docker Desktop

Getting Started

NOTE: Make sure Docker Desktop is running before you start.

Run with Dockerfile
Run func init to create a new Azure Functions app with Docker support.
func init FunctionAppWithDockerfile --worker-runtime dotnet-isolated --docker --target-framework net8.0
Confirm the Dockerfile is created in the FunctionAppWithDockerfile folder.

Run func new to add a new HTTP trigger…
View on GitHub

Prerequisites

There are a few prerequisites to containerise .NET-based function apps effectively.

Containerise with `Dockerfile`

With the Azure Functions Core Tools, you can create a new Azure Functions app with the following command:

func init FunctionAppWithDockerfile \
    --worker-runtime dotnet-isolated \
    --docker \
    --target-framework net8.0

You may notice the --docker option in the command. This option creates a Dockerfile in the project directory. The Dockerfile looks like this:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS installer-env

COPY . /src/dotnet-function-app
RUN cd /src/dotnet-function-app && \
mkdir -p /home/site/wwwroot && \
dotnet publish *.csproj --output /home/site/wwwroot

# To enable ssh & remote debugging on app service change the base image to the one below
# FROM mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-appservice
FROM mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

COPY --from=installer-env ["/home/site/wwwroot", "/home/site/wwwroot"]

There are a few points on Dockerfile to pick up:

The base image for the runtime is mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0. There are two other options available, mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-slim and mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-mariner. You can choose one of them based on your requirements.
The function app is running on the /home/site/wwwroot directory.
It has two environment variables, AzureWebJobsScriptRoot and AzureFunctionsJobHost__Logging__Console__IsEnabled.
There's no ENTRYPOINT instruction defined.

These points will be used later on this post.

Let's add a new function to the Azure Functions app with the following command:

func new -n HttpExampleTrigger -t HttpTrigger -a anonymous

Once it's added, open the HttpExampleTrigger.cs file and modify it as follows:

// Before
return new OkObjectResult("Welcome to Azure Functions!");

// After
return new OkObjectResult("Welcome to Azure Functions with Dockerfile!");

Now, you can build the container image with the following command:

docker build . -t funcapp:latest-dockerfile

You have the container image for the Azure Functions app. You can run the container with the following command:

docker run -d -p 7071:80 --name funcappdockerfile funcapp:latest-dockerfile

Your function app is now up and running in a container. Open the browser and navigate to http://localhost:7071/api/HttpExampleTrigger to see the function app running.

Open your Docker Desktop and check the running container.

Can you see the Path and Args value? The Path value is /opt/startup/start_nonappservice.sh and the Args value is an empty array. In other words, the shell script, start_nonappservice.sh is executed when the container starts, and it takes no arguments. Keep this information in mind. You'll use it later in this post.

Once you're done, stop and remove the container with the following commands:

docker stop funcappdockerfile && docker rm funcappdockerfile

So far, we've containerised the Azure Functions app with the Dockerfile. But, as I mentioned before, there is another way to containerise the Azure Functions app without having Dockerfile. Let's move on.

Containerise with `dotnet publish`

Because MSBuild natively supports containerisation, you can make use of the dotnet publish command to build the container image for your function app. If you want to dynamically set the base container image, this option will be really useful. To do this, you might need to update your .csproj file to include the containerisation settings. First of all, create a new function app without the --docker option.

func init FunctionAppWithMSBuild \
    --worker-runtime dotnet-isolated \
    --target-framework net8.0

Let's add a new function to the Azure Functions app with the following command:

func new -n HttpExampleTrigger -t HttpTrigger -a anonymous

Once it's added, open the HttpExampleTrigger.cs file and modify it as follows:

// Before
return new OkObjectResult("Welcome to Azure Functions!");

// After
return new OkObjectResult("Welcome to Azure Functions with MSBuild!");

Now, the fun part begins. Open the FunctionAppWithMSBuild.csproj file and add the following node:

<ItemGroup>
  <ContainerEnvironmentVariable
      Include="AzureWebJobsScriptRoot" Value="/home/site/wwwroot" />
  <ContainerEnvironmentVariable
      Include="AzureFunctionsJobHost__Logging__Console__IsEnabled" Value="true" />
</ItemGroup>

Did you find that these two environment variables are the same as the ones in the Dockerfile? Let's add another node to the .csproj file:

<ItemGroup Label="ContainerAppCommand Assignment">
  <ContainerAppCommand Include="/opt/startup/start_nonappservice.sh" />
</ItemGroup>

This node specifies the command to run when the container starts. This is the same as the Path value in the Docker Desktop screenshot. Now, you can build the container image with the following command:

dotnet publish ./FunctionAppWithMSBuild \
    -t:PublishContainer \
    --os linux --arch x64 \
    -p:ContainerBaseImage=mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0 \
    -p:ContainerRepository=funcapp \
    -p:ContainerImageTag=latest-msbuild \
    -p:ContainerWorkingDirectory="/home/site/wwwroot"

NOTE: You can set the base container image with mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-slim or mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-mariner, depending on your requirements.

This command takes four properties – ContainerBaseImage, ContainerRepository, ContainerImageTag, and ContainerWorkingDirectory. With this dotnet publish command, you have the same development experience as building the container image with the docker build command, without having to rely on Dockerfile.

Run the following command to run the container:

docker run -d -p 7071:80 --name funcappmsbuild funcapp:latest-msbuild

Your function app is now up and running in a container. Open the browser and navigate to http://localhost:7071/api/HttpExampleTrigger to see the function app running.

Open your Docker Desktop and check the running container.

Can you see the Path and Args value? The Path value is /opt/startup/start_nonappservice.sh and the Args value has dotnet and FunctionAppWithMSBuild.dll. But these arguments are ignored because the shell script doesn't take any argument.

Once you're done, stop and remove the container with the following commands:

docker stop funcappmsbuild && docker rm funcappmsbuild

Now, you've got the Azure Functions app containerised without Dockerfile. With this dotnet publish approach, you can easily change the base container image, repository, tag, and working directory without relying on Dockerfile.

So far, I've walked through how .NET developers can containerise their .NET-based Azure Functions apps with two different options. You can either write Dockerfiles or use dotnet publish to build container images. Which one do you prefer?

More about MSBuild for Containers?

If you want to learn more options about containers with MSBuild, the following links might be helpful.

Different Containerising Options for .NET Developers

Justin Yoo — Mon, 12 Aug 2024 13:00:59 +0000

As a .NET developer, if you want to containerise your .NET apps, you know you need a Dockerfile first. Dockerfile is a spec that describes which OS is used, where the .NET code is located, how the .NET code is compiled and how the .NET app is executed. Once your Dockerfile is ready, you can build your container image. But is the Dockerfile the only option for building your .NET apps in a container? How about the container orchestration? Is there any way to orchestrate containers other than running the docker compose up command? Throughout this post, I'm going to discuss which options are available for .NET developers to containerise your .NET apps.

You can find a sample code from:

devkimchi / msbuild-for-containers

This provides sample .NET apps using container images with Dockerfile, with MSBuild, and with .NET Aspire support on Docker Desktop.

MSBuild for Containers

As a .NET developer, when you build a container image for your app, you can use the Dockerfile to define the container image. However, you can also use the dotnet publish command to build and publish the container image without a Dockerfile. This repository provides sample .NET apps using container images with Dockerfile and with dotnet publish.

In addition to that, if you want to orchestrate containers Docker Compose is usually the first approach. However, you can also use the .NET Aspire to generate the Docker Compose file from the .NET Aspire manifest JSON file. This repository also provides a sample .NET app using the .NET Aspire to orchestrate containers.

Prerequisites

.NET SDK 8.0+ with .NET Aspire workload

Visual Studio or Visual Studio Code + C# Dev Kit

Aspirate

Docker Desktop

Getting Started

Run with Dockerfile

Run docker init to create a new Dockerfile for…

View on GitHub

Prerequisites

There are a few prerequisites to containerise .NET apps effectively.

.NET SDK 8.0+ with .NET Aspire workload and Aspirate
Docker Desktop

Containerise with `Dockerfile`

In the sample code repository, there are two .NET apps, ApiApp and WebApp. When you run both apps locally, it communicates with each other by running the following commands:

dotnet run --project ./MSBuildForContainers.ApiApp

dotnet run --project ./MSBuildForContainers.WebApp

Now, you want to containerise both apps. How can you do that? The first option is to write a Dockerfile for each app. You can either manually write Dockerfile or run the command, docker init. Once you have Dockerfile files for both apps, run the following commands to build the container images:

# For ApiApp
docker build . -t apiapp:latest

# For WebApp
docker build . -t webapp:latest

We all know how Dockerfile is useful to build container images. However, Dockerfile is yet another code and should be maintained. If you have many apps to containerise, you need to write Dockerfile files respectively. This is a bit cumbersome. Is there any other way to containerise .NET apps, without writing Dockerfile files?

Containerise with `dotnet publish`

MSBuild supports containerisation by itself. It uses the dotnet publish command to build the container image for each app. To do this, you might need to update your .csproj file to include the containerisation settings. The following is the MSBuildForContainers.ApiApp.csproj file:

<PropertyGroup>
  <ContainerRepository>apiapp</ContainerRepository>
  <ContainerImageTag>latest</ContainerImageTag>
</PropertyGroup>

These two properties replaces the --tag option in the docker build command. Once you have these properties in the .csproj file, run the following command. Note that the -t:PublishContainer indicates the containerisation and the --os and --arch options specify the target OS and architecture.

dotnet publish ./MSBuildForContainers.ApiApp \
    -t:PublishContainer \
    --os linux --arch x64

Then, you'll have the container image. If you want to change the base image to the chiseled container one, add another property to the .csproj file. The following property sets the chiseled Ubuntu 24.04 image as the base image.

<PropertyGroup>
  <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:8.0-noble-chiseled</ContainerBaseImage>
</PropertyGroup>

Then, run the dotnet publish command above again. This time, the container image is built based on the chiseled image. Let's do the same thing against the MSBuildForContainers.WebApp.csproj file. This way, you can containerise your .NET apps without writing Dockerfile files.

Alternatively, you don't even need those properties in the .csproj file. You can run the following command to build the container image directly like this:

dotnet publish ./MSBuildForContainers.ApiApp \
    -t:PublishContainer \
    --os linux --arch x64 \
    -p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:8.0-noble-chiseled \
    -p:ContainerRepository=apiapp \
    -p:ContainerImageTag=latest

You have the same development experience as building the container image with the docker build command, without having to rely on Dockerfile.

Now, you've got chiseled container images for both API app and web app. How to let them talk to each other?

Container orchestration with `docker compose`

The existing web app container image can't talk to the API app container image because it doesn't know where the API app container is. To make the web app container talk to the API app container, you need to slightly modify the web app and build the container image again. Open the MSBuildForContainers.WebApp/Program.cs file and update the base address value as follows:

// Before
builder.Services.AddHttpClient<IApiAppClient, ApiAppClient>(http => http.BaseAddress = new Uri("https://localhost:5051/"));

// After
builder.Services.AddHttpClient<IApiAppClient, ApiAppClient>(http => http.BaseAddress = new Uri("http://apiapp:8080/"));

Run the dotnet publish command again to build the web app container image. Now, you can manually run the docker run command to run both containers by attaching the same network. But for the container orchestration, the docker compose up command is much easier to use. The docker-compose.yml file is already prepared in the sample code repository. Run the following command:

docker compose -f ./docker-compose.yaml up

Then, both containers are up and running. The web app container can talk to the API app container. This is how you can orchestrate containers with docker compose up. Again, this Docker Compose file is yet another code and should be maintained. If you have many apps to orchestrate, how would you manage them?

Container orchestration with .NET Aspire and Aspirate

.NET Aspire is to orchestrate .NET apps in containers. For this Docker Compose orchestration purpose, Aspirate is used, which is a tool that generates the Docker Compose file, a Kustomize file or helm file for the container orchestration. To use Aspirate, you need to install it first:

dotnet tool install -g aspirate

In the sample code repository, Both web app and API app are orchestrated with .NET Aspire in another branch. Switch to the aspire branch with the command:

git switch aspire

Let's generate the Docker Compose file with Aspirate. Run the following command to generate the .NET Aspire manifest file first:

dotnet run --project ./MSBuildForContainers.AppHost \
    -- \
    --publisher manifest \
    --output-path ../aspire-manifest.json

Then, generate the Docker Compose file with the Aspirate command. Note that it intentionally excludes the .NET Aspire dashboard.

aspirate generate \
    --project-path ./MSBuildForContainers.AppHost \
    --aspire-manifest ./aspire-manifest.json \
    --output-format compose \
    --disable-secrets --include-dashboard false

Now, you have the Docker Compose file generated. Run the docker compose up command to orchestrate the containers. This way, you can orchestrate your .NET apps in containers without manually writing the Docker Compose file.

So far, I've walked through how .NET developers can containerise their .NET apps with different options. You can either write Dockerfile files or use dotnet publish to build container images. You can orchestrate containers by writing the Docker Compose file by hand or letting .NET Aspire and Aspirate generate it automatically. Which one do you prefer?

More about MSBuild for Containers?

If you want to learn more options about containers with MSBuild, the following links might be helpful.

DevContainers for Azure and .NET

Justin Yoo — Thu, 13 Oct 2022 21:43:53 +0000

Containers are everywhere. It's not just to make both the development and production environment consistent but also to build CI/CD pipelines, test automations, and so on. While everyone does their own way of building containers, it has become the maintenance job.

Maintenance will become easier if it uses standardised ways. What if there is an open standard spec for it? Actually, there is. It is called Development Container or DevContainer. You can build the container and store it in your GitHub repository with this spec. Then, GitHub Codespaces makes use of it. At least a project using the same GitHub repository uses the same development environment. Throughout this post, I'm going to introduce the DevContainer spec and discuss how it's used for Azure and .NET app development.

You can download the DevContainer template from this GitHub repository, which is used for this post.
devkimchi / devcontainers-dotnet

This is the template repository that contains the devcontainer settings for .NET app development
devcontainers for .NET

This is the template repository that contains the devcontainer settings for .NET app development.

Getting Started

If you want to use this devcontainer settings, you can create a new repository with this template repository, by clicking the "Use this template" button.

Options – devcontainer.json

Base Image

By default, this devcontainer settings uses the base image of Ubuntu 22.04 LTS (jammy).
"build": {
  "dockerfile": "./Dockerfile",
  "context": ".",
  "args": {
    "VARIANT": "6.0-jammy"
  }
}
However, there is currently a bug on the C# extension v1.25.0 for Razor support on Ubuntu 22.04 LTS (jammy). Therefore, if you need Razor support, build your devcontainer with Ubuntu 20.04 LTS (focal).
"build": {
  "dockerfile": "./Dockerfile",
  "context": ".",
  "args": {
    // Use this only if you need Razor support, until OmniSharp supports .NET 6 properly
    "VARIANT": "6.0-focal"
  }
…
View on GitHub

Elements of DevContainer

All you need for building a DevContainer are those two files:

devcontainer.json: It defines all the metadata details to build a DevContainer.
Dockerfile: It defines the Docker container image that is invoked within devcontainer.json.

Optionally, you can call a shell script during the container building lifecycle. The postCreateCommand attribute of the devcontainer.json file takes care of it. For example, the attribute executes the post-create.sh file.

Alternatively, you can invoke the RUN command within Dockerfile for the shell script execution. In this case, you're running the script with the root permissions. On the other hand, postCreateCommand runs the script with the user privileges declared in devcontainer.json.

Structure of `devcontainer.json`

devcontainer.json consists of various sections for metadata declarations. I only deal with a small portion of it in this post.

build: This section is for the Docker container build – location of Dockerfile, parameters passed to it.
forwardPorts: This section defines the list of port numbers to expose. For example, 7071 is for Azure Functions, 5000 and 5001 are for ASP.NET Web/API apps, and 4280 is for Azure Static Web App development.
features: While you can add everything in Dockerfile for the build, there are already pre-configured features you can optionally add. You can find the complete list of the features at here. Some examples of those features are common utilities and tools like Azure CLI, GitHub CLI and Terraform, and languages like node.js, Java, .NET, Python, etc.
customisations: This section is responsible for the tools used in DevContainer. One of the tools is VS Code which the vscode attribute represents. It defines which extensions need to be included (extensions) and how the editor behaves (settings).
remoteUser: This sets the user account within DevContainer. Unless it is set, DevContainer runs as the root account. In this post, we use vscode as the non-root account.
postCreateCommand: Once DevContainer is created, run additional commands with the remote-user account privileges. Through this attribute, you can run an additional shell script.

There are more attributes than the ones mentioned above. If you want to know more, visit this page.

Order of Building DevContainer

How does DevContainer get built? Here is the rough order.

Build the Docker container. If you add the shell script through the RUN command in Dockerfile, the shell script is run this time.
Run features declared in the features section of devcontainer.json while building the Docker container.
Run commands declared in the postCreateCommand attribute of devcontainer.json.
Apply dotfiles after postCreateCommand, if you have it.
Apply both extensions and settings of devcontainer.json at the startup of the DevContainer.

By understanding the order above, let's build the DevContainer for .NET app development on Azure.

Base Container Image

When you visit the repository for DevContainer images, there are pre-configured list of base Docker container images for DevContainer. Let's choose the one for .NET. You can choose many different variants, but either 6.0-jammy (Ubuntu 22.04) or 6.0-focal (Ubuntu 20.04) would be yours if you prefer using Ubuntu-based images with .NET 6. Ubuntu 22.04 is set to the default base image in this post.

# [Choice] .NET version: 6.0-jammy, 6.0-focal
ARG VARIANT="6.0-jammy"
FROM mcr.microsoft.com/dotnet/sdk:${VARIANT}

`devcontainer.json` Configuration

Let's configure devcontainer.json containing all the metadata details.

The `build` Section

It declares the location of Dockerfile and sends parameters to it. In this case, use 6.0-jammy for VARIANT.

"build": {
  "dockerfile": "./Dockerfile",
  "context": ".",
  "args": {
    "VARIANT": "6.0-jammy"
    // Use this only if you need Razor support, until OmniSharp supports .NET 6 properly
    // "VARIANT": "6.0-focal"
  }
}

If you are building a Blazor app, pass 6.0-focal (Ubuntu 20.04) instead of 6.0-jammy (Ubuntu 22.04). It's because the C# extension has a bug on Ubuntu 22.04.

The `forwardPorts` Section

You might need to expose some specific port numbers – 7071 for Azure Functions, 5000 and 5001 for ASP.NET Web/API apps, and/or 4280 for Azure Static Web Apps.

"forwardPorts": [
  // Azure Functions
  7071,
  // ASP.NET Core Web/API App, Blazor App
  5000, 5001,
  // Azure Static Web App CLI
  4280
]

The `features` Section

On top of the base image, if you want to add more tools and/or languages, add them to the features section.

Common Utils: You can add zsh and oh-my-zsh through this feature.

"features": {
  // Install common utilities
  "ghcr.io/devcontainers/features/common-utils:1": {
    "installZsh": true,
    "installOhMyZsh": true,
    "upgradePackages": true,
    "username": "vscode",
    "uid": "1000",
    "gid": "1000"
  }
}

Azure CLI: You can add Azure CLI through this feature.

"features": {
  // Uncomment the below to install Azure CLI
  "ghcr.io/devcontainers/features/azure-cli:1": {
    "version": "latest"
  }
}

GitHub CLI: You can add GitHub CLI through this feature.

"features": {
  // Uncomment the below to install GitHub CLI
  "ghcr.io/devcontainers/features/github-cli:1": {
    "version": "latest"
  }
}

node.js: You can add the latest LTS version of node.js through this feature.

"features": {
  // Uncomment the below to install node.js
  "ghcr.io/devcontainers/features/node:1": {
    "version": "lts",
    "nodeGypDependencies": true,
    "nvmInstallPath": "/usr/local/share/nvm"
  }
}

Suppose you have another feature, but it doesn't exist yet in this features list. In that case, you can manually add it through the postCreateCommand attribute by invoking post-create.sh.

Do you want to add those features in order? Then use this overrideFeatureInstallOrder attribute. Here in this post, the common-utils feature runs first, and then the rest features are installed in random order.

"overrideFeatureInstallOrder": [
  "ghcr.io/devcontainers/features/common-utils"
]

The `customizations.vscode.extensions` Section

You might have some extensions automatically installed while creating the DevContainer. The customisations.vscode.extensions section holds all the extensions you want to install. The list of extensions below is for Azure and .NET app development. If you want to add more, search them on Visual Studio Code Marketplace and add their extension ID. For example, the C# extension has its extension ID of ms-dotnettools.csharp.

"customizations": {
  "vscode": {
    "extensions": [
      // Recommended extensions - GitHub
      "cschleiden.vscode-github-actions",
      "GitHub.vscode-pull-request-github",

      // Recommended extensions - Azure
      "ms-azuretools.vscode-bicep",

      // Recommended extensions - Collaboration
      "eamodio.gitlens",
      "EditorConfig.EditorConfig",
      "MS-vsliveshare.vsliveshare-pack",
      "streetsidesoftware.code-spell-checker",

      // Recommended extensions - .NET
      "Fudge.auto-using",
      "jongrant.csharpsortusings",
      "kreativ-software.csharpextensions",

      // Recommended extensions - Power Platform
      "microsoft-IsvExpTools.powerplatform-vscode",

      // Recommended extensions - Markdown
      "bierner.github-markdown-preview",
      "DavidAnson.vscode-markdownlint",
      "docsmsft.docs-linting",
      "johnpapa.read-time",
      "yzhang.markdown-all-in-one",

      // Required extensions
      "GitHub.copilot",
      "ms-dotnettools.csharp",
      "ms-vscode.PowerShell",
      "ms-vscode.vscode-node-azure-pack",
      "VisualStudioExptTeam.vscodeintellicode"
    ]
  }
}

The `customizations.vscode.settings` Section

You might also want to personalise your editor settings while creating the DevContainer. You can set them on the customizations.vscode.settings section. The list of settings below are examples of personalised settings. If you want to get them more personalised, refer to the User and Workspace Settings page.

The bash shell is the default terminal. If you want to change its default behaviour to zsh, use these settings.

"customizations": {
  "vscode": {
    "settings": {
      // Uncomment if you want to use zsh as the default shell
      "terminal.integrated.defaultProfile.linux": "zsh",
      "terminal.integrated.profiles.linux": {
        "zsh": {
          "path": "/usr/bin/zsh"
        }
      }
    }
  }
}

If you want to change your terminal font, use this setting. It's specifically for oh-my-zsh or oh-my-posh.

"customizations": {
  "vscode": {
    "settings": {
      // Uncomment if you want to use CaskaydiaCove Nerd Font as the default terminal font
      "terminal.integrated.fontFamily": "CaskaydiaCove Nerd Font"
    }
  }
}

If you want to disable the minimap feature, use this setting.

"customizations": {
  "vscode": {
    "settings": {
      // Uncomment if you want to disable the minimap view
      "editor.minimap.enabled": false
    }
  }
}

If you want to change the behaviour of the explorer, use these settings. All files are sorted by extension and nested by relevant files.

"customizations": {
  "vscode": {
    "settings": {
      // Recommended settings for the explorer pane
      "explorer.sortOrder": "type",
      "explorer.fileNesting.enabled": true,
      "explorer.fileNesting.patterns": {
        "*.bicep": "${capture}.json",
        "*.razor": "${capture}.razor.css",
        "*.js": "${capture}.js.map"
      }
    }
  }
}

The `postCreateCommand` Section

Once your DevContainer is created, you might want to do something more. For example, you can't add an extra feature through the features section because it's not ready. However, executing a shell script can add those additional features through this postCreateCommand section.

Here's the one for running post-create.sh through the bash shell.

"postCreateCommand": "/bin/bash ./.devcontainer/post-create.sh > ~/post-create.log",

Here's the one for running post-create.sh through the zsh shell.

"postCreateCommand": "/usr/bin/zsh ./.devcontainer/post-create.sh > ~/post-create.log",

Let's take a look at what happens within post-create.sh.

`post-create.sh` Execution

This post-create.sh is run right after the DevContainer is created.

CaskaydiaCove Nerd Font

It's a good idea to install a custom font, if you use either oh-my-zsh or oh-my-posh for your terminal. The following script is to install CaskaydiaCove Nerd Font.

## CaskaydiaCove Nerd Font
# Uncomment the below to install the CaskaydiaCove Nerd Font
mkdir $HOME/.local
mkdir $HOME/.local/share
mkdir $HOME/.local/share/fonts
wget https://github.com/ryanoasis/nerd-fonts/releases/latest/download/CascadiaCode.zip
unzip CascadiaCode.zip -d $HOME/.local/share/fonts
rm CascadiaCode.zip

Azure CLI Extensions

You can run this script if you install Azure CLI through the feature section of devcontainer.json. However, because it adds ALL extensions, it takes about 30-60 mins, depending on your network latency. Therefore be careful to use.

## AZURE CLI EXTENSIONS ##
# Uncomment the below to install Azure CLI extensions
extensions=$(az extension list-available --query "[].name" | jq -c -r '.[]')
for extension in $extensions;
do
    az extension add --name $extension
done

You can use extensions=(list of selected extensions you want), instead of using extensions=$(az extension list-available --query "[].name" | jq -c -r '.[]'). For example, I use extensions=(account alias deploy-to-azure functionapp subscription webapp).

Azure Bicep CLI

If you use Azure Bicep, you can run this script to install Bicep CLI.

## AZURE BICEP CLI ##
# Uncomment the below to install Azure Bicep CLI
az bicep install

Azure Functions Core Tools

Do you develop Azure Functions apps? Then activate this script. As it installs through npm, you should install the node.js feature through the features section of devcontainer.json.

## AZURE FUNCTIONS CORE TOOLS ##
# Uncomment the below to install Azure Functions Core Tools
npm i -g azure-functions-core-tools@4 --unsafe-perm true

Azure Static Web Apps CLI

Unlock this script if you're building a Blazor WASM app and deploying it to Azure Static Web Apps. Like Azure Functions Core Tools, it relies on the node.js feature through the features section of devcontainer.json.

## AZURE STATIC WEB APPS CLI ##
# Uncomment the below to install Azure Static Web Apps CLI
npm install -g @azure/static-web-apps-cli

Azure Dev CLI

If you want to activate the Azure Dev CLI, run the following script. Azure Dev CLI needs both Azure CLI and GitHub CLI as dependencies. Therefore, make sure you have already installed them through the features section of devcontainer.json.

## AZURE DEV CLI ##
# Uncomment the below to install Azure Dev CLI
curl -fsSL https://aka.ms/install-azd.sh | bash

oh-my-zsh – Plugins and Themes

There are a bunch of plugins and themes for oh-my-zsh. You can follow the pattern below. Here are some recommended plugins and theme – powerlevel10k.

## OH-MY-ZSH PLUGINS & THEMES (POWERLEVEL10K) ##
# Uncomment the below to install oh-my-zsh plugins and themes (powerlevel10k) without dotfiles integration
git clone https://github.com/zsh-users/zsh-completions.git $HOME/.oh-my-zsh/custom/plugins/zsh-completions
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git $HOME/.oh-my-zsh/custom/plugins/zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-autosuggestions.git $HOME/.oh-my-zsh/custom/plugins/zsh-autosuggestions

git clone https://github.com/romkatv/powerlevel10k.git $HOME/.oh-my-zsh/custom/themes/powerlevel10k --depth=1
ln -s $HOME/.oh-my-zsh/custom/themes/powerlevel10k/powerlevel10k.zsh-theme $HOME/.oh-my-zsh/custom/themes/powerlevel10k.zsh-theme

oh-my-zsh – powerlevel10k Theme Configurations

powerlevel10k has its settings file, called p10k.zsh. I've got my own p10k.zsh settings – with a clock and without the clock. Activate the script below to copy them to DevContainer. You don't need to run the following script if you have your own ones from your dotfiles repository.

## OH-MY-ZSH - POWERLEVEL10K SETTINGS ##
# Uncomment the below to update the oh-my-zsh settings without dotfiles integration
curl https://raw.githubusercontent.com/justinyoo/devcontainers-dotnet/main/oh-my-zsh/.p10k-with-clock.zsh > $HOME/.p10k-with-clock.zsh
curl https://raw.githubusercontent.com/justinyoo/devcontainers-dotnet/main/oh-my-zsh/.p10k-without-clock.zsh > $HOME/.p10k-without-clock.zsh
curl https://raw.githubusercontent.com/justinyoo/devcontainers-dotnet/main/oh-my-zsh/switch-p10k-clock.sh > $HOME/switch-p10k-clock.sh
chmod +x ~/switch-p10k-clock.sh

cp $HOME/.p10k-with-clock.zsh $HOME/.p10k.zsh
cp $HOME/.zshrc $HOME/.zshrc.bak

echo "$(cat $HOME/.zshrc)" | awk '{gsub(/ZSH_THEME=\"codespaces\"/, "ZSH_THEME=\"powerlevel10k\"")}1' > $HOME/.zshrc.replaced && mv $HOME/.zshrc.replaced $HOME/.zshrc
echo "$(cat $HOME/.zshrc)" | awk '{gsub(/plugins=\(git\)/, "plugins=(git zsh-completions zsh-syntax-highlighting zsh-autosuggestions)")}1' > $HOME/.zshrc.replaced && mv $HOME/.zshrc.replaced $HOME/.zshrc
echo "
# To customize prompt, run 'p10k configure' or edit ~/.p10k.zsh.
[[ ! -f ~/.p10k.zsh ]] || source ~/.p10k.zsh
" >> $HOME/.zshrc

oh-my-posh – Installation

Are you into PowerShell but also want to use something like oh-my-zsh? Then oh-my-posh is your friend. Run the following script to install.

## OH-MY-POSH ##
# Uncomment the below to install oh-my-posh
sudo wget https://github.com/JanDeDobbeleer/oh-my-posh/releases/latest/download/posh-linux-amd64 -O /usr/local/bin/oh-my-posh
sudo chmod +x /usr/local/bin/oh-my-posh

oh-my-posh – Configurations

oh-my-posh has its own powerlevel10k configurations. Run the following script to copy those settings files to your DevContainer. Again, if you've set them on your dotfiles repository, you don't need to run the script below.

## OH-MY-POSH - POWERLEVEL10K SETTINGS ##
# Uncomment the below to update the oh-my-posh settings without dotfiles integration
curl https://raw.githubusercontent.com/justinyoo/devcontainers-dotnet/main/oh-my-posh/p10k-with-clock.omp.json > $HOME/p10k-with-clock.omp.json
curl https://raw.githubusercontent.com/justinyoo/devcontainers-dotnet/main/oh-my-posh/p10k-without-clock.omp.json > $HOME/p10k-without-clock.omp.json
curl https://raw.githubusercontent.com/justinyoo/devcontainers-dotnet/main/oh-my-posh/switch-p10k-clock.ps1 > $HOME/switch-p10k-clock.ps1

mkdir $HOME/.config/powershell
curl https://raw.githubusercontent.com/justinyoo/devcontainers-dotnet/main/oh-my-posh/Microsoft.PowerShell_profile.ps1 > $HOME/.config/powershell/Microsoft.PowerShell_profile.ps1

cp $HOME/p10k-with-clock.omp.json $HOME/p10k.omp.json

Once you complete the configuration like above, run your GitHub Codespaces instance. Then, you will see the terminal like below. On the left-hand side, it's the zsh shell applying oh-my-zsh. On the right-hand side, it's PowerShell using oh-my-posh.

So far, we've discussed what the DevContainer is, how it is helpful for .NET app development on Azure, and what needs to be configured for DevContainer for .NET app development on Azure, using GitHub Codespaces. What has been discussed here in this post is the only small part of the DevContainer. Therefore, if you want to apply it to your or your team's development environment, you need to do more research by yourself. However, I hope this post gives at least some sort of insights for building DevContainers.

Want to know more about DevContainers?

There are documents and learning materials for you:

Blazor WASM Custom 404 Page on GH Pages

Justin Yoo — Fri, 07 Oct 2022 00:11:55 +0000

It might be necessary to implement the custom 404 page while developing a Blazor WebAssembly (WASM) app. But when you deploy your Blazor WASM app to GitHub Pages, it only shows GitHub's 404 page, not yours. Although there are many workarounds for this, throughout this post, I'm going to discuss how to use a Blazor web component for the 404 page on GitHub Pages.

You can download the sample application on this GitHub repository.

fitability / fitability.github.io

fitability™️ – your friendly fitness activity tracking app

fitability™️ – your friendly fitness activity tracking app

fitability™️ is an app that runs on your preferred platform – web, desktop or mobile – which traces your fitness activities, and shares them with your friends or on social media.

It's all open-sourced under the MIT license.

Repositories

fitability-docs: Documents

fitability-app: Applications

fitability-power: Power Apps app

Credits

Icons made by Freepik from www.flaticon.com

View on GitHub

Blazor WASM – Default 404 Page

The default 404 page right after you create a Blazor WASM app project looks like this:

It's because App.razor defines like that.

@* BlazorApp1.App.razor *@

<Router AppAssembly="@typeof(App).Assembly">
    ...
    <NotFound>
        <PageTitle>Not found</PageTitle>
        <LayoutView Layout="@typeof(MainLayout)">
            @* ⬇️⬇️⬇️ This is the content ⬇️⬇️⬇️*@
            <p role="alert">Sorry, there's nothing at this address.</p>
            @* ⬆️⬆️⬆️ This is the content ⬆️⬆️⬆️*@
        </LayoutView>
    </NotFound>
</Router>

Therefore, all you need to customise your 404 page is this part.

Blazor WASM – Custom 404 Page

The sample app used in this post uses a customised 404 page. For the custom 404 page, create a web component called NotFound.razor.

@* Fitability.Home.Components.NotFound.razor *@

<div class="row">
    <div class="col-6">
        <img src="images/banner-3840x1920.png" class="img-fluid" alt="banner" />
    </div>
    <div class="col-6 d-flex align-items-center">
        <div class="row">
            <div class="col-12">
                <h1 class="text-center">Not Found!</h1>
                <p class="text-center fs-2">Your requested page doesn't exist.</p>
                <p class="text-center fs-3"><a href="/" class="btn btn-primary btn-lg">Home</a></p>
            </div>
        </div>
    </div>
</div>

Then, import it within the LayoutView component of App.razor

@* Fitability.Home.App.razor *@

<Router AppAssembly="@typeof(App).Assembly">
    ...
    <NotFound>
        <LayoutView Layout="@typeof(MainLayout)">
            @* ⬇️⬇️⬇️ Add the NotFound component here ⬇️⬇️⬇️*@
            <NotFound />
            @* ⬆️⬆️⬆️ Add the NotFound component here ⬆️⬆️⬆️*@
        </LayoutView>
    </NotFound>
</Router>

Run your Blazor WASM app on your local machine, and you will see the custom 404 page.

GitHub Pages – Default 404 Page

However, deploy your Blazor WASM app to GitHub Pages and visit any non-existing URL. Then you will see GitHub's default 404 page.

It's because GitHub displays their default 404 page if someone visits the non-existing page. Let's change this.

GitHub Pgaes – Custom 404 Page

The 404.html file MUST physically exist to use the custom 404 page on your GitHub Pages. Generally speaking, you can prepare hard-coded 404.html for this purpose. But we're using the Blazor WASM's routing pipeline.

Copy the existing index.html file to 404.html. Both are fundamentally the same file as each other.
Create the 404.razor page and import the NotFound component. The routing path of this 404.razor page MUST be /404.html.
```
@* Fitability.Home.Pages.404.razor *@

@page "/404.html"

<NotFound />
```

Deploy your Blazor WASM app to GitHub Pages again and visit any non-existing URL. Then, you will be able to see your custom 404 page.

It's because GitHub Pages looks for the physical 404.html file. This file runs on the Blazor WASM routing pipeline. Therefore, you can write any business logic on your 404 page.

So far, we've walked through how to deal with the custom 404 page of the Blazor WASM app running on GitHub Pages.

Want to know more about Blazor?

It's great if you visit those sites for more Blazor stuff.

Azure AD B2C on Blazor WASM Standalone

Justin Yoo — Sat, 24 Sep 2022 00:00:27 +0000

There are many ways to implement authentication and authorisation onto the Blazor WebAssembly (WASM) app. If you publish it to Azure Static Web Apps (ASWA), you can use the built-in authN feature (in my previous post). What if you're publishing your Blazor WASM app onto GitHub Pages? There's no built-in authN feature in this case. However, Azure AD B2C offers a straightforward way for it. You can see literally nothing to write codes to make this happen except a few configurations. Throughout this post, I'm going to discuss how to integrate Azure AD B2C with a standalone type Blazor WASM app.

Azure AD vs Azure AD B2C

As the naming implies, both Azure AD and Azure AD B2C are similar to each other. In terms of the authentication and authorisation service provider, both are basically the same as each other.

What are some differences, then? Azure AD does granular controls for internal (organisation-wide) resources like SharePoint, Teams, Dynamics365, etc. Azure AD sets permissions on each resource and account. On the other hand, Azure AD B2C provides the same authN-ing feature, but it's for specific applications. As Azure AD B2C works independently from Azure AD, it's NOT for organisation-wide purposes unless it's configured in that way.

Configuring Azure AD B2C

Create an Azure AD B2C instance from Azure Portal. You can give any name for it, but let's say fitabilitydevkr for now. Then, you'll get the Azure AD B2C instance like below.

Click the "Open B2C Tenant" link to access the Azure AD B2C admin page. On the admin page, click the "App registrations" menu on the left. Then click the "New registration" button at the top.

Enter the details like below:

Name: Name of the app. Say, my-fitability-app.
Supported account types: Choose the option "Accounts in any identity provider or organisational directory".
Redirect URI (Recommended): Select "Single-page Application (SPA)", then enter https://localhost/authentication/login-callback.
Permissions: Tick "Grant admin consent to openid and offline_access permissions"

Once registered, double-check the following details:

Single-page Application – Redirect URIs
Implicit grant and hybrid flows – Access tokens, ID tokens
Supported account types – Accounts in any identity provider or organisational directory

You can now see the new app registered. Note the application (client) ID.

Let's define the log-in process. On the Azure AD B2C page, click the "User flows" menu on the left, then the "New user flow" menu at the top.

There are many different user flow types. This time, choose the "Sign up and sign in" flow. Then, select "Recommended".

Enter the following values, and click "Create".

Name: SignUpSignIn
Identity providers: Email Signup

You can add as many identity providers as you like. But in this post, you can only choose the email sign-up option by default.

Tick more options if you want to include more details in the token.

You now complete Azure AD B2C configurations.

Building Blazor WASM App

To implement the authN feature with Azure AD B2C on a Blazor WASM app, you first need to create a Blazor WASM project. At the time of this writing, the latest version of Visual Studio is 17.3.4, which doesn't create the Blazor WASM project with Azure AD B2C integration, unfortunately.

Therefore, you SHOULD use dotnet CLI for it. Enter the command below. You might be noticed the following options:

--framework net6.0: Without giving the framework option explicitly, it uses the latest version of the .NET framework. It explicitly declares the net6.0 value to fix the framework version.
--hosted false: If you want to create a standalone Blazor WASM app, use this option. If you want a hosted Blazor WASM app, give this option with true.
--auth IndividualB2C: Choose this option to use Azure AD B2C.
--aad-b2c-instance "https://<TENANT_NAME>.b2clogin.com/": It's the login URL of the Azure AD B2C instance. In this post, let's use the tenant name fitabilitydevkr.
--domain "<TENANT_NAME>.onmicrosoft.com": It's the domain URL of the Azure AD B2C instance. In this post, let's use the tenant name fitabilitydevkr.
--client-id: The client ID value from the app created in the previous section.
--susi-policy-id "B2C_1_SignUpSignIn": The policy name for authN. Use the policy name that you just created. In this post, use SignUpSignIn.

dotnet new blazorwasm \
    --output "MyBlazorWasmApp" \
    --framework net6.0 \
    --hosted false \
    --auth IndividualB2C \
    --aad-b2c-instance "https://<TENANT_NAME>.b2clogin.com/" \
    --domain "<TENANT_NAME>.onmicrosoft.com" \
    --client-id "<CLIENT_ID>" \
    --susi-policy-id "B2C_1_SignUpSignIn"

Now, you've got Azure AD B2C enabled on the Blazor WASM app. Let's configure the app. Open Program.cs and add the AddMsalAuthentication(...) method.

builder.Services.AddScoped(sp => new HttpClient
{
    BaseAddress = new Uri(builder.HostEnvironment.BaseAddress)
});

// ⬇️⬇️⬇️ Add these lines below ⬇️⬇️⬇️
builder.Services.AddMsalAuthentication(options =>
{
    options.ProviderOptions.DefaultAccessTokenScopes.Add("openid");
    options.ProviderOptions.DefaultAccessTokenScopes.Add("offline_access");

    builder.Configuration.Bind("AzureAdB2C", options.ProviderOptions.Authentication);
});
/// ⬆️⬆️⬆️ Add these lines above ⬆️⬆️⬆️

await builder.Build().RunAsync();

Then, update appsettings.json under the wwwroot directory.

{
  "AzureAdB2C": {
    "Authority": "https://<TENANT_NAME>.b2clogin.com/<TENANT_NAME>.onmicrosoft.com/B2C_1_SignUpSignIn",
    "ClientId": "<CLIENT_ID>",
    "ValidateAuthority": false
  }
}

All the configurations on the Blazor WASM app side are done! Build and run the app on your local machine.

You will see the "Log in" button at the top right corner. Click it to see the log-in pop-up window.

Add your email address and password to log-in, or register a new account by clicking the "Sign up now" button. Once you get logged in, you will see the screen like below:

Can you see your username?

So far, I've walked through how to add the Azure AD B2C authN feature to the standalone type Blazor WASM app. With minimum code change, you can quickly implement the authN feature. In the next post, I'll give a try to add a social media log-in feature to Azure AD B2C.

Want to know more about Blazor?

It's great if you visit those sites for more Blazor stuff.

Want to know more about Azure AD B2C with Blazor?

There are several documents that you might follow for Blazor WASM and Azure AD B2C integration scenarios.

Browser Extension with Blazor WASM - Cross-Browser Compatibility

Justin Yoo — Mon, 05 Sep 2022 12:00:22 +0000

In my previous post, I discussed the JavaScript interop feature in Blazor WebAssembly (WASM) and how to leverage it for the Chrome extension development. In this post, I'm going to expand the same extension to support cross-browser compatibility, like Mozilla Firefox, and what to consider for compatibility.

You can download the sample Chrome extension from this GitHub repository:
devkimchi / blazor-wasm-chrome-extension

This provides sample codes for a Chrome Extension app built on Blazor WASM
Blazor WASM Browser Extension Sample

This provides sample codes for a cross-browser extension app built on Blazor WASM. This sample app originally started for building a Chrome extension with Blazor WASM, but it now does the cross-browser support including Chromium-based browsers and Mozilla FireFox.

Acknowledgement

This sample code includes Mozilla's WebExtension browser API Polyfill, which is licensed under MPL 2.0.

Getting Started
Build the app
dotnet build .
Publish the app
dotnet publish ./src/ChromeExtensionV2/ -c Release -o published
Run PowerShell script
./Run-PostBuild.ps1
Register the extension to your Chromium-based browser like Chrome or Edge, or Mozilla FireFox.

Visit any website on https://developer.chrome.com, https://developer.mozilla.org or https://docs.microsoft.com.

Run the extension by clicking the icon at the top of your web browser.
View on GitHub

Browser Extension Polyfill

The Browser Extension Working Group at W3.org proposes the web standards based on the Chrome extension manifest, which supports all web browsers. Based on that proposal, Mozilla has released the Browser Extension Polyfill library that supports the modern promise pattern instead of callback. Therefore, if you import this polyfill library, theoretically, your Chrome extension quickly turns into the browser extension that runs on multiple browser engines.

Therefore, add the polyfill library through CDN to index.html like below. The link takes the latest release of the polyfill.

<!DOCTYPE html>
<html lang="en">
...
<body>
    <div id="app">Loading...</div>
    ...
    <!-- ⬇️⬇️⬇️ Add this line ⬇️⬇️⬇️ -->
    <script src="https://unpkg.com/browse/webextension-polyfill/dist/browser-polyfill.min.js"></script>
    <!-- ⬆️⬆️⬆️ Add this line ⬆️⬆️⬆️ -->
    <script src="_framework/blazor.webassembly.js"></script>
</body>
</html>

However, you can't use the direct link to the polyfill because of the "Content Security Policy" violation error.

In order to sort out this issue, you should download the JavaScript file and give its local reference. Visit the CDN page and download each files and save them into the wwwroot/js/dist directory. Then, update the index.html file like below:

<!DOCTYPE html>
<html lang="en">
...
<body>
    <div id="app">Loading...</div>
    ...
    <!-- ⬇️⬇️⬇️ Add this line ⬇️⬇️⬇️ -->
    <script src="js/dist/browser-polyfill.min.js"></script>
    <!-- ⬆️⬆️⬆️ Add this line ⬆️⬆️⬆️ -->
    <script src="_framework/blazor.webassembly.js"></script>
</body>
</html>

Now, it's OK to use the polyfill. Next, let's move on to manifest.json for cross-browser support.

`manifest.json` Accommodation

First of all, you need to get rid of Chrome's exclusive features. Especially, as the Declarative Content part only works for the Chrome extensions, you need to replace it with other approaches. In this example, if you want the extension to only work with the domain like developer.chrome.com, developer.mozilla.org or docs.microsoft.com, add domain URLs to the permissions collection like below and remove the declarativeContent value from it.

{
  ...

  "permissions": [
    "*://developer.chrome.com/*",
    "*://developer.mozilla.org/*",
    "*://docs.microsoft.com/*",
    "activeTab",
    // "declarativeContent",
    "storage"
  ],

  ...
}

Then, add the polyfill to the background script collection.

{
  ...

  "background": {
    "scripts": [
      "js/dist/browser-polyfill.min.js",
      "js/background.js"
    ],
    "persistent": false
  },

  ...
}

Initially, manifest.json only uses the options_page attribute, but for compatibility, add the options_ui attribute as well.

{
  ...

  "options_page": "options.html",

  "options_ui": {
    "page": "options.html",
    "browser_style": true
  }

  ...
}

And finally, Mozilla-based browsers need a unique ID for each extension. Therefore, give the browser_specific_settings for it.

{
  ...

  "browser_specific_settings": {
    "gecko": {
      "id": "browser-extension-sample@devkimchi.com"
    }
  },

  ...
}

Updating manifest.json is over. Now, let's move on to the JavaScript files.

`background.js` Update

For background.js, you must change all the chrome. instances to the browser. ones because the chrome instances are specific to the Chrome extension, while the browser instances are for the browser extensions in general. In other words, if your background.js looks like the following:

chrome.runtime.onInstalled.addListener(function() {
  chrome.storage.sync.set({color: '#3aa757'}, function() {
    console.log("The color is green.");
  });

  chrome.declarativeContent.onPageChanged.removeRules(undefined, function() {
    chrome.declarativeContent.onPageChanged.addRules([{
      conditions: [
        new chrome.declarativeContent.PageStateMatcher({
          pageUrl: { hostEquals: 'developer.chrome.com' },
        }),
        new chrome.declarativeContent.PageStateMatcher({
          pageUrl: { hostEquals: 'docs.microsoft.com' },
        })
      ],
      actions: [new chrome.declarativeContent.ShowPageAction()]
    }]);
  });
});

All chrome. declared above must be replaced with browser. like below:

// Use 'browser.' instead of 'chrome.'
browser.runtime.onInstalled.addListener(function() {
  // Use 'browser.' instead of 'chrome.'
  browser.storage.sync.set({color: '#3aa757'}, function() {
    console.log("The color is green.");
  });

  // Use 'browser.' instead of 'chrome.'
  browser.declarativeContent.onPageChanged.removeRules(undefined, function() {
    // Use 'browser.' instead of 'chrome.'
    browser.declarativeContent.onPageChanged.addRules([{
      conditions: [
        // Use 'browser.' instead of 'chrome.'
        new browser.declarativeContent.PageStateMatcher({
          pageUrl: { hostEquals: 'developer.browser.com' },
        }),
        // Use 'browser.' instead of 'chrome.'
        new browser.declarativeContent.PageStateMatcher({
          pageUrl: { hostEquals: 'docs.microsoft.com' },
        })
      ],
      // Use 'browser.' instead of 'chrome.'
      actions: [new browser.declarativeContent.ShowPageAction()]
    }]);
  });
});

Once you replace all the chrome instances with browser ones, change all the callback patterns to promise patterns. For example, this example requires the browser's local storage access. How can it be changed?

  // Before
  browser.storage.sync.set({color: '#3aa757'}, function() {
    console.log("The color is green.");
  });

  // After
  browser.storage.sync.set({color: '#3aa757'})
  .then(() => {
    console.log("The color is green.");
  });

It's written as an anonymous function and added as the event handler to the onInstalled event. Therefore, it's better to create an independent function like the below:

function handleRuntimeOnInstalled(details) {
  browser.storage.sync.set({color: '#3aa757'})
  .then(() => {
    console.log("The color is green.");
  });
}

As mentioned above, we can't use the Declarative Content feature any longer. Hence, instead of the events that belong to the declarativeContent property, you need other events and event handlers. This sample extension only works in specific domains like developer.google.com, developer.mozilla.org or docs.microsoft.com, and the declarativeContent property performs this sort of detection. Therefore, replace it with the handleTabs() function like below, using the pageAction property.

function handleTabs() {
  browser.tabs.query({active: true, currentWindow: true})
  .then((tabs) => {
    console.log(tabs[0].url);

    let matched = tabs[0].url.includes('developer.chrome.com') || tabs[0].url.includes('developer.mozilla.org') || tabs[0].url.includes('docs.microsoft.com');
    if (matched) {
      browser.pageAction.show(tabs[0].id);
    } else {
      browser.pageAction.hide(tabs[0].id);
    }
  });
}

Once everything is done, register both event handlers for the events below:

browser.runtime.onInstalled.addListener(handleRuntimeOnInstalled);
browser.tabs.onActivated.addListener(handleTabs);
browser.tabs.onHighlighted.addListener(handleTabs);
browser.tabs.onUpdated.addListener(handleTabs);

`popup.js` Update

Let's update popup.js. It was initially like this:

let changeColor = document.getElementById('changeColor');

chrome.storage.sync.get('color', function(data) {
  changeColor.style.backgroundColor = data.color;
  changeColor.setAttribute('value', data.color);
});

changeColor.onclick = function(element) {
  let color = element.target.value;
  chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
    chrome.tabs.executeScript(
        tabs[0].id,
        {code: 'document.body.style.backgroundColor = "' + color + '";'});
  });
};

Like the same in the previous JavaScript file,

Replace all chrome. instances with browser. ones.
Change all callback patterns to the promise patterns.

let changeColor = document.getElementById('changeColor');

// Use 'browser.' instead of 'chrome.'
// Use the promise pattern
browser.storage.sync.get('color')
.then((data) => {
  changeColor.style.backgroundColor = data.color;
  changeColor.setAttribute('value', data.color);
});

changeColor.onclick = function(element) {
  let color = element.target.value;

  // Use 'browser.' instead of 'chrome.'
  // Use the promise pattern
  browser.tabs.query({active: true, currentWindow: true})
  .then((tabs) => {
    let matched = tabs[0].url.includes('developer.chrome.com') || tabs[0].url.includes('developer.mozilla.org') || tabs[0].url.includes('docs.microsoft.com');
    if (matched) {
      // Use 'browser.' instead of 'chrome.'
      browser.tabs.executeScript(
        tabs[0].id,
        {code: 'document.body.style.backgroundColor = "' + color + '";'});
    } else {
      console.log('URL not matched');
    }
  });
};

The popup.js is done.

`options.js` Update

This time, it's the turn for options.js, which initially looks like:

let page = document.getElementById('buttonDiv');

const kButtonColors = ['#3aa757', '#e8453c', '#f9bb2d', '#4688f1'];

function constructOptions(kButtonColors) {
  for (let item of kButtonColors) {
    let button = document.createElement('button');
    button.className = 'color-button';
    button.style.backgroundColor = item;
    button.style.padding = '10px';

    button.addEventListener('click', function() {
      chrome.storage.sync.set({color: item}, function() {
        console.log('color is ' + item);
      })
    });
    page.appendChild(button);
  }
}

constructOptions(kButtonColors);

Replace all chrome. instances with browser. ones.
Change all callback patterns to the promise patterns.

let page = document.getElementById('buttonDiv');

const kButtonColors = ['#3aa757', '#e8453c', '#f9bb2d', '#4688f1'];

function constructOptions(kButtonColors) {
  for (let item of kButtonColors) {
    let button = document.createElement('button');
    button.className = 'color-button';
    button.style.backgroundColor = item;
    button.style.padding = '10px';

    button.addEventListener('click', function() {
      // Use 'browser.' instead of 'chrome.'
      // Use the promise pattern
      browser.storage.sync.set({color: item})
      .then(() => {
        console.log('color is ' + item);
      })
    });
    page.appendChild(button);
  }
}

constructOptions(kButtonColors);

The options.js file is updated.

Blazor Component Abstraction

Suppose you want to get rid of importing the browser polyfill from index.html and import it directly from the Blazor components. In that case, it's a good idea to create a common page component that each Popup.razor and Options.razor can inherit. First of all, declare a LoadAdditionalJsAsync() method that is called within the OnAfterRenderAsync(...) method.

public class PageComponentBase : ComponentBase
{
    protected abstract Task LoadAdditionalJsAsync();
}

Then, invoke the method at the end of OnAfterRenderAsync(...). By doing so, the OnAfterRenderAsync(...) method first imports the js/main.js followed by the browser polyfill script, then import the page-specific JavaScript files.

public class PageComponentBase : ComponentBase
{
    [Inject]
    private IJSRuntime JS { get; set; }

    protected IJSObjectReference Module { get; private set; }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        this.Module = await this.JS.InvokeAsync<IJSObjectReference>("import", "./js/main.js");

        var src = "js/dist/browser-polyfill.min.js";
        await this.Module.InvokeVoidAsync("loadJs", src);

        // Invoke the page-specific JavaScript loader
        await this.LoadAdditionalJsAsync();
    }

    protected abstract Task LoadAdditionalJsAsync();
}

With the Popup.razor page, inherit the PageComponentBase class and implement the LoadAdditionalJsAsync() method like below, which imports the js/popup.js file. You don't need the IJSRuntime instance as a dependency any longer, so remove it.

@page "/popup.html"

@* @inject IJSRuntime JS *@

@using ChromeExtensionV2.Components
@inherits PageComponentBase

...

@code {
    protected override async Task LoadAdditionalJsAsync()
    {
        var src = "js/popup.js";
        await this.Module.InvokeVoidAsync("loadJs", src);
    }
}

Similarly, the Options.razor page also inherits the PageComponentBase class and implement the LoadAdditionalJsAsync() method to import js/options.js. The IJSRuntime dependency is no longer necessary, either.

@page "/options.html"

@* @inject IJSRuntime JS *@

@using ChromeExtensionV2.Components
@inherits PageComponentBase

...

@code {
    protected override async Task LoadAdditionalJsAsync()
    {
        var src = "js/options.js";
        await this.Module.InvokeVoidAsync("loadJs", src);
    }
}

`Run-PostBuild.ps1` Adjustment

Unlike the Chrome extensions, the Mozilla-based web extension needs a .zip file for installation. Therefore, the PowerShell script, Run-PostBuild.ps1, requires an additional step to generate a .zip file as an artifact.

Compress-Archive -Path ./published/wwwroot/* -DestinationPath ./published/wwwroot/wwwroot.zip -Force

Once you complete all the steps above, build the project and run the PowerShell script, and it will generate the wwwroot.zip file under the published directory. Next, install the zip file to Firefox, and you will see the screen below:

You can see the options page as a pop-up modal due to the manifest.json update. In the options modal, change the background colour to yellow.

Then, you are able to change the background colour to yellow.

So far, we've walked through how our Blazor WASM-based chrome extension can support cross-browser compatibility and showed how it works on the Firefox browser.

Do you want to know more about Blazor?

Here are some tutorials for you.

Chrome Extension with Blazor WASM - The Integration

Justin Yoo — Fri, 22 Jul 2022 00:00:31 +0000

In my previous post, I've walked through how to migrate a JavaScript-based Chrome extension to Blazor WASM with minimal code changes. Although it's successfully migrated to Blazor WASM, it doesn't fully use the JavaScript Interoperability (JS interop) feature, which is the powerful feature of Blazor WASM. I'm going to take this feature throughout this post.

You can download the sample Chrome extension from this GitHub repository:
devkimchi / blazor-wasm-chrome-extension

This provides sample codes for a Chrome Extension app built on Blazor WASM
Blazor WASM Browser Extension Sample

This provides sample codes for a cross-browser extension app built on Blazor WASM. This sample app originally started for building a Chrome extension with Blazor WASM, but it now does the cross-browser support including Chromium-based browsers and Mozilla FireFox.

Acknowledgement

This sample code includes Mozilla's WebExtension browser API Polyfill, which is licensed under MPL 2.0.

Getting Started
Build the app
dotnet build .
Publish the app
dotnet publish ./src/ChromeExtensionV2/ -c Release -o published
Run PowerShell script
./Run-PostBuild.ps1
Register the extension to your Chromium-based browser like Chrome or Edge, or Mozilla FireFox.

Visit any website on https://developer.chrome.com, https://developer.mozilla.org or https://docs.microsoft.com.

Run the extension by clicking the icon at the top of your web browser.
View on GitHub

Chrome Extension – Before JS Interop

The index.html file written in the previous post looks like the following. It loads blazor.webassembly.js first with the autostart="false" option, followed by loading js/main.js through the function call. The js/main.js reference is replaced with js/options.js or js/popup.js during the artifact generation process.

<!DOCTYPE html>
<html lang="en">
...
<body>
    <div id="app">Loading...</div>
    ...
    <!-- Add the 'autostart' attribute and set its value to 'false' -->
    <script src="_framework/blazor.webassembly.js" autostart="false"></script>
    <!-- ⬇️⬇️⬇️ Add these lines ⬇️⬇️⬇️ -->
    <script>
        Blazor.start().then(function () {
            var customScript = document.createElement('script');
            customScript.setAttribute('src', 'js/main.js');
            document.head.appendChild(customScript);
        });
    </script>
    <!-- ⬆️⬆️⬆️ Add these lines ⬆️⬆️⬆️ -->
</body>
</html>

I'm not happy with this JS loading due to the two reasons below:

I have to explicitly give the option of autostart="false" while loading the blazor.webassembly.js file, which is extra to the bootstrapper.
I have to append js/main.js through the Promise pattern after Blazor.start(), which is another extra point to the bootstrapper.

Can we minimise this modification from the original index.html file and use more JS Interop capabilities here so that it can be more Blazor-ish?

Chrome Extension – JS Interop Step #1

Let's update the index.html file. Unlike the previous update, remove the JS part calling the Blazor.start() function. Load js/main.js before loading blazor.webassembly.js. Remove the autostart="false" attribute as well.

<!DOCTYPE html>
<html lang="en">
...
<body>
    <div id="app">Loading...</div>
    ...
    <!-- ⬇️⬇️⬇️ Add this line ⬇️⬇️⬇️ -->
    <script src="js/main.js"></script>
    <!-- ⬆️⬆️⬆️ Add this line ⬆️⬆️⬆️ -->
    <script src="_framework/blazor.webassembly.js"></script>
</body>
</html>

Originally the js/main.js file was blank, but this time let's add the following JS function that appends another script tag to load the given JS file reference.

function loadJs(sourceUrl) {
  if (sourceUrl.Length == 0) {
    console.error("Invalid source URL");
    return;
  }

  var tag = document.createElement('script');
  tag.src = sourceUrl;
  tag.type = "text/javascript";

  tag.onload = function () {
    console.log("Script loaded successfully");
  }

  tag.onerror = function () {
    console.error("Failed to load script");
  }

  document.body.appendChild(tag);
}

Update the Popup.razor file like below:

Add the @inject declaration for the IJSRuntime instance as a dependency.
Call the JS.InvokeVoidAsync method to load the js/popup.js file by invoking the loadJs function from the js/main.js file.

@* Popup.razor *@

@page "/popup.html"

@* Inject IJSRuntime instance *@
@inject IJSRuntime JS

...

@code {
    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (!firstRender)
        {
            return;
        }

        var src = "js/popup.js";

        // Invoke the `loadJs` function
        await JS.InvokeVoidAsync("loadJs", src).ConfigureAwait(false);
    }
}

Update the Options.razor file in the same way.

@* Options.razor *@

@page "/options.html"

@* Inject IJSRuntime instance *@
@inject IJSRuntime JS

...

@code {
    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (!firstRender)
        {
            return;
        }

        var src = "js/options.js";

        // Invoke the `loadJs` function
        await JS.InvokeVoidAsync("loadJs", src).ConfigureAwait(false);
    }
}

Now, we don't need the reference replacement part in the PowerShell script. Let's comment them out.

# Run-PostBuild.ps1

...

# Update-FileContent `
#     -Filename "./published/wwwroot/popup.html" `
#     -Value1 "js/main.js" `
#     -Value2 "js/popup.js"

# Update-FileContent `
#     -Filename "./published/wwwroot/options.html" `
#     -Value1 "js/main.js" `
#     -Value2 "js/options.js"

Build and publish the Blazor WASM app, then run the PowerShell script to get ready for the extension loading. Once reload the extension, it works with no issue. The loadJs function is the key that takes advantage of the JS Interop feature.

However, I'm still not happy with adding js/main.js to index.html. Can we also remove this part from the file and use the JS Interop feature instead?

Chrome Extension – JS Interop Step #2

Let's get index.html back to the original state when a bootstrapper creates the file. Then, all we can see in index.html is the blazor.webassembly.js file reference.

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
    <title>ChromeExtensionV2</title>
    <base href="/" />
    <link href="css/bootstrap/bootstrap.min.css" rel="stylesheet" />
    <link href="css/app.css" rel="stylesheet" />
    <link href="ChromeExtensionV2.styles.css" rel="stylesheet" />
</head>

<body>
    <div id="app">Loading...</div>

    <div id="blazor-error-ui">
        An unhandled error has occurred.
        <a href="" class="reload">Reload</a>
        <a class="dismiss">🗙</a>
    </div>
    <script src="_framework/blazor.webassembly.js"></script>
</body>
</html>

Then, add the export declaration in front of the loadJs function in the js/main.js file.

export function loadJs(sourceUrl) {
...
}

Update Popup.razor like below.

...
var src = "js/popup.js";

// Import the `js/main.js` file
var module = await JS.InvokeAsync<IJSObjectReference>("import", "./js/main.js").ConfigureAwait(false);

// Invoke the `loadJs` function
await module.InvokeVoidAsync("loadJs", src).ConfigureAwait(false);

The same change should also be applicable to Options.razor. And finally, update the manifest.json below because we no longer need the hash key for popup.js and options.js.

{
  "manifest_version": 2,
  "version": "1.0",
  "name": "Getting Started Example (Blazor WASM)",
  "description": "Build an Extension!",

  ...

  "content_security_policy": "script-src 'self' 'unsafe-eval' 'wasm-unsafe-eval' 'sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA='; object-src 'self'",

  ...
}

Build and publish the app, and run the PowerShell script against the artifact. Then, reload the extension, and you will see the same result.

So far, we've walked through how to take more advantage of the JS Interop feature that Blazor WASM offers to migrate the existing Chrome extension to Blazor WASM. What could be the potential merits of this exercise?

We never touch any bootstrapper codes that Blazor WASM generate for us.
If necessary, we load JavaScript for each page using the JS Interop feature. During this practice, C# handles all the JS codes.

Then, does this exercise only brings you benefits? Here are a couple of considerations:

The code gets overly complex. If we simply import the JavaScript files through the index.html/popup.html/options.html, we don't need to do this exercise.
Not everytime the dynamic JS loading is useful. It has trade-offs. If you don't want to touch the bootstrapper files, then try this approach discussed in this post. But if you do touch the bootstrapper files, then this dynamic JS loading approach may be unsuitable.

Overall, if we use more JS Interop features appropriately, we can build the Blazor WASM app more effectively, which will be another option for building Chrome extensions. In the next post, I'm going to discuss cross-browser compatibility for this Blazor WASM-based browser extension.

Do you want to know more about Blazor?

Here are some tutorials for you.

Chrome Extension with Blazor WASM - The Migration

Justin Yoo — Fri, 08 Jul 2022 00:00:30 +0000

A Chrome extension is a tiny app used for Chromium-based web browsers for many purposes. It's like a web application serving static contents, which doesn't need a web server. If this is the case, what if we can build the Chrome extension using Blazor WebAssembly? Throughout this post, I'm going to migrate the existing JavaScript-based Chrome extension to Blazor WebAssembly with minimal code changes.

You can download the sample Chrome extension from this GitHub repository:
devkimchi / blazor-wasm-chrome-extension

This provides sample codes for a Chrome Extension app built on Blazor WASM
Blazor WASM Browser Extension Sample

This provides sample codes for a cross-browser extension app built on Blazor WASM. This sample app originally started for building a Chrome extension with Blazor WASM, but it now does the cross-browser support including Chromium-based browsers and Mozilla FireFox.

Acknowledgement

This sample code includes Mozilla's WebExtension browser API Polyfill, which is licensed under MPL 2.0.

Getting Started
Build the app
dotnet build .
Publish the app
dotnet publish ./src/ChromeExtensionV2/ -c Release -o published
Run PowerShell script
./Run-PostBuild.ps1
Register the extension to your Chromium-based browser like Chrome or Edge, or Mozilla FireFox.

Visit any website on https://developer.chrome.com, https://developer.mozilla.org or https://docs.microsoft.com.

Run the extension by clicking the icon at the top of your web browser.
View on GitHub

Chrome Extension – JavaScript-based

There's a Chrome extension app based on the Manifest v2. Load it to your Edge browser, and it will look like the following image.

You can change the background colour if you run it on your web browser.

Because it's written in JavaScript, let's migrate this app to Blazor WebAssembly.

Due to the policy change, you cannot publish any Chrome extension based on the manifest v2 to Web Store from January 17th, 2022. I'm going to discuss the manifest v3 extension in the following posts.

Chrome Extension – Blazor WebAssembly-based

Create a Blazor WebAssembly project. In the newly created project, open the index.html file, and you will see the div tag having the id attribute of app.

Basically, Blazor WebAssembly handles the virtual DOM within the div tag with the app ID. Therefore, your Chrome extension should accommodate it. In the coming posts, I'll talk about how you manage the virtual DOM in a Blazor WebAssembply app.

There are several differences between the Chrome extension and the Blazor WebAssembly app. One of the differences is routing. Because Blazor WebAssembly relies on the routing with the virtual DOM, you only need one physical file, index.html.

Delete both Counter.razor and FetchData.razor, and add Popup.razor page.

@* Popup.razor *@

@page "/popup.html"

<PageTitle>Pop Up</PageTitle>

<h1>Pop Up - Chrome Extension with Blazor WASM</h1>

<button id="changeColor"></button>

Then, add Options.razor page.

@* Options.razor *@

@page "/options.html"

<PageTitle>Options</PageTitle>

<h1>Options - Chrome Extension with Blazor WASM</h1>

<div id="buttonDiv">
</div>
<div>
    <p>Choose a different background color!</p>
</div>

As you can see, each Razor page has the routing value of popup.html and options.html, respectively.

Once all is done, publish your Blazor WebAssembly app:

dotnet publish ./src/ChromeExtensionV2 -c Release -o published

You can confirm the published artifact:

It's time to register this migrated extension. However, you can't register it because of the error message below. The error message says that you can't use any directory name or filename starting with an underscore (_). Unfortunately, the Blazor WebAssembly app generates the _framework directory by default. Therefore, you can't directly use the published artifact.

It would be best if you changed all the underscored directories and filenames. In addition to that, it would be best if you change all the contents referencing underscored files or directories. You can easily do this with a PowerShell script or a bash shell script. I'm going to use the PowerShell script for this post.

# Run-PostBuild.ps1

function Update-FileContent {
    param (
        [string] $Filename,
        [string] $Value1,
        [string] $Value2
    )

    $content = Get-Content -Path $Filename -Raw
    $updated = $content -replace $Value1, $Value2
    Set-Content -Path $Filename -Value $updated -Force
}

Update-FileContent `
    -Filename "./published/wwwroot/_framework/blazor.webassembly.js" `
    -Value1 "_framework" `
    -Value2 "framework"

Update-FileContent `
    -Filename "./published/wwwroot/index.html" `
    -Value1 "_framework" `
    -Value2 "framework"

mv ./published/wwwroot/_framework ./published/wwwroot/framework

After running the PowerShell script, you'll be able to see the directory name changed.

Register the extension again. This time, another error occurs that no options.html file exists. In other words, you physically need the options.html file.

According to this error, any Chrome extension must have popup.html and/or options.html files. Both Razor files are not enough for page rendering. By the way, both popup.html and options.html files are fundamentally the same as the index.html that access the div tag having the app ID to handle the virtual DOM. So then, instead of manually creating both files, let's duplicate the existing index.html file by adding those commands to the PowerShell script.

# Run-PostBuild.ps1
...
cp ./published/wwwroot/index.html ./published/wwwroot/popup.html
cp ./published/wwwroot/index.html ./published/wwwroot/options.html

Rerun the script. Both popup.html and options.html are duplicated from index.html.

However, no error occurring during the registration process doesn't mean that the extension actually works. Click the "Inspect pop-up window" menu like the screenshot below.

Then, you'll see the developer tools window that says there are errors. It's because of the Content Security Policy.

To sort out this error, the manifest.json file needs the content_security_policy attribute.

{
  "manifest_version": 2,
  "version": "1.0",
  "name": "Getting Started Example (Blazor WASM)",
  "description": "Build an Extension!",

  ...

  "content_security_policy": "script-src 'self' 'unsafe-eval' 'wasm-unsafe-eval' 'sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA='; object-src 'self'",

  ...
}

Here are some details for the content_security_policy attribute:

unsafe-eval: For the Function() object, and setTimeout() and setInterval() functions.
wasm-unsafe-eval: For the web assembly binary files.
sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=: For the Blazor WebAssembly libraries.

After updating the manifest.json file, register the extension again. Everything looks OK.

However, we still don't see the button to change the background colour. It means that the extension still doesn't work as expected. It's because both popup.html and options.html don't have corresponding JavaScript files.

Both files are automatically generated from index.html through the PowerShell script. Therefore, add the JavaScript reference of js/main.js to index.html. Also, create an empty main.js file under the js directory.

<!DOCTYPE html>
<html lang="en">
...
<body>
    <div id="app">Loading...</div>
    ...
    <script src="_framework/blazor.webassembly.js"></script>
    <!-- ⬇️⬇️⬇️ Add this line ⬇️⬇️⬇️ -->
    <script src="js/main.js"></script>
    <!-- ⬆️⬆️⬆️ Add this line ⬆️⬆️⬆️ -->
</body>
</html>

Then, update the PowerShell script by adding the following lines so that both popup.html and options.html have the link to popup.js and options.js, respectively.

# Run-PostBuild.ps1
...
Update-FileContent `
    -Filename "./published/wwwroot/popup.html" `
    -Value1 "js/main.js" `
    -Value2 "js/popup.js"

Update-FileContent `
    -Filename "./published/wwwroot/options.html" `
    -Value1 "js/main.js" `
    -Value2 "js/options.js"

Re-register the extension and see how it's going. But another error has occurred this time. Both JavaScript files worked perfectly with no issue but not in the Blazor WebAssembly. Why is that?

The blazor.webassembly.js file knows the answer. This JavaScript file initiates the Blazor WebAssembly app, followed by loading either popup.js or options.js. Unfortunately, those files are loaded even before the Blazor app is initiated, which causes the error above.

Therefore, to figure out this problem, you need to update the JavaScript reference section like below. JS interop for Blazor WebAssembly has more information if you want to know more.

<!DOCTYPE html>
<html lang="en">
...
<body>
    <div id="app">Loading...</div>
    ...
    <!-- Add the 'autostart' attribute and set its value to 'false' -->
    <script src="_framework/blazor.webassembly.js" autostart="false"></script>
    <!-- ⬇️⬇️⬇️ Add these lines ⬇️⬇️⬇️ -->
    <script>
        Blazor.start().then(function () {
            var customScript = document.createElement('script');
            customScript.setAttribute('src', 'js/main.js');
            document.head.appendChild(customScript);
        });
    </script>
    <!-- ⬆️⬆️⬆️ Add these lines ⬆️⬆️⬆️ -->
</body>

</html>

Build the app and register the extension again. There's another Content Security Policy-related error.

Add the hash value mentioned in error to manifest.json to fix this error.

{
  "manifest_version": 2,
  "version": "1.0",
  "name": "Getting Started Example (Blazor WASM)",
  "description": "Build an Extension!",

  ...

  "content_security_policy": "script-src 'self' 'unsafe-eval' 'wasm-unsafe-eval' 'sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=' 'sha256-DnTH4SKCYpHBGu1OxDOqoYLsvmZTiYIWJVQ1Ava7Kig=' 'sha256-b9roSuk6Pa7l0Hl/LWXGQlupw8fMc6ME2+82/N3qM0Q='; object-src 'self'",

  ...
}

What are those hash values?

sha256-DnTH4SKCYpHBGu1OxDOqoYLsvmZTiYIWJVQ1Ava7Kig=: It points to popup.js.
sha256-b9roSuk6Pa7l0Hl/LWXGQlupw8fMc6ME2+82/N3qM0Q=: It points to options.js.

Once added, register the extension again. Now it's working as expected!

Your existing JavaScript-based Chrome extension has now successfully been migrated to Blazor WebAssembly! If you want to see the complete example, go to this page.

So far, we've migrated the JavaScript-based Chrome extension app to Blazor WebAssembly with minimal code changes. Both extensions are almost identical, except for a couple of points. In other words, your extension can easily be migrated using the "lift & shift" approach. However, it doesn't entirely make use of the powerful JS interop feature yet. In the next post, let's explore how we can use the JS interop feature more for this migration.

Do you want to know more about Blazor?

Here are some tutorials for you.

Efficient OAuth Authorisation Management in Azure API Management

Justin Yoo — Wed, 08 Jun 2022 00:55:17 +0000

While developing an application, the majority of the time, you use API calls to send and receive messages. Therefore, you should follow an authentication and authorisation process to use the API unless it's the public API. Those authentication/authorisation process uses either 1) an auth key or 2) an access token through an OAuth process.

Using the auth key approach, you can store it in a safe place like the Azure Key Vault service and fetch the key. It's a relatively simple process. However, if you need to use the OAuth process, it gets complicated with the following authorisation process. Here's the conceptual OAuth process.

Request an authorisation code
Receive the authorisation code
Request an access token by providing the authorisation code
Receive the access token and a refresh token
Call API request by providing the access token
Receive the API response
Request a new access token by providing the refresh token once the existing access token expires
Receive the new access token and a new refresh token
Call API request by providing the new access token
Receive the API response

If you want to know more about the OAuth auth process, please refer to this doc.

Therefore, developers should implement those processes as a part of the application development. You might be lucky if the service you want to use offers an SDK. If not, you should do it all by yourself, which is very cumbersome. What if someone does all the tedious steps for you? Let's say, within the secure place, someone does all the auth process on your behalf and simply returns the access token. If this happens, your application development velocity will increase significantly. Azure API Management (APIM) has recently released a preview feature called "Authorisations" that does the OAuth process on your behalf. Throughout this post, I'm going to discuss this feature using a Blazor Web Assembly (WASM) app hosted on Azure Static Web Apps (SWA).

You can download the sample app code from this GitHub repository:

aaronpowell / token-store-demo

A sample of how to use token store from JavaScript and .NET

Token Store: Azure API Management Authorizations

Prerequisites

For Blazor app: .NET SDK 6.0.300 or later

For React app: node.js v14 or later

Getting Started

GitHub Secrets

Add the following GitHub Secrets to your repository:

AZURE_CREDENTIALS: Azure login credentials to get APIM and SWA details. To get this value, refer to this doc.

GH_PAT: GitHub personal access token to interact with GitHub resources. To get this value, refer to this doc.

Dropbox App

This sample uses the access token issued by Dropbox. You need to create an app for this demo.

Autopilot

This will work only if this repo goes public.

Click the button below to create and deploy both Blazor WASM app and React app in one go. Note the resource name for later use.

Once completing the resource provisioning above, run the GitHub Action workflow. Make sure to use the same resource name as…

View on GitHub

There are two apps in the repository – one based on Blazor WASM and the other based on React. I'm going to use the Blazor WASM sample here. If you're interested in the React app sample, please visit my colleague, Aaron Powell's blog post.

Blazor Web Assembly App

Please refer to the Blazor Tutorial document for the Blazor WASM in general. Instead, I'm going to take a look at a component taking care of the OAuth authorisation and access token. This component takes the user inputs, stores them as a .csv file format and uploads it to DropBox. The Razor code below is nothing special but contains a form for user inputs. When a user completes the form and clicks the "Submit" button, the OnFormSubmittedAsync event is triggered (line #3).

<div class="container-sm" style="max-width: 540px;">
  <h1>Blazor Lead Capture</h1>
  <form class="clearfix" @onsubmit="OnFormSubmittedAsync">
    <fieldset>
      <div>
        <label for="firstName" class="form-label">First name</label>
        <input type="text" class="form-control" id="firstName" name="firstName" placeholder="Justin" value="@userInfo.FirstName" @onchange="@(e => OnFieldChanged(e, "firstName"))" />
      </div>
      <div>
        <label for="lastName" class="form-label">Last name</label>
        <input type="text" class="form-control" id="lastName" name="lastName" placeholder="Yoo" value="@userInfo.LastName" @onchange="@(e => OnFieldChanged(e, "lastName"))" />
      </div>
    </fieldset>

    <fieldset>
      <div>
        <label htmlFor="email" class="form-label">Email</label>
        <input type="email" class="form-control" id="email" name="email" placeholder="bar@email.com" value="@userInfo.Email" @onchange="@(e => OnFieldChanged(e, "email"))" />
      </div>
      <div>
        <label htmlFor="phone" class="form-label">Phone</label>
        <input type="phone" class="form-control" id="phone" name="phone" placeholder="555-555-555" value="@userInfo.Phone" @onchange="@(e => OnFieldChanged(e, "phone"))" />
      </div>
    </fieldset>

    <fieldset>
      <button type="submit" class="btn btn-@componentUIInfo.ButtonColour" disabled="@(componentUIInfo.Submitting || string.IsNullOrWhiteSpace(userInfo.FirstName) || string.IsNullOrWhiteSpace(userInfo.LastName) || string.IsNullOrWhiteSpace(userInfo.Email) || string.IsNullOrWhiteSpace(userInfo.Phone))">
        <span>Submit</span>
        <span class="spinner-border spinner-border-sm" style="display:@componentUIInfo.DisplaySpinner;" role="status" aria-hidden="true"></span>
      </button>
    </fieldset>
  </form>

  <div class="alert alert-@componentUIInfo.AlertResult" style="display:@componentUIInfo.DisplayResult;">
    <h2>@componentUIInfo.MessageResult</h2>
    <button type="reset" class="btn btn-dark" @onclick="ResetFields">
      <span>Start Over?</span>
    </button>
  </div>
</div>

The following @code { ... } block is the C# code interacting with the Razor component. For brevity, I've left two methods. The first method is the event handler, OnFormSubmittedAsync triggered by the "Submit" button. Then, inside the event handler, it calls the SaveToDropboxAsync method, which takes care of all the things, including access token fetch and DropBox save.

@code {
    ...
    protected async Task OnFormSubmittedAsync(EventArgs e)
    {
        ...
        await SaveToDropboxAsync().ConfigureAwait(false);
    }

In the SaveToDropboxAsync method, it firstly gets the environment variable of APIM_Endpoint (line #4). Blazor WASM stores all the environment variables in the appsettings.json file, which I will discuss later. By calling the APIM endpoint from appsettings.json, the app gets the access token to DropBox (line #7), and the DropBox client instance uploads the data.

    private async Task SaveToDropboxAsync()
    {
        // Gets the APIM endpoint from appsettings.json
        var requestUrl = Configuration.GetValue<string>("APIM_Endpoint");

        // Gets the auth token from APIM
        var token = await Http.GetStringAsync(requestUrl).ConfigureAwait(false);

        // Builds contents.
        var path = $"/submissions/{DateTimeOffset.UtcNow.ToString("yyyyMMddHHmmss")}.csv";
        var contents = $"{userInfo.FirstName},{userInfo.LastName},{userInfo.Email},{userInfo.Phone}";
        var bytes = UTF8Encoding.UTF8.GetBytes(contents);

        // Uploads the contents.
        var result = default(FileMetadata);
        using(var dropbox = new DropboxClient(token))
        using(var stream = new MemoryStream(bytes))
        {
            result = await dropbox.Files.UploadAsync(path, WriteMode.Overwrite.Instance, body: stream).ConfigureAwait(false);
        }

        ...
    }
}

Let's take a look at the appsettings.json file that contains the APIM_Endpoint environment variable. The value is the APIM endpoint to get the DropBox access token.

{
  "APIM_Endpoint": "https://<APIM_NAME>.azure-api.net/dropbox-demo/token?subscription-key=<APIM_SUBSCRIPTION_KEY>"
}

Run the Blazor WASM app on your local machine.

dotnet watch run

Then, open your web browser and enter the URL of https://localhost:5001, and you will see the page like:

Fill out the form and click the "Submit" button, and the app will save the form details to DropBox. Then, if you open the Developer Tools of your web browser, you can see how the Blazor WASM app calls the APIM endpoint.

And the API call returns the access token to DropBox.

With this access token, you can create and store a file. Here's the result:

There are no codes for OAuth authorisation to DropBox, as you can recall. Instead, it starts from the API call that directly gets the access token. So how can the code remove all the preflight codes before getting the access token? This is the new APIM authorisation feature being referred to in this post. In short, the APIM instance internally performs all the OAuth related processes on behalf of the Blazor WASM app and simply returns the access token.

Azure API Management Instance

Let's dig into the new APIM feature. You can click the button below to provision all the resources onto Azure at once.

Alternatively, you can run the bicep files declared below. Let's take a further look at the bicep files. First, declare the APIM instance. You might notice that it enables the Managed Identity feature (line #13-15), which I'll discuss later in this post. For convenience, name the APIM instance of token-store-demo-apim and set the location to West Central US. The resource group for this provision is set to rg-token-store-demo.

// APIM instance
resource apim 'Microsoft.ApiManagement/service@2021-08-01' = {
  name: 'token-store-demo-apim'
  location: 'westcentralus'
  sku: {
    name: 'Developer'
    capacity: 1
  }
  properties: {
    publisherName: 'John Doe'
    publisherEmail: 'john.doe@nomail.com'
  }
  identity: {
    type: 'SystemAssigned'
  }
}

The next step is the CORS policy because Azure SWA directly calls the APIM endpoint. Within the inbound node, add the cors node, add the allowed-origins node under it, and add the origin node with its value of *. Make sure that it's just for the demo purpose. You should add the specific URL for better security if it goes live.

// Service Policy
resource apim_policy 'Microsoft.ApiManagement/service/policies@2021-08-01' = {
  parent: apim
  name: 'policy'
  properties: {
    value: service_policy
    format: 'xml'
  }
}

// Service Policy Definition
var service_policy = '''
<policies>
    <inbound>
        <cors allow-credentials="false">
            <allowed-origins>
                <origin>*</origin>
            </allowed-origins>
            <allowed-methods>
                <method>GET</method>
                <method>POST</method>
            </allowed-methods>
        </cors>
    </inbound>
    <backend>
        <forward-request />
    </backend>
    <outbound />
    <on-error />
</policies>'''

After declaring the APIM instance, define an API and its operation. The API's serviceUrl is set to the base URL of the DropBox API, and the operation endpoint is set to /token that returns the access token. Therefore, the entire APIM endpoint might look like https://token-store-demo-apim.azure-api.net/dropbox-demo/token.

// API
resource api 'Microsoft.ApiManagement/service/apis@2021-08-01' = {
  name: 'dropbox-demo'
  parent: apim
  properties: {
    serviceUrl:'https://api.dropboxapi.com'
    path: 'dropbox-demo'
    displayName:'dropbox-demo'
    protocols:[
      'https'
    ]
  }
}

// Operation
resource api_gettoken 'Microsoft.ApiManagement/service/apis/operations@2021-08-01' = {
  name: 'gettoken'
  parent: api
  properties: {
    method: 'GET'
    urlTemplate: '/token'
    displayName: 'gettoken'
  }
}

However, this endpoint doesn't exist on DropBox API. Therefore, add the operation policy to make this operation work.

// Operation Policy
resource api_gettoken_policy 'Microsoft.ApiManagement/service/apis/operations/policies@2021-08-01' = {
  parent: api_gettoken
  name: 'policy'
  properties: {
    value: operation_token_policy
    format: 'xml'
  }
}

The following XML document of the operation policy explains the core idea of this APIM's new feature. Add the get-authorization-context node under inbound. It has the following attributes.

provider-id: dropbox-demo
authorization-id: auth
context-variable-name: auth-context
identity-type: managed

As you can see, the APIM instance has enabled the Managed Identity feature corresponding to identity-type. Both provider-id and authorisation-id will be used later. The context-variable-name attribute is set to auth-context. It's used in the return-response node that holds the access token value. Overall, this operation policy takes care of getting access token on behalf of the SWA app.

// Operation Token Policy Definition
var operation_token_policy = '''
<policies>
    <inbound>
        <base />
        <get-authorization-context provider-id="dropbox-demo" authorization-id="auth" context-variable-name="auth-context" ignore-error="false" identity-type="managed" />
        <return-response>
            <set-body>@(((Authorization)context.Variables.GetValueOrDefault(&quot;auth-context&quot;))?.AccessToken)</set-body>
        </return-response>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>'''

You've got the APIM instance defined. Now, you need the SWA app instance for the Blazor WASM app.

Azure Static Web Apps Instance

To host the Blazor WASM app, you need to provision an Azure SWA instance. Here's the bicep code for it. First, give the app name token-store-demo-blazor-swa and the location of Central US under the resource group of rg-token-store-demo.

// SWA instance
resource sttapp 'Microsoft.Web/staticSites@2021-02-01' = {
  name: 'token-store-demo-blazor-swa'
  location: 'centralus'
  sku: {
    name: 'Free'
  }
  properties: {
    allowConfigFileUpdates: true
    stagingEnvironmentPolicy: 'Enabled'
  }
}

Blazor WASM App Deployment to Azure Static Web Apps Instance

You've got the new ASWA instance. It's time to deploy the Blazor WASM app, which is located in the src/frontend/blazor directory. The first step should be adding the appsettings.json file that contains the APIM endpoint for the access token. The following commands are how to get the APIM's endpoint URL.

# Get APIM gateway URL
rg_name=rg-token-store-demo
apim_name=token-store-demo-apim

gateway_url=$(az apim show -g $rg_name -n $apim_name --query "gatewayUrl" -o tsv)

# Get APIM subscription key
subscription_id=$(az account show --query "id" -o tsv)
apim_secret_uri=/subscriptions/$subscription_id/resourceGroups/$rg_name/providers/Microsoft.ApiManagement/service/$apim_name/subscriptions/master/listSecrets
api_version=2021-08-01

subscription_key=$(az rest --method post --uri $apim_secret_uri\?api-version=$api_version | jq '.primaryKey' -r)

# Build APIM endpoint
apim_endpoint=$gateway_url/dropbox-demo/token\?subscription-key=$subscription_key

The APIM's endpoint URL is finally landed in the apim_endpoint variable. Therefore, rename the appsettings.sample.json file under the src/frontend/blazor/wwwroot directory to appsettings.json and update the endpoint.

{
  "APIM_Endpoint": "<apim_endpoint>"
}

Build and create the artifact of the Blazor WASM app.

dotnet restore ./src/frontend/blazor
dotnet build ./src/frontend/blazor
dotnet publish ./src/frontend/blazor -c Release -o ./src/frontend/blazor/bin

There's one more step for deployment. Get the deployment key by running the command below:

swa_key=$(az staticwebapp secrets list \
    -g rg-token-store-demo \
    -n token-store-demo-blazor-swa \
    --query "properties.apiKey" -o tsv)

Finally, deploy the Blazor WASM app by running the command.

swa deploy -a ./src/frontend/blazor/bin/wwwroot -d $swa_key --env default

Although everything has gone perfectly so far, you can see the error below after submitting the form:

It's because you haven't made consent to the DropBox app yet. The final step will be consent.

DropBox App Consent

Create a DropBox app by following this document, and you will get both App key and App secret.

You need both values for the consent within the APIM instance. Click the "Authorisations (preview)" at the blade.

There are no authorisation apps yet. Therefore, click the "Create" button.

You can recall how you set up the get-authorisation-context node for the operation policy. It's time to use them.

Enter dropbox-demo to the "Provider name" field.
Select DropBox from the "Identity provider" field.
Enter DropBox's app key value to the "Client id" field.
Enter DropBox's app secreet value to the "Client secret" field.
Enter files.metadata.write files.content.write files.content.read to the "Scopes" field.
Enther auth to the "Authorization name" field.

Click the "Create" button and get the redirection URL.

Add the redirection URL to the DropBox app.

Back to the APIM instance and log in to the DropBox app. Then, proceed the pop-up window by clicking the "Continue" and "Allow" and "Allow access" buttons consecutively.

Then, you will see the success message.

The DropBox app has now been authorised. But the APIM instance has not yet been authorised to access the DropBox app. Since the APIM instance has the Managed Identity feature enabled, let's use it. Choose "Managed identity" and click the "Add members" button.

Find the APIM instance and add it.

Now, both APIM and DropBox can communicate with each other.

Can you see the DropBox app authorised?

Let's test the endpoint whether it actually works or not. Follow the menu "APIs" ➡️ "dropbox-demo" ➡️ "gettoken" and click the "Send" button.

Then you will see the access token successfully issued.

Let's get back to the ASWA app and fill out the form. There is no error this time.

And the uploaded file appears on DropBox!

So far, we've discussed the new OAuth authorisation feature of Azure API Management. Ultimately, we need the access token through the OAuth process. APIM performs this process. Therefore, we can save a huge amount of time by not implementing this feature within our app. Since it's currently in preview, some features may be ready, but they will be continuously improved.

If you want to know more about this APIM OAuth authorisation management feature, please visit the document below:

Azure API Management Authorisations Management

Blazor WebAssembly for Headless CMS on Azure Static Web Apps

Justin Yoo — Fri, 13 May 2022 00:00:33 +0000

One of the most popular scenarios to build a static website is to run a blog site for myself or my organisation. WordPress is the most popular service for this purpose. Now, you want to migrate your WordPress blog site to a static website, but it doesn't look easy.

What if you still want to use the WordPress site to write content but only want to refresh the UI outside the site? What if you can even use C# for it through Blazor WebAssembly? You are now able to use the existing WordPress site as the data source of truth and build a UI in a separate instance with your preferred method. Does that sound attractive?

Throughout this post, I'm going to discuss how to use the serviced WordPress instance as the headless CMS, build the Blazor WebAssembly app to make use of the WordPress as a data source, and host it to Azure Static Web Apps.

You can download the sample app code from this GitHub repository:

justinyoo / blazor-wasm-azfunc-aswa

Blazor WASM with Azure Functions on ASWA for headless CMS

Headless CMS Example with Blazor WebAssembly on Azure Static Web Apps

This provides a sample headless CMS app using Blazor WebAssembly hosted on Azure Static Web Apps.

Prerequisites

.NET 6

Visual Studio 2022 or Visual Studio Code

View on GitHub

Serviced WordPress Site Instance

I've got a serviced WordPress site that is no longer maintained but archived.

In order to use this site as a data source, I need to be able to access to the contents through APIs. Fortunately, WordPress provides full of HTTP API endpoints. Enter the following command in your terminal.

curl -X GET https://public-api.wordpress.com/rest/v1.1/sites/<site-name>.wordpress.com/posts/

Alternatively, you can use your preferred UI tool like Postman to get the list of contents:

You get the contents. All you need to do now is to render the contents on the Blazore WASM app. There are two approaches to it:

Directly call the API from the Blazor WASM app, or
Call the API from the Blazor WASM app through the proxy API app

Both approaches have pros and cons, but let's make it with the second approach.

Proxy API Application

We don't need the proxy API app for Azure Static Web Apps. However, if you need to overcome the CORS issue, handle various APIs, or deal with some security concerns, using the proxy API is a good option. Because Azure Static Web Apps natively supports this proxy API feature, we can simply use it. First of all create an HTTP trigger of Azure Functions app.

Define GetPosts for the WordPress API endpoint and create an HttpClient instance.

public static class PostHttpTrigger
{
    private const string GetPosts = "https://public-api.wordpress.com/rest/v1.1/sites/{0}/posts";
    private static HttpClient http = new HttpClient();

If you add the OpenAPI extension to your function app, your Blazor WASM app can easily access this proxy API. I'll handle this part later in this post.

    [FunctionName("PostHttpTrigger")]
    [OpenApiOperation(operationId: "posts.get", tags: new[] { "posts" })]
    [OpenApiResponseWithBody(statusCode: HttpStatusCode.OK, contentType: "application/json", bodyType: typeof(PostCollection), Description = "The OK response")]
    public static async Task<IActionResult> GetPostsAsync(
        [HttpTrigger(AuthorizationLevel.Anonymous, "GET", Route = "posts")] HttpRequest req,
        ILogger log)
    {

Get the actual WordPress site name from the environment variables.

        var requestUri = new Uri(string.Format(GetPosts, Environment.GetEnvironmentVariable("SITE__NAME")));

Finally, call the WordPress API and deserialise the result to the PostCollection object.

        var json = await http.GetStringAsync(requestUri).ConfigureAwait(false);
        var posts = JsonConvert.DeserializeObject<PostCollection>(json);

        return new OkObjectResult(posts);
    }
}

Here are the definitions of the PostCollection class and its subclasses. Although the WordPress API returns a massive variety of results, we only need some of them defined in the PostCollection class.

public class PostCollection
{
    public virtual int Found { get; set; }

    public virtual List<PostItem> Posts { get; set; }

    [JsonProperty("meta")]
    public virtual Metadata Metadata { get; set; }
}

public class PostItem
{
    [JsonProperty("ID")]
    public virtual int PostId { get; set; }

    public virtual Author Author { get; set; }

    [JsonProperty("date")]
    public virtual DateTimeOffset DatePublished { get; set; }

    public virtual string Title { get; set; }

    [JsonProperty("URL")]
    public virtual string Url { get; set; }

    public virtual string Excerpt { get; set; }

    public virtual string Content { get; set; }
}

public class Author
{
    [JsonProperty("ID")]
    public virtual int AuthorId { get; set; }

    [JsonProperty("first_name")]
    public virtual string FirstName { get; set; }

    [JsonProperty("last_name")]
    public virtual string Surname { get; set; }

    public virtual string Name { get; set; }
}

public class Metadata
{
    public virtual Dictionary<string, string> Links { get; set; }

    [JsonProperty("next_page")]
    public virtual string NextPage { get; set; }

    [JsonProperty("wpcom")]
    public virtual bool IsWordpressCom { get; set; }
}

Finally, configure the local.settings.json file. We set it to this file as we previously referred to the environment variable of SITE__NAME. In addition to that, we set the CORS for the Blazor WebAssembly app integration.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",

    "SITE__NAME": "<site-name>.wordpress.com"
  },
  "Host": {
    "CORS": "*"
  }
}

All set! Run the proxy API app, and you will see the result like below:

The OpenAPI document URL to this proxy API app is one of the following:

http://localhost:7071/api/swagger.json – OpenAPI V2
http://localhost:7071/api/openapi/v2.json – OpenAPI V2
http://localhost:7071/api/openapi/v3.json – OpenAPI V3

Blazor WebAssembly Application

Open Visual Studio and create a new Blazor WebAssembly project.

Give it the name of WebApp, and leave the rest as default. Once the app is created, run the app by typing the F5 key, and you will see the screen like this:

It's time to connect to the proxy API to this Blazor app. First, make sure that the proxy API app is running background. Then, click the "Connected Services" menu.

Then click the "➕" button.

Choose the "OpenAPI" option as a service reference.

Enter the OpenAPI URL, give the namespace of WebApp.Proxies and class name of ProxyClient, and click the "Finish" button.

You'll see the proxy API is added to the Blazor app.

Click the three dots on the right-hand side and select the "View generated code" menu. Can you see the auto-generated code from the OpenAPI document?

We just need to consume this code. First, open the Program.cs file and add the dependency of the ProxyClient instance.

While developing this app on your local machine, the default base URL is http://localhost:7071/api. But once it's deployed to Azure, it must follow the actual host address (line #8-12).

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });

// Add these lines to inject the dependency of ProxyClient
builder.Services.AddScoped(sp =>
{
    var client = sp.GetService<HttpClient>();
    var api = new ProxyClient(client);
    if (!builder.HostEnvironment.IsDevelopment())
    {
        var baseUrl = $"{builder.HostEnvironment.BaseAddress.TrimEnd('/')}/api";
        api.BaseUrl = baseUrl;
    }

    return api;
});

By this far, your Blazor app is now freely accessible to the proxy API. So, let's implement this part. First, we simply modify the index.razor page and render the list of blog posts in this post.

Inject the dependency of ProxyClient added through Program.cs.

@page "/"

@* Inject ProxyClient dependency *@
@using WebApp.Proxies
@inject ProxyClient Api

Add the HTML bits and pieces just below the <SurveyPrompt> component that handles the list of blog posts.

...
<SurveyPrompt Title="How is Blazor working for you?" />

@if (posts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th>Author</th>
                <th>Title</th>
                <th>Excerpt</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var post in posts)
            {
                <tr>
                    <td>@post.Date.ToString()</td>
                    <td>@post.Author.Name</td>
                    <td><a href="@post.URL">@post.Title</a></td>
                    <td>@((MarkupString)post.Excerpt)</td>
                </tr>
            }
        </tbody>
    </table>
}

Here's the actual code to call the proxy API. Through this proxy API, this page receives the list of blog posts.

@code {
    private List<PostItem> posts;

    protected override async Task OnInitializedAsync()
    {
        var collection = await Api.Posts_getAsync().ConfigureAwait(false);
        posts = collection?.Posts.ToList();
    }
}

It's done! Run the Blazor app again. You can see the list of blog posts populated from Wordpress.

You need to push all the code to the GitHub repository.

Azure Static Web Apps Hosting

All coding parts have been completed! Now it's time to publish the app to Azure Static Web Apps. I'm not going to walk through this part. Instead, here are links to my previous posts about the deployment.

Deploying Static Web Apps

Once you complete publishing your Blazor WebAssembly app with the proxy API app, go to the website to confirm whether everything is OK or not.

So far, I've walked through how to build a Blazor WebAssembly app with an Azure Functions proxy API and use serviced WordPress site as a data source. Also, I've published this app to Azure Static Web Apps instance. Although this post has only implemented the high-level concepts, it has basically touched almost everything you need. Therefore, it's up to you to use as many API endpoints as possible and make the UI prettier. Then, you can still use the existing WordPress site as your data source of truth.

Azure Apps Autopilot #2 - Deployment Script

Justin Yoo — Thu, 07 Apr 2022 13:13:14 +0000

In my previous post, we built the autopilot feature, using various event triggers from GitHub Actions and Azure Bicep. Throughout this post, I'm going to build the revised autopilot feature using Azure Bicep Deployment Scripts resource without GitHub Actions.

You can download the sample code from this GitHub repository below.

devkimchi / APIM-OpenAPI-Sample

This provides sample Azure Functions apps that integrate with Azure API Management, and expose Swagger UI through it.

APIM OpenAPI Integration Sample

This provides sample Azure Functions apps that integrate with Azure API Management, and expose their respective Swagger UI pages through it.

Getting Started

Click the button below to autopilot all instances and apps on Azure. Make sure that you don't forget the app name you give.

Visit the following URLs to check whether all the apps have been properly provisioned and deployed.

https://apim-<APP_NAME>.azure-api.net/azip/swagger/ui

~~https://apim-<APP_NAME>.azure-api.net/azoop/swagger/ui~~

Known Issues

Due to the fact that Azure CLI has an error to deploy .NET-based out-of-proc function app, the autopilot feature only takes care of the in-proc function app. However, manual deployment of both in-proc and out-of-proc function apps is fine.

View on GitHub

Solution Architecture

Let's say you're building a microservices architecture. It typically consists of an API gateway and many API apps, which are Azure API Management (APIM) and Azure Functions API in this example. The microservices architecture might be more complex depending on the requirements, but it's way too far from our topic. Therefore, let's build a minimal structure that is working. Here's the diagram.

Azure Resources Provisioning

There are five resources to provision:

As you can see, each resource has its corresponding Bicep module. For example, it's required to provision Azure Storage, Application Insights and App Service Plan (Consumption) before creating an Azure Functions app. Therefore, the provision_functionapp.bicep file takes care of this orchestration. In addition to that, Azure API Management also needs Application Insights as a dependency, so the provision_apimamagement.bicep file looks after this orchestration.

After deploying the function app, the provision_apimanagementapi.bicep registers the function app to APIM.

NOTE: I used the modularisation approach while writing the Bicep files. But it may differ from your situation, and writing one big Bicep file could be more efficient in some circumstances.

Once you complete writing the Bicep file, you might expect the following processes in that order.

Provision the function related resources 👉 provision_functionapp.bicep
Provision the APIM related resources 👉 provision_apimamagement.bicep
➡️ Deploy the function app ⬅️
Integrate the function app with APIM 👉 provision_apimanagementapi.bicep

When #1 and #2 are over, you can see the following resources provisioned.

By the way, #4 can't be provisioned until the function app is deployed at #3. Moreover, #3 is not related to resource provisioning but app deployment. What if we can convert this app deployment experience into resource provisioning? Then, all processes from #1 to #4 can be done within the resource provisioning pipeline, which means the whole "autopilot" feature is set.

Azure Bicep – Deployment Scripts

Azure Resource Manager (ARM) has introduced the concept of deployment script. Through this deployment script, ARM can include PowerShell scripts or bash scripts as a part of the resource provisioning pipeline. In other words, the deployment script resource can run Azure PowerShell or Azure CLI. How is that possible? Here's the Bicep file declaring the deployment script.

resource ds 'Microsoft.Resources/deploymentScripts@2020-10-01' = {
    name: 'my-deployment-script'
    location: resourceGroup().location
    kind: 'AzureCLI'
    identity: {
        type: 'UserAssigned'
        userAssignedIdentities: {
            '<user-assigned-identity-id>': {}
        }
    }
    properties: {
        azCliVersion: '2.33.1'
        containerSettings: {
            containerGroupName: 'my-container-group'
        }
        environmentVariables: [
            {
                name: 'RESOURCE_NAME'
                value: '<resource-name>'
            }
        ]
        primaryScriptUri: '<bash-script-url>'
        retentionInterval: 'P1D'
    }
}

The kind attribute explicitly declares that it uses Azure CLI. You can declare "AzurePowerShell" if you like.
The bash script needs the login credentials to run Azure CLI commands. Therefore, it uses the user-assigned identity.
The bash script uses the Azure CLI of v2.33.1 in this example. It's recommended to use a specific version instead of the latest version, discussed later.
The bash script uses the environment variable of RESOURCE_NAME, which is declared and has the value assigned in the Bicep file.
The primaryScriptUri attribute declares the publicly accessible bash script URL.

NOTE: The Bicep file only shows the necessary bits and pieces. If you want to know more details, please take a look at this Bicep file.

So, what does this deployment script resource do? It temporarily provisions both Azure Container Instance and Storage Account to handle the script. According to this document, using the Azure CLI version older than 30 days from the day running the script is recommended. Therefore, at the time of this writing, v2.33.1 is the closest one. Of course, you can use the az upgrade command within the script to get the latest version, but it's totally up to you.

Deployment Script – Bash Script

Take a look at the bash script that runs the series of Azure CLI commands. Let's say the artifact name is api.zip, and the following script gets the artifact URL stored in the GitHub repository at the beginning.

# Get artifacts from GitHub
urls=$(curl -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/devkimchi/APIM-OpenAPI-Sample/releases/latest | \
  jq '.assets[] | { name: .name, url: .browser_download_url }')

apizip=$(echo $urls | jq 'select(.name == "api.zip") | .url' -r)

As the artifact URL is set as the environment variable, $apizip, Azure CLI uses this artifact URL to deploy the function app. The environment variable, $RESOURCE_NAME, comes from the deployment script Bicep file.

# Deploy function apps
ipapp=$(az functionapp deploy \
  -g rg-$RESOURCE_NAME \
  -n fncapp-$RESOURCE_NAME-api \
  --src-url $apizip \
  --type zip)

Once we complete deployment, it should be registered to APIM through the OpenAPI document. How can we do that? Another Bicep file, provision-apimanagementapi.bicep, can also be run within the bash script through Azure CLI. But make sure that, if you want to provision resources through URL, you MUST convert the Bicep file to an ARM template of the JSON type.

# Provision APIs to APIM
az deployment group create \
  -n ApiManagement_Api \
  -g rg-$RESOURCE_NAME \
  # MUST be ARM template, not Bicep
  -u https://raw.githubusercontent.com/devkimchi/APIM-OpenAPI-Sample/main/Resources/provision-apimanagementapi.json \
  -p name=$RESOURCE_NAME

Now, we've got the bash script to run within the deployment script resource.

Overall Resource Orchestration

As the final step, everything written above should be composed into one. Here's the main.bicep file that orchestrates resources and deployment scripts. The deployment script resource should always come last after all other resources are provisioned by using the dependsOn attribute.

// Provision API Management
module apim './provision-apimanagement.bicep' = {
    name: 'ApiManagement'
    params: {
        ...
    }
}

// Provision function app
module fncapp './provision-functionapp.bicep' = {
    name: 'FunctionApp'
    dependsOn: [
        apim
    ]
    params: {
        ...
    }
}]

// Provision deployment script
module uai './deploymentScript.bicep' = {
    name: 'UserAssignedIdentity'
    dependsOn: [
        apim
        fncapp
    ]
    params: {
        ...
    }
}

Once everything is done, convert the last Bicep file into the ARM template and link it to the image button below. Then, just click the button and put in the necessary information. It will automatically provision resources, deploy apps and do the rest of the provisioning process within one single pipeline, and the app is ready to use.

If you actually click the button above, you will be able to see the Azure Portal screen like below:

Did you complete all the steps? Then go to APIM and visit one of the function app's Swagger UI endpoint.

So far, we've walked through the Azure Bicep's deployment script resources and revised the autopilot feature without needing to rely on GitHub Actions, as mentioned in the previous post. Now, you can hand over your repository to your tech-sales representatives to demo for their clients or other dev units to take a look with no prior knowledge of your application set-up. How easy is that?

Forem: Justin Yoo

One Command Deploying .NET Apps to Azure Container Apps: azd up

devkimchi / azdevfying-dotnet-apps-on-aca

This provides sample .NET apps to be deployed onto Azure Container Apps through azd CLI

azdevfying .NET apps on Azure Container Apps

Prerequisites

Architecture

Getting Started

Prerequisites

Running the app locally

azd init – Initialisation

azd up – Provision and deployment

Update Bicep files – Service discovery

More about deploying .NET apps to ACA?

You don't need Dockerfile to containerise Azure Functions

devkimchi / msbuild-for-functions-on-containers

This provides sample .NET function apps using container images with Dockerfile and with MSBuild on Docker Desktop.

MSBuild for Azure Functions on Containers

Prerequisites

Getting Started

Run with Dockerfile

Prerequisites

Containerise with Dockerfile

Containerise with dotnet publish

More about MSBuild for Containers?

Different Containerising Options for .NET Developers

devkimchi / msbuild-for-containers

This provides sample .NET apps using container images with Dockerfile, with MSBuild, and with .NET Aspire support on Docker Desktop.

MSBuild for Containers

Prerequisites

Getting Started

Run with Dockerfile

Prerequisites

Containerise with Dockerfile

Containerise with dotnet publish

Container orchestration with docker compose

Container orchestration with .NET Aspire and Aspirate

More about MSBuild for Containers?

DevContainers for Azure and .NET

devkimchi / devcontainers-dotnet

This is the template repository that contains the devcontainer settings for .NET app development

devcontainers for .NET

Getting Started

Options – devcontainer.json

Base Image

Elements of DevContainer

Structure of devcontainer.json

Order of Building DevContainer

Base Container Image

devcontainer.json Configuration

The build Section

The forwardPorts Section

The features Section

The customizations.vscode.extensions Section

The customizations.vscode.settings Section

The postCreateCommand Section

post-create.sh Execution

CaskaydiaCove Nerd Font

Azure CLI Extensions

Azure Bicep CLI

Azure Functions Core Tools

Azure Static Web Apps CLI

Azure Dev CLI

oh-my-zsh – Plugins and Themes

oh-my-zsh – powerlevel10k Theme Configurations

oh-my-posh – Installation

oh-my-posh – Configurations

Want to know more about DevContainers?

Blazor WASM Custom 404 Page on GH Pages

fitability / fitability.github.io

fitability™️ – your friendly fitness activity tracking app

fitability™️ – your friendly fitness activity tracking app

Repositories

Credits

Blazor WASM – Default 404 Page

Blazor WASM – Custom 404 Page

GitHub Pages – Default 404 Page

GitHub Pgaes – Custom 404 Page

Want to know more about Blazor?

Azure AD B2C on Blazor WASM Standalone

`azd init` – Initialisation

`azd up` – Provision and deployment

Run with `Dockerfile`

Containerise with `Dockerfile`

Containerise with `dotnet publish`

Run with `Dockerfile`

Containerise with `Dockerfile`

Containerise with `dotnet publish`

Container orchestration with `docker compose`

Options – `devcontainer.json`

Structure of `devcontainer.json`

`devcontainer.json` Configuration

The `build` Section

The `forwardPorts` Section

The `features` Section

The `customizations.vscode.extensions` Section

The `customizations.vscode.settings` Section

The `postCreateCommand` Section

`post-create.sh` Execution

`manifest.json` Accommodation

`background.js` Update

`popup.js` Update

`options.js` Update

`Run-PostBuild.ps1` Adjustment