When building a web application, it can be helpful to deploy your application with the latest features and code changes to a server, so that users can actually test it. Especially at the beginning of a new project, setting up such an environment where test users can immediately see and test new features is super important.

When you push your code to a repository on GitHub, you can use a so-called GitHub action to build and deploy your application automatically. Instead of setting this up manually on GitHub.com, .NET developers can use Visual Studio.

In this blog post, you will learn how to automatically publish your .NET web application to an Azure App Service on every commit with a GitHub action that you create in Visual Studio. We’ll look at the following steps:

1. Create a new Blazor Server Project
2. Push the Project to a new GitHub Repository
3. Publish the App to Azure with a GitHub Action
4. Trigger a Deployment with Another Commit

Let’s start and let’s create a new Blazor Server project.

Create a New Blazor Server Project

Blazor is Microsoft’s web framework to build Single Page Applications (SPAs). It belongs to the ASP.NET Core family, which is Microsoft’s .NET-based web framework stack that contains also functionality to build for example REST APIs and server-side web applications like MVC or Razor Pages.

The word Blazor is a combination of “Browser” and “Razor”. Razor is a syntax that allows you to mix HTML and C# code to build web applications.

To host a Blazor web application, you have different options, all available via different project templates in Visual Studio:

• Blazor Server: The application runs with .NET on the server. The browser loads a JavaScript file to set up a communication channel to the server via WebSockets. The WebSocket connection is established via SignalR, which is an open-source communication library from Microsoft. From a user perspective, this server-side application feels like a client-side application that runs natively in their browsers, because there are no full page reloads.
• Blazor WebAssembly (WASM): The application is downloaded and runs directly in the browser with a WebAssembly-based .NET runtime. WebAssembly is a binary instruction format that is natively supported by all modern browsers.
• Blazor Hybrid: The application runs in a native .NET mobile or .NET desktop application. With Blazor Hybrid, you can use your Blazor skills to build mobile and desktop apps, and you can share components between mobile, desktop, and the web.

Especially for internal Line-of-Business (LOB) applications, Blazor Server is a very popular option, because:

• It is easy to deploy, you just need a server
• Compared to Blazor WebAssembly, there’s no need to build a separate REST API to load data from a database. As your .NET code runs on the server and not in the browser, you can directly access a database.

To be able to create a Blazor Server application, you must install the “ASP.NET and web development” workload with the Visual Studio Installer, like you see it in the screenshot below.

With the workload installed, Visual Studio has different Blazor project templates that you see in the “Create a new project” dialog below. With the Blazor Server App project template selected, a new Blazor Server project can be created.

After clicking on the Next button in the “Create a new project” dialog, you can enter a project name. In this case, the project name BlazorServerApp is entered, like you see it in the dialog below.

After clicking again on the Next button, you can choose on the dialog page that you see below the target framework and some other options like authentication type or enabling Docker. Let’s keep the default values.

After clicking on the Create button, the Blazor Server project is created and you can see it in Visual Studio’s Solution Explorer. In the project’s Pages folder you find the page components of the Blazor Server application, ending with the file extension .razor. In the screenshot below you can see that there are the page components: Index.razor, FetchData.razor and Counter.razor.

When you debug the application, it runs on a port on your localhost. In the screenshot below you can see that it has by default three menuitems to navigate to the three pages Home (Index), Counter, and Fetch data. I navigated to the Counter page component. That component increases a counter when a button is clicked. It’s a simple component that shows how some UI interaction is done in Blazor.

The code snippet below shows the content of the Counter component. At the top you can see the page directive that defines the route “/counter”. When a user navigates to this route — in the screenshot above you can see the route in the browser’s address bar — the Counter.razor component shows up.

In the Counter.razor file below you can see that the component contains a UI part with HTML and a code block with C# at the bottom. The code block defines the field currentCount and an IncrementCount method to increase this field. In the UI part the IncrementCount method is called when the button is clicked, and the currentCount field is shown in a paragragh.

@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

This was a very brief overview of a Razor page component. You can also look at the other components of the default project. But this blog post is not about the Blazor web framework as such, instead it is about automatically deploying your application to Azure with a GitHub action. To do this, you first need to push your project to a GitHub repository. 

Push the Project to a new GitHub Repository

In Visual Studio 2022, with the Blazor Server project opened, you find at the top a menu item called Git. Under that menu item, there’s the option “Create Git Repository…”:

After clicking on the “Create Git Repository…” menu item, the “Create a Git repository” dialog that you see below comes up. On the left side you can select in this dialog different options: You can push to a remote repository on GitHub or Azure DevOps, or you can push to any other existing remote repository, or you can create just a local repository. In this case, the GitHub option is selected on the left side.

On the right side in the dialog above, you see the details of the selected options. With GitHub selected, you can see that two things will be done:

