Migrating a static web site using custom HTTP modules to Azure App Service

Premier Developer

Premier

App Dev Manager Steve Keeler migrates a static web site using custom HTTP modules to an Azure App Service.


I was asked recently about migrating a local Internet Information Server (IIS) static web application to an Azure App Service. For this type of question, resources like the App Service Migration tool are usually a good place to start. In this case the App Service Migration tool reported issues based on the presence of location tags related to a custom HTTP module used by the web application.

Here is the web.config file for the local web application running on IIS that caused the “location tag” issue for the migration tool:

Fortunately, it is relatively straightforward to move this type of content into an Azure App Service. The source code for the this simple static web site and custom HTTP module is available in this GitHub repository.

To make it a little more interesting, we’ll setup build and release pipelines in an Azure DevOps project to automatically deploy committed source changes to an Azure App Service. If you’d like to replicate these steps in your own environment, you can follow along and start by Creating a project in Azure DevOps if you don’t already have one. Once you have an Azure DevOps project, use the Import a Git repo documentation to import the sample GitHub repository mentioned above into your Azure DevOps project repository.

The sample repository code is a very basic static web application. It primarily consists of a single main page, index.html and a CSS file site.css. The HTML for the main page is simply:

Another element in the repository is a custom HTTP module named DemoHttpModule. The key parts of the implementation for this module is:

The sample custom HTTP module prepends and appends HTML to every static web page request. The compiled assembly for DemoHttpModule is output into the \bin folder of the root directory for proper placement when the web application is deployed to the Azure App Service.

The final piece required is an XDT transformation to dynamically generate the configuration bindings for the DemoHttpModule in the Azure App Service. The XDT transformation is located in the applicationHost.xdt source file and has the following contents:

With the source code in place, we are ready to create build and release pipeline definitions to package and deploy the web application automatically. For more information on Azure DevOps pipelines, refer to the article Getting started with Azure Pipelines.

Two tasks are used for the build pipeline: Archive Files and Publish Build Artifacts. The YAML fragment for the build job tasks is:

In the designer, the build definition appears visually as follows:

Build pipeline

Build pipeline

The release pipeline consumes the artifact published by the build pipeline and is configured to trigger whenever a new build artifact becomes available. It is represented visually as follows:

Release pipeline

Release pipeline

One task is used for the release pipeline: Azure App Service Deploy. The YAML fragment for the release job task is:

In the designer, the release definition task appears visually as follows:

Release pipeline tasks

Release pipeline tasks

Once you have created your build (CI) and release (CD) pipelines, deploying the static web application with custom HTTP module is as easy as committing a change in the code repository.

After the build and release pipelines complete, loading the web application in a browser displays our test page:

web application

web application

The Beginning of Request banner at the top of the page and End of Request banner at the bottom of the page are injected into the page by the DemoHttpModule custom HTTP module.

Premier Developer
Premier Developer

Premier Support for Developers

Follow Premier   

No Comments.