How to publish and auto-deploy your .NET Web Application

Intro

As my specialty is not DevOps, I usually have to exclaim "Ugh! Now have to publish it! Again!" after finishing a project in my portfolio. Even now when I have gathered them all in one (if you are interested: xuanphuoc92/PeterDoStuff: Peter's collection portfolio in free time), there will be time I may have to go through the setup and publish again.

So, this post is also for me to go back and "Let's see what is the recipe bring the app to Azure."

And why Azure? Because we want to make use of the ecosystem that Microsoft takes years to fine-rune.

Step 1: Have your application ready on GitHub

This article will mainly cover the steps to publish .NET Blazor web applications. However, from the information I have so far, the steps can also be applied to .NET Core applications, and possibly .NET Framework too (though more limited in this case).

If you do not have any application ready, you can fork my portfolio (a .NET Blazor Web Assembly application) to try setting up on your own.

I recommend putting your application on GitHub, as this article covers the auto-deployment via GitHub Actions.

This article only covers the application alone, not the setup of application's database on Azure. The databases that Azure offers are only available above the free tier. That being said, you can still try setting up Azure databases out of free tier, but just thread carefully cuz it's no longer free. Some alternatives are to have your own public database and its API elsewhere, and have your application wired to it from your local machine or from Azure. Another option that I am working on is to create a virtual memory database that should not exceed 1 GB RAM.

Step 2: Know the Limits of free tier

As of now Jan-2024, Free tier of Azure Web Application offers the following:

1 Region from a limited pool (e.g. East US)
60 CPU minutes / day
1 GB RAM
1 GB Storage

If you need more, take a look at the pricing.

While these limits may look even worse than a typical home-owned PC, I like to take on these Limits of free tier, as it forces me to really know what I am doing, and my portfolio's designs and implementations to be the simplest (and it sure pays off well). Bad designs tend to come from taking your server's resources for granted until too late.

Finally, even being Free tier, Azure Web Services may still require your credit card details before you can proceed. So, get it ready.

Step 3: Access Azure

Access Azure (https://azure.microsoft.com/) and login or create a new free account if you have none.

If you encounter this announcement, it means you already have an account. You can re-use your existing subscription in your account.

After you get in, you should see the portal as following (may be changed in the future):

Proceed to "Create a resource", and then "Create" under "Web App" section:

Step 4: Setup

On the first page, choose the Subscription and Resource Group of your application:

If you are new, you may be required to create them. To explain shortly:

Subscription: your profile account that keeps track how much your applications have incurred (if you only uses Free tier, no amount should be incurred). It is best to have only 1 subscription, so that you don't get into the situation where you forget 1 subscription that keeps incurring debt to your self.
Resource Group: your profile account that organize your applications (and other kinds of resources like Databases, Insights, etc.). Resource Group helps organize your applications and resources in the way that you can find which ones are related to each other. And if one day you want to take off / dispose your applications / resources, you can just delete the Resource Group in one go.

You can have multiple applications sharing the same Subscription and Resource Group.

Next part, fill in the details. A typical fill-up can look like this. Pricing Plan is the most important option, as you can incur higher payment than you expect if choosing wrongly (and the default option is NOT Free, so you have to deliberately choose I just want to use it free):

To explain further:

Name: The domain how your app is accessed. For example, with peter1992, your app will be accessed peter1992.azurewebsites.net. Your name may not be available if someone else has used it.
Publish: Choose "Code", which should work for both Server side apps, Client side (e.g. Web Assembly) apps, or hybrid types (FYI, my portfolio is currently pure Client side). "Docker Container" can work as well, but I prefer simpler option like "Code." "Static Web App" should only be applicable to Client side apps.
Runtime stack: Since we are working on .NET applications here, choose a .NET stack that should be same or above your application's stakc. For example with my portfolio, its web application PeterDoStuff.MudWasm is .NET 6, so the choice of .NET 7 should work.
Operating system: Either Linux or Windows should work for .NET Core or Blazor applications. However, Windows tend to be less risky option, in my personal opinion.
Region: The target audience of your application. That does not mean people in different regions cannot access your application, they just feel it slower. If your application is total server side apps, this choice becomes important. However, if your application is client side or hybrid, the speed is not much different and my recommendation is "East US" default option.
Pricing Plans: If you are new, you will need to create a new plan. Otherwise, you can re-use the plan you have created previously. Take note to choose "Free F1 (Shared Infrastructure)" before proceeding further if you are not ready to pay for higher tier. Be careful, as the default option is not Free F1, so don't skip it.

Proceed "Next" to Database. If your pricing plan is Free F1, you can skip "Next" to Deployment:

In Deployment, your option for Continuous Deployment is Disabled by default. Switch to Enabled, as it would be useful in the long run:

You may need to wire your GitHub with Azure if you are new. Once your GitHub is wired, you can find your repositories under Repository. Choose the Repository you would like to publish, and the branch that is based on, usually master. With this, whenever there is any change in master branch, it will be auto-updated into your published application after a few minutes.

Proceed "Next" to Networking. Review and enable the public access:

Proceed "Next" to Monitoring. I am not sure how Insight pricing works, so to be safe, you can disable it for now:

Proceed "Next" to Tags. To keep it simple, we can skip:

Preview your Summary, then proceed to "Create":

Step 5: Observe your GitHub Action

Revisit your application repo on GitHub.

The moment you successfully Create the application at Azure, Azure will update your application repo with the following:

First, a new folder named .github/workflows is created if it does not exists. Inside, Azure creates or updates the yml file that tells GitHub actions to deploy your application to your Azure application when there is any change to your master branch (or another branch based on your setup):

Second, under "Settings" tab, in Security > Secrets and Variables > Actions, Azure will tell GitHub to create a secrets variable. This is the secret that allows your GitHub repository to push your application to your Azure application:

Access "Actions" tab on your GitHub to see if your deployment is successful. 90% it should work, but sometimes there can be hiccup that requires some troubleshooting.

There is a possibility that you may encounter this error:

It seems around the time of the article (Jan-2024), Azure seems to have some hiccup in their Azure Web Service. To solve this problem, access Azure Web Service portal, access the Application you created, and access the Deployment Center. You may see the following error about Basic Authentication:

Click on the error message to bring yourself to the Configuration page, which shows Basic Authentication is On:

Turn it Off, save, then On again, and finally Save.

Revisit your GitHub Actions, and re-run all the jobs:

Your GitHub action should be successful. Feel free to reach out to me via LinkedIn if you encounter another problem where your action workflow fails.

Step 6: View your application

After the workflow in Actions runs with no failure, you should be able to access your application via the name you have set, e.g. https://peter-do-stuff.azurewebsites.net/:

Bonus:

Just to share my hobby with Generative AI:

Congratulations Minerva on becoming a new Animagus. It's Purrfect!

Prof. Dumbledore