• Initialize a local Git repository: A local Git repository will be initialized for you.
• Create a new GitHub repository: A new GitHub repository will be created and the local repository will be pushed to that GitHub repository. As you can see, I’ve selected there my personal GitHub account thomasclaudiushuber. The dropdown to select a GitHub account allows you to add a new GitHub account. For the repository, the name BlazorServerApp is specified. At the bottom you can also see that I’ve specified that this is a private repository (It’s a bit cutted though in the screenshot due to scrolling). Private means that only I can see it on GitHub.com.

When you click in the dialog above on the Create and Push button, the local repository will be created and pushed to a new repository on GitHub. This means, after clicking that Create and Push button, you can open your browser and browse to the repository on Github.com. In the screenshot below you can see the repository on GitHub. It contains the code of the BlazorServerApp.

On the repository on GitHub, there’s an Actions tab. In the screenshot below that tab is selected, and there you can select an existing workflow template. Four workflow templates exist for .NET and you can see that there is one called “Deploy a .NET Core app to an Azure Web App”.

Wait, what’s the difference between a GitHub Action and a Workflow?
The whole CI/CD (Continuous Integration/Continuous Deployment) platform is called GitHub Actions. It allows you to automatically build, test, and deploy your application. The platform consists of different things like workflows, actions, jobs and runners.

A workflow is the thing that actually runs when a specific action happens, and it can trigger one or more jobs that are defined as part of the workflow. A workflow is also what you can select in the screenshot above. Correctly, a workflow is called a GitHub Actions workflow, but quite often developers just refer to a workflow as a GitHub action.

When you configure a workflow directly on GitHub, it means that you need to take care of configuring all the required secrets, so that the GitHub action respectively the workflow is allowed to publish your application to Azure. Instead of configuring the workflow on GitHub, you can set up everything directly in Visual Studio, and then Visual Studio will take care of the secrets. Let’s see how to do this in the next section.

Publish the App to Azure with a GitHub Action

To publish your application to Azure with a GitHub Actions workflow, you first must create that workflow. To do this, you right-click the project in Visual Studio’s Solution Explorer. Like in the screenshot below, you select from the context menu the Publish… menu item.

After clicking on the Publish… menu item, Visual Studio’s Publish dialog opens up. You can see it in the screenshot below. First, you select a publication target. In this case here, let’s select Azure as a target, as you want to publish the Blazor Server application to the Microsoft cloud.

After clicking on the Next button, you can select a specific target on Azure. As .NET is a cross-platform framework, let’s publish the application to a Linux-based Azure App Service. The Linux-based Azure App Service is actually a little bit cheaper than the Windows-based one:

In the next step, you select an Azure App Service instance that you want to use as a deployment target. As you can see in the screenshot below in the top right corner, I’m signed in with my Microsoft account. That account has an Azure subscription assigned. Now an Azure App Service instance can be selected or created. As you can see in the screenshot below, there are no existing instances available, so I have to create a new one. A new one can be created by clicking on the “Create new” button.

Clicking on the “Create new” button brings up the App Service dialog that you see below. There, you can select a name for the App Service, the Azure subscription, a resource group, and a hosting plan.

When you click behind the Hosting Plan on New…, you can create a new hosting plan for your App Service with the dialog that you see below. I gave the plan the name BlazorServerAppHuber, I selected Germany as a location, as I am in Germany, and I selected the small S1 size for this simple demo.

After clicking on the OK button, the specified hosting plan is selected for the App Service, as you can see in the dialog below. I also gave the App Service the name BlazorServerAppHuber. That name must be unique in Microsoft Azure, as it is part of the public domain, under which your application will run.

Now it’s time to click on the Create button. When you do this, you will see like below that the App Service is being created. This takes usually around 1–2 minutes to complete.

The dialog will close automatically when the App Service has been created. Then you’re back in the Publish dialog that you see below. There the created App Service shows up and is selected. This means that you can click on the Next button of the Publish dialog to proceed.

In the screenshot below you see the last step of the Publish dialog, which is selecting the deployment type. You can generate a pubxml file with the options that you selected in the previous steps of the Publish dialog. This means that you publish your application to the Azure App Service by manually selecting the Publish context menu in Visual Studio. This is great if you want to control when the application gets published. But in this case here, let’s select the second option, CI/CD using GitHub Actions workflows. This option will create a GitHub Actions workflow that deploys your application automatically to Azure everytime you push code to the GitHub repository.

After clicking on the Finish button, the dialog shows what Visual Studio generated, as you can see in the screenshot below. Visual Studio generated the required secrets and the BlazorServerAppHuber.yml file that contains the GitHub Actions workflow.

Now you can close the Publish dialog.

In Visual Studio you will see like in the screenshot below a Publish tab with the created workflow in the BlazorServerAppHuber.yml file. By the way, you can always open this Publish tab again by using the Publish… context menu from Visual Studio’s Solution Explorer.

When you go to the Solution Explorer, you can see there besides the Blazor Server project the generated BlazorServerAppHuber.yml file under a GitHub Actions node:

