At work I was asked to create and deploy a new .NET 8 Blazor app to an Azure Static Web App.
I’m brand new to Blazor, and brand new to Azure Static Web Apps, so I had a few stumbling blocks.
One of them was that I was getting this error when deploying via Azure Pipelines (using the AzureStaticWebApp@0 task):
Failed to find a default file in the app artifacts folder. Valid default files: index.html,Index.html.
The root cause of this was that when I created my Blazor app, I did so in Visual Studio 2022 using the “Blazor Web App” project template:
I should have instead used the “Blazor WebAssembly Standalone App” project template:
This was an easy newbie mistake to make, because:
- The Blazor Web App template is suggested immediately, I didn’t need to search for it. I didn’t know the WebAssembly Standalone App template exists, until I searched for “Blazor” in the New project search box.
- The Blazor Web App template includes options to choose the Interactive Render Mode, and WebAssembly is one of them, so I thought I was choosing doing the correct option for an Azure Static Web app.
More instructions are on Thomas Gauvin’s blog post.
Here’s some more thoughts I have on Static Web Apps so far, particularly the AzureStaticWebApp@0 Pipeline task.
- I don’t like the deployment model, i.e. how it deploys from your source repo directly. I prefer a traditional Build Artifact approach, because a Build Artifact is a set in stone and can be deployed to another environment. Deploying from source feels wishy-washy.
- I also don’t like how the it needs a unique deployment token to deploy to it, via the azure_static_web_apps_api_token parameter. Why can’t it use the same parameters as other tasks, i.e. AzureFunctionApp@2, which takes azureSubscription and appName parameters.


Fully agree with your thoughts on the deployment model and the token parameter!
Deploying Build Artifacts needs to be supported! Defeats the purpose of Azure DevOps CI/CD Pipelines if it’s not possible to link to your existing Build pipelines.
Yeah, I still agree that it would be better to deploy a SWA from a Build artifact rather than from source code – if you’re using a separate Release pipeline.
It’s been over a year since I wrote this post, and I must admit that I haven’t had any issues with deploying SWAs from source. On our project we have a single Build pipeline with different stages
and the above has been working fine for over a year.