LuisLlamas Logo
blazor-entorno-desarrollo-estructura

Entorno de desarrollo y estructura de un proyecto Blazor

  • 5 min
  • Iniciación

El entorno de desarrollo de Blazor es el conjunto de herramientas con el que creamos, ejecutamos y depuramos la aplicación.

En este artículo vamos a instalar lo necesario y a crear un proyecto con la plantilla actual. Después recorreremos los archivos que genera para entender dónde va cada cosa.

Entender esa estructura evita que te pierdas cuando la aplicación empiece a crecer.

Instalación del entorno

Para trabajar con Blazor necesitamos el SDK de .NET y un editor. En este curso usaremos Visual Studio 2022, aunque también puedes trabajar con Visual Studio Code o con la CLI de .NET.

Visual Studio 2022

Descarga o actualiza Visual Studio 2022 a una versión compatible con el SDK que vayas a utilizar.

Durante la instalación, en la pestaña de “Cargas de trabajo” (Workloads), asegúrate de marcar la casilla:

  • Desarrollo de ASP.NET y web

Esto instala los editores de Razor y las herramientas de compilación web. Comprueba además que tienes disponible el SDK de .NET 10 (o el SDK de la versión objetivo de tu proyecto).

Si ya tenías Visual Studio instalado, abre Visual Studio Installer y comprueba tanto la carga de trabajo como el SDK. El runtime permite ejecutar aplicaciones; para compilarlas necesitas el SDK.

Creando el proyecto

Abre Visual Studio y selecciona «Crear un nuevo proyecto». Busca «Blazor» y elige:

  • Aplicación web de Blazor (Blazor Web App)

También existe la plantilla independiente de Blazor WebAssembly. Para desarrollo nuevo con renderizado del servidor, del cliente o combinado, Microsoft recomienda Blazor Web App desde .NET 8.

Configuración de la plantilla

Esta pantalla reúne varias decisiones importantes. Vamos a configurar las opciones así:

Framework: .NET 10. Si tu proyecto está fijado a .NET 8 LTS, también puedes seguir el curso, aunque alguna plantilla puede variar.

Authentication type: None (lo veremos más adelante).

Interactive render mode: Aquí decidimos cómo queremos que sea la interactividad por defecto.

  • Si eliges Server: Todo corre en el servidor (SignalR).
  • Si eliges WebAssembly: Todo corre en el cliente.
  • Si eliges Auto: Empieza con interactividad en el servidor y puede usar WebAssembly cuando el paquete cliente ya está disponible.
  • Para este ejemplo inicial, seleccionaremos Auto (Server and WebAssembly) para ver la estructura completa.

Interactivity location:

  • Per page/component: Decidimos componente a componente si es interactivo.
  • Global: Toda la app es interactiva (SPA clásica).
  • Seleccionaremos Per page/component, que es la opción predeterminada.

Estructura de la solución

Al crear el proyecto con modo Auto, Visual Studio nos generará una solución con dos proyectos. Esto es algo que choca al principio, pero tiene mucho sentido.

El proyecto servidor (MiAplicacion)

Es el proyecto principal. Es una aplicación ASP.NET Core que sirve el HTML inicial. Aquí reside:

  • La conexión a base de datos.
  • Los controladores de API (si los hubiera).
  • La configuración de seguridad.
  • Los componentes que se renderizan en modo Server o Static SSR.

El proyecto cliente (MiAplicacion.Client)

Este proyecto contiene el código que se descargará al navegador cuando usemos el modo WebAssembly o Auto.

  • Aquí NO puedes acceder directamente a la base de datos (¡estás en el navegador del usuario!).
  • Los componentes que vivan aquí pueden ejecutarse tanto en el servidor (prerenderizado) como en el cliente.

Si hubiéramos elegido modo “Server”, solo tendríamos un proyecto. Al elegir “Auto” o “WebAssembly”, necesitamos separar físicamente el código que puede viajar al cliente del que debe quedarse seguro en el servidor.

Archivos clave

Vamos a analizar los archivos más importantes del proyecto principal (el del servidor).

Es el punto de entrada. En este archivo se configuran la inyección de dependencias y el pipeline HTTP.

var builder = WebApplication.CreateBuilder(args);

// Agrega servicios al contenedor.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()  // Habilita modo Server
    .AddInteractiveWebAssemblyComponents(); // Habilita modo WASM

var app = builder.Build();

// Configuración del pipeline
app.MapStaticAssets();
app.UseAntiforgery();

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddInteractiveWebAssemblyRenderMode()
    .AddAdditionalAssemblies(typeof(Counter).Assembly); // Vincula el proyecto Client

app.Run();
Copied!

Vemos claramente cómo se registran los modos de renderizado que hemos seleccionado.

Es el componente raíz de la aplicación. Es el primer HTML que se envía.

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

<head>
    <HeadOutlet />
</head>

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

</html>
Copied!

Fíjate en dos componentes clave:

  1. <Routes />: Es el encargado de mirar la URL y decidir qué componente cargar.
  2. blazor.web.js: Es el script que arranca Blazor en el navegador.

Este archivo define el enrutamiento.

<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!

Básicamente dice: “Si encuentras un componente que coincida con la ruta, muéstralo usando el MainLayout. Si no, muestra un error 404”.

Aquí están las páginas enrutables de la aplicación y escribiremos buena parte de los componentes del curso.

  • Home.razor: La página de inicio.
  • Weather.razor: Ejemplo de carga de datos.

Aquí van los archivos estáticos “de toda la vida”:

  • css/: Tus estilos (Bootstrap viene por defecto).
  • app.css: Estilos globales.

En esta página