When you open that BlazorServerAppHuber.yml file, you can take a look at the YAML code. You can see the content of this file in the code snippet below. At the top, you can see that the workflow is triggered when you push to the main branch of the GitHub repository. After some environment content, you can see that the workflow has two jobs: build and deploy. The build job uses the .NET SDK and the .NET CLI (Command Line Interface) to build the Blazor Server application. The deploy job uses the compiled project from the build job — the so-called artifact — and deploys it to Azure. That’s it.

name: Build and deploy .NET Core application to Web App BlazorServerAppHuber
on:
  push:
    branches:
    - main
env:
  AZURE_WEBAPP_NAME: BlazorServerAppHuber
  AZURE_WEBAPP_PACKAGE_PATH: ./published
  CONFIGURATION: Release
  DOTNET_CORE_VERSION: 6.0.x
  WORKING_DIRECTORY: ''
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET SDK
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_CORE_VERSION }}
    - name: Restore
      run: dotnet restore "${{ env.WORKING_DIRECTORY }}"
    - name: Build
      run: dotnet build "${{ env.WORKING_DIRECTORY }}" --configuration ${{ env.CONFIGURATION }} --no-restore
    - name: Test
      run: dotnet test "${{ env.WORKING_DIRECTORY }}" --no-build
    - name: Publish
      run: dotnet publish "${{ env.WORKING_DIRECTORY }}" --configuration ${{ env.CONFIGURATION }} --no-build --output "${{ env.AZURE_WEBAPP_PACKAGE_PATH }}"
    - name: Publish Artifacts
      uses: actions/upload-artifact@v3
      with:
        name: webapp
        path: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
    - name: Download artifact from build job
      uses: actions/download-artifact@v3
      with:
        name: webapp
        path: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
    - name: Deploy to Azure WebApp
      uses: azure/webapps-deploy@v2
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.BlazorServerAppHuber*** }}
        package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

To run the created GitHub Actions workflow, you need to push it to GitHub. When you go in Visual Studio to the Git Changes window, you can see like in the screenshot below that the BlazorServerAppHuber.yml file was added in the new folder .github\workflows. That folder is where GitHub Actions workflows for your GitHub repository are defined. 

With the commit message “Add GitHub action” specified, let’s create and push the commit from the Git Changes window of Visual Studio. After doing this, you can go back to your browser and navigate to the Actions tab of your GitHub repository. As you can see in the screenshot below, under this Actions tab a workflow is now running for that “Add GitHub action” commit that we just pushed to the repository.

When you click on the running workfow, you can see the details like in the screenshot below. You can see that the workflow contains two jobs, build and deploy. The build job completed already, and the deploy job is currently running:

You can also click on one of the jobs to view the details. When you click on the deploy job, you can expand the step Deploy to Azure WebApp, like you see it in the screenshot below. Expanding this step works after the step has finished. There you can see the URL to which the application has been deployed. The URL has by convention this format: https://%NAME_OF_YOUR_APP_SERVICE%.azurewebsites.net.

Now let’s open a new browser window and let’s navigate to that URL. Here we go, the Blazor Server app comes up in the browser, now served from the newly created Azure App Service:

When you go back to the Publish tab in Visual Studio, you can also see there at the bottom the URL/Site, to which the application has been published:

Now everything is set up: The Blazor Server app project was pushed to a GitHub repository. That GitHub repository contains a GitHub Actions workflow that will build and deploy the application to an Azure App Service on every commit. Let’s trigger another deployment by pushing another commit to the GitHub repository.

Trigger a Deployment with Another Commit

The Pages/Index.razor file of the Blazor Server project defines the home page component of our application. When you look at the code of this Index.razor file, you can see that it has the following content:

@page "/"

<PageTitle>Index</PageTitle>

<h1>Hello, world!</h1>

Welcome to your new app.

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

Now let’s remove the SurveyPrompt component from the Index.razor file and let’s adjust the heading from “Hello, world!” to “Welcome to our new Blazor Server App”:

@page "/"

<PageTitle>Index</PageTitle>

<h1>Welcome to our new Blazor Server App</h1>

Welcome to your new app

Next, let’s go in Visual Studio to the Git Changes window and let’s create and push another commit for this change:

After pushing this commit from Visual Studio to the GitHub repository, you can see on GitHub that the workflow is running for this new commit:

Also on the Publish tab in Visual Studio, you can see that the workflow is running for the pushed commit:

After the workflow finished, you can refresh the browser. On the home page, you can see now the adjusted content with the new heading that you just pushed to the GitHub repository:

Summary

You learned in this blog post how to set up a GitHub Actions workflow in Visual Studio to build and deploy your .NET web application after every pushed commit to an Azure App Service. This functionality makes it easy to build and publish appilcations for your customers. Besides the GitHub Actions workflow as such, Visual Studio also allows you to create the necessary Azure App Service to host the application. This means that everything needed to build, deploy, and host your .NET web application in the Microsoft Cloud can be done from Visual Studio.