{"meta":{"title":"Compilar y probar desarrollos en .NET","intro":"Aprende a crear un flujo de trabajo de integración continua (CI) para compilar y probar tu proyecto de .NET.","product":"GitHub Actions","breadcrumbs":[{"href":"/es/actions","title":"GitHub Actions"},{"href":"/es/actions/tutorials","title":"Tutoriales"},{"href":"/es/actions/tutorials/build-and-test-code","title":"Crea y prueba tu código"},{"href":"/es/actions/tutorials/build-and-test-code/net","title":".NET"}],"documentType":"article"},"body":"# Compilar y probar desarrollos en .NET\n\nAprende a crear un flujo de trabajo de integración continua (CI) para compilar y probar tu proyecto de .NET.\n\n## Introducción\n\nEsta guía te muestra cómo construir, probar y publicar un paquete de .NET.\n\nLos ejecutores hospedados en GitHub tienen un caché de herramientas con software pre-instalado, lo cual incluye el SDK de .NET Core. Para obtener una lista completa del software actualizado y las versiones preinstaladas del SDK de .NET Core, vea [Software instalado en ejecutores hospedados en GitHub](/es/actions/using-github-hosted-runners/about-github-hosted-runners).\n\n## Requisitos previos\n\nYa debes estar familiarizado con la sintaxis de YAML y con cómo se utiliza con GitHub Actions. Para más información, consulta [Sintaxis del flujo de trabajo para GitHub Actions](/es/actions/using-workflows/workflow-syntax-for-github-actions).\n\nTe recomendamos que tengas un entendimiento básico de .NET Core SDK. Para más información, vea [Introducción a .NET](https://dotnet.microsoft.com/learn).\n\n## Uso de una plantilla de flujo de trabajo de .NET\n\nPara comenzar rápidamente, agregue una plantilla de flujo de trabajo al directorio `.github/workflows` del repositorio.\n\nGitHub proporciona una plantilla de flujo de trabajo para .NET que debería funcionar para la mayoría de los proyectos de .NET. En las secciones siguientes de esta guía se proporcionan ejemplos de cómo puede personalizar esta plantilla de flujo de trabajo.\n\n1. En GitHub, navegue hasta la página principal del repositorio.\n\n2. En el nombre del repositorio, haz clic en ** Actions**.\n\n \n\n3. Si ya tiene un flujo de trabajo en su repositorio, haga clic en **New workflow** (Nuevo flujo de trabajo).\n\n4. En la página \"Elegir un flujo de trabajo\" se muestra una selección de plantillas de flujo de trabajo recomendadas. Busca «dotnet».\n\n5. En el flujo de trabajo «NET», haz clic en **Configurar**.\n\n6. Edita el flujo de trabajo según sea necesario. Por ejemplo, cambia la versión de .NET.\n\n7. Haga clic en **Commit changes** (Confirmar cambios).\n\nEl archivo de flujo de trabajo `dotnet.yml` se agrega al directorio `.github/workflows` de tu repositorio.\n\n## Especificar una versión de .NET\n\nPara usar una versión preinstalada del SDK de .NET Core en un ejecutor hospedado en GitHub, use la acción `setup-dotnet`. Esta acción busca una versión específica de .NET en la caché de herramientas en cada ejecutor y agrega los binarios necesarios a `PATH`. Estos cambios persistirán para el resto del trabajo.\n\nLa acción `setup-dotnet` es la forma recomendada de usar .NET con GitHub Actions, ya que garantiza el comportamiento coherente entre los distintos ejecutores y versiones de .NET. Si va a usar un ejecutor autohospedado, debe instalar .NET y agregarlo a `PATH`. Para más información, vea la acción [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk).\n\n### Utilizar versiones múltiples de .NET\n\n```yaml\nname: dotnet package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n strategy:\n matrix:\n dotnet-version: [ '3.1.x', '6.0.x' ]\n\n steps:\n - uses: actions/checkout@v6\n - name: Setup dotnet ${{ matrix.dotnet-version }}\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: ${{ matrix.dotnet-version }}\n # You can test your matrix by printing the current dotnet version\n - name: Display dotnet version\n run: dotnet --version\n```\n\n### Utilizar una versión específica de .NET\n\nPuede configurar el trabajo para que utilice una versión específica de .NET, como `6.0.22`. Como alternativa, puedes utilizar una sintaxis de versión semántica para obtener la versión menor más reciente. Este ejemplo utiliza el lanzamiento menor más reciente de .NET 6.\n\n```yaml\n - name: Setup .NET 6.x\n uses: actions/setup-dotnet@v4\n with:\n # Semantic version range syntax or exact version of a dotnet version\n dotnet-version: '6.x'\n```\n\n## Instalación de dependencias\n\nLos ejecutores hospedados en GitHub cuentan con el administrador de paquetes NuGet ya instalado. Puedes utilizar el CLI de dotnet para instalar dependencias desde el registro de paquetes de NuGet antes de compilar y probar tu código. Por ejemplo, el código YAML siguiente instala el paquete `Newtonsoft`.\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.0.x'\n- name: Install dependencies\n run: dotnet add package Newtonsoft.Json --version 12.0.1\n```\n\n### Almacenar dependencias en caché\n\nPuedes almacenar en caché las dependencias de NuGet para futuros flujos de trabajo mediante la entrada opcional `cache`. Por ejemplo, el código YAML siguiente almacena en caché la carpeta `global-packages` de NuGet y, a continuación, instala el paquete `Newtonsoft`. Una segunda entrada opcional, `cache-dependency-path`, se puede usar para especificar la ruta de acceso a un archivo de dependencia: `packages.lock.json`.\n\nPara más información, consulta [Referencia de almacenamiento en caché de dependencias](/es/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.x'\n cache: true\n- name: Install dependencies\n run: dotnet add package Newtonsoft.Json --version 12.0.1\n```\n\n> \\[!NOTE]\n> Según el número de dependencias, puede ser más rápido usar la caché de dependencias. Los proyectos con muchas dependencias de gran tamaño deberían ver un aumento del rendimiento, ya que reduce el tiempo necesario para la descarga. Los proyectos con menos dependencias podrían no ver un incremento significativo del rendimiento e incluso podrían ver un ligero decremento, debido a cómo NuGet instala las dependencias almacenadas en el caché. El rendimiento varía de un proyecto a otro.\n\n## Construir y probar tu código\n\nPuedes usar los mismos comandos que usas de forma local para construir y probar tu código. En este ejemplo se muestra cómo usar `dotnet build` y `dotnet test` en un trabajo:\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.0.x'\n- name: Install dependencies\n run: dotnet restore\n- name: Build\n run: dotnet build --no-restore\n- name: Test with the dotnet CLI\n run: dotnet test --no-build\n```\n\n## Empaquetar datos de flujo de trabajo como artefactos\n\nDespués de que se completa un flujo de trabajo, puedes cargar los artefactos que se den como resultado para su análisis. Por ejemplo, es posible que debas guardar los archivos de registro, los vaciados de memoria, los resultados de las pruebas o las capturas de pantalla. En el ejemplo siguiente se muestra cómo puede usar la acción `upload-artifact` para cargar los resultados de la prueba.\n\nPara más información, consulta [Almacenamiento y uso compartido de datos con artefactos de flujo de trabajo](/es/actions/using-workflows/storing-workflow-data-as-artifacts).\n\n```yaml\nname: dotnet package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n strategy:\n matrix:\n dotnet-version: [ '3.1.x', '6.0.x' ]\n\n steps:\n - uses: actions/checkout@v6\n - name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: ${{ matrix.dotnet-version }}\n - name: Install dependencies\n run: dotnet restore\n - name: Test with dotnet\n run: dotnet test --no-restore --logger trx --results-directory \"TestResults-${{ matrix.dotnet-version }}\"\n - name: Upload dotnet test results\n uses: actions/upload-artifact@v4\n with:\n name: dotnet-results-${{ matrix.dotnet-version }}\n path: TestResults-${{ matrix.dotnet-version }}\n # Use always() to always run this step to publish test results when there are test failures\n if: ${{ always() }}\n```\n\n## Publicación en registros de paquetes\n\nPuedes configurar tu flujo de trabajo para publicar tu paquete de .NET a un registro de paquetes cuando pasen tus pruebas de IC. Puedes utilizar secretos de los repositorios para almacenar cualquier token o credenciales que se necesiten para publicar tu binario. En el ejemplo siguiente se crea y publica un paquete en GitHub Packages mediante `dotnet core cli`.\n\n```yaml\nname: Upload dotnet package\n\non:\n release:\n types: [created]\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n permissions:\n packages: write\n contents: read\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.0.x' # SDK Version to use.\n source-url: https://nuget.pkg.github.com//index.json\n env:\n NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}\n - run: dotnet build --configuration Release \n - name: Create the package\n run: dotnet pack --configuration Release \n - name: Publish the package to GPR\n run: dotnet nuget push /bin/Release/*.nupkg\n```"}