Preparar el entorno práctico de C#

Resumen del laboratorio

[!NOTE] Un proyecto compilado y una suite de pruebas ejecutada son evidencias distintas.

Conceptos · Primera tarea · Lista de evidencias · Restablecer

Objetivos de aprendizaje

• Distingue un SDK instalado del entorno de ejecución de destino que necesita un proyecto.
• Compila un proyecto copiado sin tocar otros espacios de trabajo.
• Verifica el descubrimiento de pruebas en lugar de asumir que compilar equivale a probar.

Antes de empezar

Lee la configuración de la unidad de trabajo y los límites de recursos. Los fixtures integrados de C# tienen como destino .NET 10. C# Dev Kit es útil para descubrir pruebas en el editor; las compilaciones y pruebas de la línea de comandos siguen siendo la referencia reproducible.

Conceptos y casos de uso

dotnet build compila un proyecto. dotnet test descubre y ejecuta sus pruebas. dotnet run inicia la aplicación y puede depender del directorio de trabajo actual. Un SDK más reciente por sí solo no significa que todos los entornos de ejecución anteriores estén instalados.

Escenario del ejercicio

Prepara el fixture de la biblioteca para investigarlo, no una nueva plantilla de consola ni un cambio de configuración global.

Tarea 1 - Verificar las herramientas seleccionadas

1. Inspecciona el entorno de ejecución requerido por el .csproj del fixture seleccionado.
2. Ejecuta dotnet --list-sdks y dotnet --list-runtimes.
3. Si falta el entorno de ejecución requerido, usa la vía de instalación aprobada por tu organización o el Dev Container del repositorio. No instales todos los SDK.
4. Verifica Git y la extensión de C# de VS Code si vas a usar funciones del editor.
5. Para el acceso a Copilot, usa el laboratorio de configuración de cuenta.

Tarea 2 - Preparar y compilar un fixture

1. Desde la raíz del contenido formativo:

   node scripts/prepare-hands-on.js --lab 02-csharp --destination /Volumes/T9/Dev/oss/workshop-runs/02-csharp
   

2. Abre únicamente el directorio mostrado.

3. Con las variables de caché de la unidad de trabajo configuradas, ejecuta desde la raíz de esa copia:

   dotnet build src/Library.Console/Library.Console.csproj -m:1 -p:UseSharedCompilation=false
   dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false --list-tests
   dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false
   

4. Registra las pruebas descubiertas, los códigos de salida y cualquier advertencia. Una dependencia ausente de un origen de paquetes o de red es un bloqueo del entorno, no evidencia de una prueba de dominio fallida.

5. No añadas repetidamente el mismo origen NuGet ni cambies la configuración global de orígenes.

Verifica tu trabajo

• El destino del proyecto y el entorno de ejecución instalado coinciden.
• El proyecto de consola compila y el proyecto de pruebas descubre pruebas reales.
• La salida de las pruebas se registra por separado de la salida de compilación.
• Las cachés y los archivos generados permanecen en la unidad de trabajo seleccionada.

Solución de problemas

Si falta appSettings.json al ejecutar la aplicación de consola, cambia a src/Library.Console en la copia desechable antes de ejecutarla. Si no aparecen pruebas en el editor, selecciona o compila el proyecto de pruebas y actualiza el descubrimiento; no equipares «cero pruebas» con éxito.

Práctica independiente

Explica por qué --no-restore es apropiado después de una restauración exitosa, pero no en una copia recién obtenida del repositorio. Demuestra la diferencia sin instalar un nuevo framework de pruebas.

Restablecimiento

Cierra la ventana del fixture. Mantén intactos los SDK compartidos. Elimina únicamente la copia desechable inspeccionada si no hay evidencia ni cambios que deban conservarse.

Referencias oficiales

• Información general sobre .NET CLI
• Pruebas de C# en VS Code
• C# Dev Kit