LuisLlamas Logo
blazor-entorno-desarrollo-estructura

Development Environment and Structure of a Blazor Project

  • 5 min
  • Beginner

The Blazor development environment is the set of tools with which we create, run, and debug the application.

In this article, we will install the necessary tools and create a project with the current template. Then, we will go through the generated files to understand where everything goes.

Understanding this structure prevents you from getting lost when the application starts to grow.

Environment Installation

To work with Blazor, we need the .NET SDK and an editor. In this course, we will use Visual Studio 2022, although you can also work with Visual Studio Code or the .NET CLI.

Visual Studio 2022

Download or update Visual Studio 2022 to a version compatible with the SDK you plan to use.

During installation, in the “Workloads” tab, make sure to check the box:

  • ASP.NET and web development

This installs the Razor editors and web build tools. Also, verify that you have the .NET 10 SDK (or the SDK for your project’s target version) available.

If you already had Visual Studio installed, open Visual Studio Installer and check both the workload and the SDK. The runtime allows you to run applications; to compile them, you need the SDK.

Creating the Project

Open Visual Studio and select “Create a new project”. Search for “Blazor” and choose:

  • Blazor Web App

There is also a standalone Blazor WebAssembly template. For new development with server-side, client-side, or combined rendering, Microsoft recommends Blazor Web App starting from .NET 8.

Template Configuration

This screen contains several important decisions. Let’s configure the options as follows:

Framework: .NET 10. If your project is set to .NET 8 LTS, you can still follow the course, although some templates might vary.

Authentication type: None (we will cover this later).

Interactive render mode: Here we decide how we want interactivity to behave by default.

  • If you select Server: Everything runs on the server (SignalR).
  • If you select WebAssembly: Everything runs on the client.
  • If you select Auto: It starts with server-side interactivity and can use WebAssembly when the client package is available.
  • For this initial example, we will select Auto (Server and WebAssembly) to see the complete structure.

Interactivity location:

  • Per page/component: We decide component by component if it is interactive.
  • Global: The entire app is interactive (classic SPA).
  • We will select Per page/component, which is the default option.

Solution Structure

When creating the project with Auto mode, Visual Studio will generate a solution with two projects. This can be jarring at first, but it makes a lot of sense.

The Server Project (MyApplication)

This is the main project. It is an ASP.NET Core application that serves the initial HTML. It contains:

  • Database connections.
  • API controllers (if any).
  • Security configuration.
  • Components that are rendered in Server or Static SSR mode.

The Client Project (MyApplication.Client)

This project contains the code that will be downloaded to the browser when using WebAssembly or Auto mode.

  • Here you CANNOT directly access the database (you are in the user’s browser!).
  • Components that live here can run both on the server (prerendering) and on the client.

If we had chosen “Server” mode, we would only have one project. By choosing “Auto” or “WebAssembly”, we need to physically separate the code that can travel to the client from the code that must remain securely on the server.

Key Files

Let’s analyze the most important files in the main project (the server one).

This is the entry point. This file configures dependency injection and the HTTP pipeline.

var builder = WebApplication.CreateBuilder(args);

// Adds services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()  // Enables Server mode
    .AddInteractiveWebAssemblyComponents(); // Enables WASM mode

var app = builder.Build();

// Pipeline configuration
app.MapStaticAssets();
app.UseAntiforgery();

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddInteractiveWebAssemblyRenderMode()
    .AddAdditionalAssemblies(typeof(Counter).Assembly); // Links the Client project

app.Run();
Copied!

We can clearly see how the render modes we selected are registered.

This is the root component of the application. It is the first HTML that is sent.

<!DOCTYPE html>
<html lang="en">

<head>
    <HeadOutlet />
</head>

<body>
    <Routes />
    <script src="_framework/blazor.web.js"></script>
</body>

</html>
Copied!

Notice two key components:

  1. <Routes />: It is responsible for checking the URL and deciding which component to load.
  2. blazor.web.js: This is the script that starts Blazor in the browser.

This file defines the routing.

<Router AppAssembly="@typeof(Program).Assembly">
    <Found Context="routeData">
        <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
    </Found>
    <NotFound>
        <p>Sorry, there's nothing at this address.</p>
    </NotFound>
</Router>
Copied!

It basically says: “If you find a component that matches the route, display it using the MainLayout. If not, show a 404 error.”

Here are the routable pages of the application, and we will write a good part of the course components here.

  • Home.razor: The home page.
  • Weather.razor: An example of data loading.

Here go the “traditional” static files:

  • css/: Your styles (Bootstrap comes by default).
  • app.css: Global styles.

On this page