dateo. Coding Blog

Coding, Tech and Developers Blog

blazor
asp.net
azure
github

Deploy your Blazor app to Azure now for free!

Dennis Frühauff on June 14th, 2023

With the new Static Web Apps service on Microsoft Azure, deploying your side or even enterprise projects and applications has never been easier. You can try that out in just a couple of clicks. And the best: It's free for personal use and small projects. Let's see how that works.


I have worked with both Microsoft Azure and Amazon Web Services extensively lately, but Azure's recent service Static Web Apps has caught me off guard: Never has it been easier to deploy simple applications to the cloud, all in a matter of minutes. And for small and personal-use projects it's completely free.


In this article, I will show you the basics of how you can start deploying to the cloud immediately.


Prerequisites

I will demonstrate how to build and deploy a Blazor Web Assembly application to Azure Static Web Apps (SWA). If you want to follow along, you will need an active Azure and GitHub account; everything else will be provided by this tutorial.


What is Azure Static Web Apps?

The Azure SWA service provides you with an environment to deploy your static web applications with


  • globally-distributed hosting,
  • build and deployment automation,
  • domains and SSL certificates,
  • authentication options,
  • staging environments,
  • CLI support,
  • support for Blazor, Vue, React, Angular, Svelte, and other frontend frameworks,
  • support to hook up to Azure functions and containerized apps.

You can have a look at the official documentation. The current pricing plans support a free and a professional option, depending on what your application might need. For our purposes, the free plan is more than enough.


Getting started: Create a project

Let's get started. The first we'll have to do is create a new dotnet solution and a Blazor Web Assembly project. You can do this with both Visual Studio and JetBrains Rider (which I am a fan of), but for the purpose of this post, we'll use the dotnet command line (that's fewer screenshots for me 😉).


We head over to our repository folder on our disk, which is D:\repos in my case.
With dotnet list new you can see a list of all the templates that are installed on your machine. We'll use blazorwasm here.


First, we create a new folder for the solution, cd into it and create a new solution file:


md Sandbox.BlazorStaticWebApp
cd .\Sandbox.BlazorStaticWebApp\
dotnet new sln --name Sandbox.BlazorStaticWebApp

Now, we create a Blazor Web Assembly project and associate it with the solution:


dotnet new blazorwasm --name Client
dotnet sln add .\Client\Client.csproj

And last, since we know that we will use git in the process, we create a .gitignore file. And you know what? The dotnet CLI can do this for us as well:


dotnet new gitignore

We now already have a working application. We can start it by cding into its directory and executing it:


cd .\Client\
dotnet run

The terminal will display the URL on your machine, that is http://localhost:5037 in my case.
If we navigate to this we'll the familiar Blazor template with which we can now work.


Actually, in order to show you how to deploy this application to Azure, we don't need to do anything else with our app. The only thing we'll change, because it's fun, is adding some more information to the index page Index.razor:


@page "/"

<PageTitle>Index</PageTitle>

<h1>Hello, world!</h1>

Welcome to your new app.
<br/>
Processor count: @Environment.ProcessorCount
<br/>
OS Version: @Environment.OSVersion
<br/>

Create a repository on GitHub

Now, we are ready to put our application out into the world. To do this, we navigate to our GitHub account and create a new repository. You can name it whatever you like. I will, obviously, stick to the name of the solution and also make it public so that you can access the code later. All of the other options need not be touched. We are initializing a completely empty repository.


On the following page, GitHub is nice enough to tell you how to proceed when pushing an existing repository to GitHub.


So, we go back to the terminal on our machine and navigate to the root directory of the solution. From there, we execute the following commands:


git init
git add .
git commit -m "This is the first commit"
git remote add origin https://github.com/FoxDawg/Sandbox.BlazorStaticWebApp.git
git branch -M main
git push -u origin main

Make sure that you change the 4th line to whatever GitHub tells you to use in your case.


Once you refresh your GitHub page, you should be able to see your code.


Easy, right? And we are already finished in GitHub. Let's head over to Azure for the final step.


Create a static web app on Azure

Navigate to the Azure Portal and log in (or create a new subscription if you have none).


From the search bar, you should be able to find the Static Web Apps service.


Screenshot 1


Once there, you can hit the Create button right away.
In the following screenshot, you will see the complete setup for my application, but let's pick that apart.


Screenshot 2


  • Subscription: You need to assign your work to a subscription.
  • Resource Group: All resources related to this application will be assigned to a group. If you leave this field out, Azure will automatically create a new one for you.
  • Name: Give your application a name.
  • Plan Type: The free plan really is free, so don't worry.
  • Region: You can pick a region that is located near your hometown or whatever you like. This is only relevant for the Azure Functions backend if you have one. Your static content will be globally distributed to sit where your users are.
  • Source: We obviously choose GitHub, but you can also hook up to an Azure DevOps subscription. Azure will also ask you to log in to your account from here. You can then choose the corresponding repository and branch.
  • Build Presets: You'll find a list of all the frameworks that are supported out of the box. Pretty impressive, if you ask me.
  • App location: This is the folder of your client app within your solution directory. Client in our case.
  • Api location: If you start with a template that supports Azure Functions as a backend, you can specify the folder here as well. We have no such thing, so it can stay empty.

That's it. Now hit Review + Create and Azure will start deploying the application.


In fact, Azure will go into your GitHub repository and commit an automated workflow file, set up a few secrets, and configure all of the necessary Azure resources for you. It is pretty much a no-brainer.


Once finished, hit Go to resource and find the value for the URL.
In my case, the GitHub deploy action actually failed and that might be the case for you as well. If you navigate to the workflow file in your repository, you might notice a line


api_location: "" # Api source code path - optional

We do not have an API, so we can simply delete that line (Just hit the pen in the top right and commit your changes). Since we committed to main, GitHub will start deploying your application again.


Give it a few minutes, after which you should be able to navigate to the URL Azure provided you with:
Screenshot 3


Sad though, we didn't learn anything interesting from the additional code...
But still, that was pretty easy, wasn't it?


What else is there?

The Azure + GitHub integration (and Azure DevOps, of course) comes with more features. For example, if you or one of your colleagues creates a pull request to main in your repository, Azure will automatically deploy a staging site. That way, reviewers can actually see your changes live and play with it. Once merged, the staging site will automatically be destroyed again. How do you get the URL, you might ask? Azure will add it to the pull request's discussion, and you can also see the list of deployed environments from Azure itself.


Also, authorization options between client application and API (if present) can be easily configured as well, making the experience as smooth as possible.


You can also link your client to already deployed containerized applications in Azure.


Conclusion

In terms of user experience, deploying simple projects and applications has probably never been easier and I have to say that I am very impressed by how well-integrated Azure has become with external service providers.
I hope you'll have some fun building your own applications and deploying them to the cloud!


As usual, you can find the code on GitHub



Please share on social media, stay in touch via the contact form, and subscribe to our post newsletter!

Be the first to know when a new post was released

We don’t spam!
Read our Privacy Policy for more info.

We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.