Migrating To .Net6 and Azure

Sep 02, 2022
by:   Tim Stanley

In 2022, I decided to make a significant update the the code base and hosting platform used by this site. I decided to migrate to .Net 6 and host it on Azure.

I could have taken the old site to Azure, but I wanted to start with a cleaner code base. I removed some of the old dependencies, libraries and assumptions to lighten up as much as possible. A general list of the new requirements:

  • Store content as XML or JSON.
  • Do not require the use of a database.
  • Provide support for as much of the original content as possible.
  • Remove dependencies on third party packages as possible.

The main course of effort was the original site was written in ASP.Net Web forms. The new site was written in ASP.Net Core Razor pages in C#.

Some interesting points:

  • Start: 2022 06 10
  • End: 2022 07 31
  • 32 days of working changes, a few hours on nights & weekends
  • Occurred over 50 calendar days
  • The equivalnet of about 15-20 full time equivalent working days
  • 15,552 Lines of Source Code
  • 4,438 Lines of Executable Code
  • Go Live: 2022 08 28

Here is a summary of some of the key points of the new site:

  • Developed using Visual Studio 2022
  • Targets .Net 6
  • ASP.Net Core Razor Pages
  • Content / object model is all XML based
  • Supports pages, posts, tags, categories, authors, and site statistics
  • Uses Azure DNS
  • Uses Azure App Services / an Azure Website for hosting the site
  • Uses GitHub Azure integrations to publish software updates to Azure
  • Uses prism.js for code formatting
  • Uses tinymce for content editing
  • Uses bootstrap for a CSS styling.
  • Some moving parts were greatly influenced by Miniblog.Core. This site is not a derivative of Miniblog.Core, but I did use some of the ideas as a base for this sites code base.
  • The Table Of Content generator leverages the HtmlAgilityPack

A few things about Azure I learned along the way.

Pick carefully what Azure Datacenter you want for hosting. Not all Azure Datacenters have the same features, or the same pricing and you cannot easiliy mix parts from other Azure Datacenters. For example, once your publishing a site from Github to Azure, moving that Azure Website to another Azure DataCenter basically requires configuring everything back from scratch.

Using an Azure Static Website is really for a "static" site. A dynamic site that runs ASP.Net Core isn't suited for a Azure Static Website.

Using GitHub actions to publish to Azure is a timesaver. However, each action stores the result as storage, and if your not careful, very quickly you will exceed the 500 MB storage limit for "free" GitHub repositories.

Azure App Services provide several layers of scalability for the Azure Hosting Plans.

Using Azure App Services / Azure Websites for a Developer Lab Instance provides a free hosting service (F1), an SSL certificate, and is extremely helpful for go live preparation. The D1 service plan provides the bare bones minimum to host a non azure domain name.

You can't get an SSL certificate (even if you buy one) on a custom domain name on the F1 or D1 service plan. Microsoft tells you that a B1 service plan or higher is needed.

The D1 service plan provides:

  • 1 GB of memory
  • 240 minutes / day compute

The D1 service plan is more than enough power to drive this website. It uses about 250-350 Mb of memory (everything is store in memory since there is no database). Because everything is stored in memory it barely uses any compute time.

The positives of moving to Azure App Services:

  • Github Actions to publish to Azure is a great timesaver.
  • Azure DNS is much easier to administer than other DNS services I've used.
  • The minimum D1 plan is still screamingly fast.
  • The Azure monitoring provides some usefull analysis tools.

The only negative I've experienced so far with Azure is that it tries to steer the creation to a default S1 plan. If you accidentally setup an S1 plan, and remove it from you site, you still pay for the plan until you remove it from the subscription. If you don't pay attention, you can quickly run up a hefty bill. Few people really need an S1 hosting plan to start a small website.

Related Items