Contents

Documentación de .NET
Primeros pasos
Hola mundo
Tutoriales de introducción
Vídeos de .NET 101
Cómo instalar
Información general
Instalar en Windows
Instalación en macOS
Instalar en Linux
Información general
Ubuntu
Alpine
CentOS
Debian
Fedora
OpenSUSE
Red Hat Enterprise Linux
SLES
Eliminación de entornos de ejecución y SDK obsoletos
Administración de plantillas de .NET
Incidencias de certificación notarial en macOS
Cómo comprobar las versiones de .NET
Instalación de una versión localizada de IntelliSense
Información general
Introducción a .NET
Componentes de la arquitectura .NET
Bibliotecas de clases de .NET
Información general de .NET Standard
 Versiones, revisiones y soporte técnico
Glosario de .NET
Tutoriales
Usar Visual Studio
Creación de una aplicación de consola
Depuración de una aplicación
Publicar una aplicación
Creación de una biblioteca
Prueba unitaria de una biblioteca
Instalar y usar un paquete
Crear y publicar un paquete
Usar Visual Studio Code
Creación de una aplicación de consola
Depuración de una aplicación
Publicar una aplicación
Creación de una biblioteca
Prueba unitaria de una biblioteca
Instalar y usar un paquete
Crear y publicar un paquete
Uso de Visual Studio para Mac
Creación de una aplicación de consola
Depuración de una aplicación
Publicar una aplicación
Creación de una biblioteca
Prueba unitaria de una biblioteca
Instalar y usar un paquete
Más tutoriales
Novedades de .NET
.NET 5.0
Novedades
Cambios importantes
.NET Core 3.1
 Novedades
Cambios importantes
.NET Core 3.0
Novedades
Cambios importantes
.NET Core 2.2
.NET Core 2.1
Novedades
Cambios importantes
.NET Core 2.0
.NET Standard
Herramientas y diagnósticos
Información general
SDK de .NET Core
Información general
Mensajes de error
NETSDK1005 y NETSDK1047
NETSDK1013
NETSDK1022
NETSDK1059
NETSDK1071
NETSDK1073
NETSDK1079
NETSDK1145
CLI de .NET Core
Información general
Referencia
dotnet
dotnet build
dotnet build-server
dotnet clean
dotnet help
dotnet migrate
dotnet msbuild
dotnet new
dotnet nuget
dotnet nuget delete
dotnet nuget locals
dotnet nuget push
dotnet nuget add source
dotnet nuget disable source
dotnet nuget enable source
dotnet nuget list source
dotnet nuget remove source
dotnet nuget update source
dotnet nuget verify
dotnet pack
dotnet publish
dotnet restore
dotnet run
dotnet sln
dotnet store
dotnet test
dotnet tool
dotnet tool install
dotnet tool list
dotnet tool restore
dotnet tool run
dotnet tool search
dotnet tool uninstall
dotnet tool update
dotnet vstest
Scripts de dotnet-install
Comandos de referencia del proyecto
 dotnet add reference
dotnet list reference
dotnet remove reference
Comandos del paquete del proyecto
dotnet add package
dotnet list package
dotnet remove package
Información general de global.json
Telemetría
Acceso elevado
Habilitación de la finalización con tabulación
Integración continua con la CLI
Desarrollo de bibliotecas con la CLI
Creación de plantillas para la CLI
Plantillas personalizadas
1 - Crear una plantilla de elemento
2 - Crear una plantilla de proyecto
3 - Crear un paquete de plantillas
Entornos de desarrollo integrados (IDE)
Visual Studio
Visual Studio para Mac
Visual Studio Code
MSBuild y archivos del proyecto
SDK de proyecto
Información general
Referencia
Microsoft.NET.Sdk
Microsoft.NET.Sdk.Web
Microsoft.NET.Sdk.Razor
Versiones de .NET Framework de destino
Adiciones al formato csproj
Administración de dependencias
Herramientas globales y locales
Administración de herramientas
Herramientas de solución de problemas
Creación de herramientas para la CLI
1 - Creación de una herramienta
2 - Uso de una herramienta global
3- Uso de una herramienta local
Herramientas adicionales
Información general
Herramienta de desinstalación de .NET
Herramienta de instalación de .NET para autores de extensiones
Generación de certificados autofirmados
Proveedor de WCF Web Service Reference
Utilidad del servicio WCF
Serializador XML del servicio WCF
Generador de serializador XML
Diagnóstico e instrumentación
Información general
Depuradores administrados
Volcados
Información general
Volcados de memoria de Linux
EventCounters
EventPipe
Registro y seguimiento
Eventos en tiempo de ejecución
Información general
Eventos de contención
Eventos de excepción
Eventos de recolección de elementos no utilizados
Eventos de interoperabilidad
Eventos de cargador y enlazador
 Eventos de método
Eventos ThreadPool
Eventos del sistema de tipos
Recopilación de diagnósticos en contenedores
Herramientas globales de la CLI de .NET Core
dotnet-counters
dotnet-dump
dotnet-gcdump
dotnet-trace
dotnet-symbol
dotnet-sos
Tutoriales de diagnóstico de .NET Core
Recopilación del seguimiento del rendimiento en Linux con PerfCollect
Obtención de métricas de rendimiento con EventCounters
Depuración de una fuga de memoria
Depuración del uso elevado de CPU
Depuración de interbloqueo
Análisis de código
Información general
Configuración
Opciones generales
Archivos de configuración
Reglas de calidad del código
Opciones de la regla
Configuraciones predefinidas
Reglas de estilo de código
Opciones de la regla
Referencia de reglas
Reglas de calidad del código
Introducción
Reglas de diseño
Información general
CA1000
CA1001
CA1002
CA1003
CA1005
CA1008
CA1010
CA1012
CA1014
CA1016
CA1017
CA1018
CA1019
CA1021
CA1024
CA1027
CA1028
CA1030
CA1031
CA1032
CA1033
CA1034
CA1036
CA1040
CA1041
CA1043
CA1044
CA1045
CA1046
CA1047
CA1050
CA1051
 CA1052
CA1053
CA1054
CA1055
CA1056
CA1058
CA1060
CA1061
CA1062
CA1063
CA1064
CA1065
CA1066
CA1067
CA1068
CA1069
CA1070
CA1071
Reglas de documentación
Información general
CA1200
Reglas de globalización
Información general
CA1303
CA1304
CA1305
CA1307
CA1308
CA1309
CA1310
CA2101
Reglas de portabilidad e interoperabilidad
 Introducción
CA1401
CA1416
CA1417
Reglas de mantenimiento
Información general
CA1501
CA1502
CA1505
CA1506
CA1507
CA1508
CA1509
Reglas de nomenclatura
Información general
CA1700
CA1707
CA1708
CA1710
CA1711
CA1712
CA1713
CA1714
CA1715
CA1716
CA1717
CA1720
CA1721
CA1724
CA1725
Reglas de rendimiento
Información general
 CA1802
CA1805
CA1806
CA1810
CA1812
CA1813
CA1814
CA1815
CA1819
CA1820
CA1821
CA1822
CA1823
CA1824
CA1825
CA1826
CA1827
CA1828
CA1829
CA1830
CA1831
CA1832
CA1833
CA1834
CA1835
CA1836
CA1837
CA1838
Reglas de publicación
Información general
IL3000
IL3001
Reglas de confiabilidad
Información general
CA2000
CA2002
CA2007
CA2008
CA2009
CA2011
CA2012
CA2013
CA2014
CA2015
CA2016
Reglas de seguridad
Información general
CA2100
CA2109
CA2119
CA2153
CA2300
CA2301
CA2302
CA2305
CA2310
CA2311
CA2312
CA2315
CA2321
CA2322
CA2326
CA2327
CA2328
CA2329
CA2330
CA2350
CA2351
CA2352
CA2353
CA2354
CA2355
CA2356
CA2361
CA2362
CA3001
CA3002
CA3003
CA3004
CA3005
CA3006
CA3007
CA3008
CA3009
CA3010
CA3011
CA3012
CA3061
CA3075
CA3076
CA3077
CA3147
CA5350
CA5351
CA5358
CA5359
CA5360
CA5361
CA5362
CA5363
CA5364
CA5365
CA5366
CA5367
CA5368
CA5369
CA5370
CA5371
CA5372
CA5373
CA5374
CA5375
CA5376
CA5377
CA5378
CA5379
CA5380
CA5381
CA5382
CA5383
CA5384
CA5385
CA5386
CA5387
CA5388
CA5389
CA5390
CA5391
 CA5392
CA5393
CA5394
CA5395
CA5396
CA5397
CA5398
CA5399
CA5400
CA5401
CA5402
CA5403
Reglas de uso
Información general
CA1801
CA1816
CA2200
CA2201
CA2207
CA2208
CA2211
CA2213
CA2214
CA2215
CA2216
CA2217
CA2218
CA2219
CA2224
CA2225
CA2226
CA2227
 CA2229
CA2231
CA2234
CA2235
CA2237
CA2241
CA2242
CA2243
CA2244
CA2245
CA2246
CA2247
CA2248
CA2249
Reglas de estilo de código
Información general
Reglas del lenguaje
Información general
Preferencias de this. y .me
Uso de palabras clave de idioma para tipos
Preferencias de modificadores
Preferencias de paréntesis
Preferencias de nivel de expresión
Preferencias de la comprobación de NULL
Preferencias de var
Miembros con forma de expresión
Preferencias de coincidencia de patrones
Preferencias de bloques de código
Preferencias de directiva "using"
Preferencias de encabezado de archivo
Reglas de código innecesario
Introducción
 IDE0001
IDE0002
IDE0004
IDE0005
IDE0035
IDE0051
IDE0052
IDE0058
IDE0059
IDE0060
IDE0079
IDE0080
IDE0081
IDE0100
IDE0110
Reglas varias
IDE0076
IDE0077
Reglas de formato
Información general
Reglas de nomenclatura
Información general
Analizador de compatibilidad de plataformas
Analizador de API
Analizador de portabilidad
Modelo de ejecución
Common Language Runtime (CLR)
Proceso de ejecución administrada
Ensamblados de .NET
Metadatos y componentes autodescriptivos
Carga de dependencias
Carga de dependencias
 Descripción de AssemblyLoadContext
Detalles de la carga de dependencias
Sondeo de dependencia predeterminado
Carga de ensamblados administrados
Carga de ensamblados satélite
Carga de bibliotecas no administradas
Tutoriales
Creación de una aplicación de .NET Core con complementos
Uso y depuración de la descargabilidad de ensamblado en .NET Core
Control de versiones
Información general
Selección de la versión de .NET Core
Configuración del entorno en tiempo de ejecución
Configuración
Configuración de la compilación
Depuración y configuración de perfiles
Nombre de recolector de elementos no utilizados
Configuración de la globalización
Configuración de redes
Configuración de subprocesos
Modelos de implementación
Información general
Implementación de aplicaciones con Visual Studio
Publicación de aplicaciones con la CLI
Creación de un paquete NuGet con la CLI
Puesta al día del runtime de implementación autocontenida
Implementación de archivo único y ejecutable
ReadyToRun
Recorte de implementaciones autocontenidas
Introducción y procedimientos
Opciones
Almacenamiento de paquetes en tiempo de ejecución
 Catálogo de identificadores de tiempo de ejecución (RID)
Nombres del manifiesto de recurso
Docker
Introducción a .NET y Docker
Incluir una aplicación de .NET Core en un contenedor
Herramientas de contenedor de Visual Studio
Componentes fundamentales de la codificación
Información general de los tipos base
Common Type System y Common Language Specification
Sistema de tipos comunes
Independencia de lenguaje
Componentes independientes del lenguaje
Conversión de tipos en .NET
Tablas de conversión de tipos
Elección entre tipos de tupla y anónimos
Bibliotecas del marco
Introducción a la biblioteca de clases
Tipos genéricos
Información general
Introducción a los tipos genéricos
Colecciones genéricas en .NET
Delegados genéricos para manipular matrices y listas
Interfaces genéricas
Covarianza y contravarianza
Colecciones y estructuras de datos
Información general
Seleccione una clase de colección
Tipos de colección utilizados normalmente
Cuándo utilizar colecciones genéricas
Comparaciones y ordenaciones en colecciones
Tipos de colecciones ordenadas
Tipos Hashtable y Dictionary
 Colecciones seguras para subprocesos
Delegados y expresiones lambda
Events
Información general
Provocación y consumo de eventos
Control de varios eventos mediante propiedades de evento
Modelo de diseño de observador
Información general
Procedimientos recomendados
Procedimiento Implementación de un proveedor
Procedimiento Implementación de un observador
Excepciones
Información general
Clase Exception y propiedades
Temas procedimentales
Uso del bloque Try/Catch para detectar excepciones
Uso de excepciones específicas en un bloque Catch
Inicio de excepciones explícitamente
Creación de excepciones definidas por el usuario
Creación de excepciones definidas por el usuario con mensajes de excepción
localizados
Uso de bloques Finally
Uso de controladores de excepciones filtradas por el usuario
Control de excepciones de interoperabilidad COM
Procedimientos recomendados
Tipos numéricos
Fechas, horas y zonas horarias
Atributos
Información general
Aplicación de atributos
Escritura de atributos personalizados
Recuperación de la información almacenada en atributos
Bibliotecas en tiempo de ejecución
Información general
Formato de números, fechas y otros tipos
Información general
Cadenas con formato numérico estándar
Cadenas con formato numérico personalizado
Cadenas con formato de fecha y hora estándar
Cadenas con formato de fecha y hora personalizado
Cadenas de formato TimeSpan estándar
Cadenas de formato TimeSpan personalizado
Cadenas de formato de enumeración
Formatos compuestos
Temas procedimentales
Relleno de un número con ceros a la izquierda
Extracción del día de la semana de una fecha
Uso de proveedores de formato numérico personalizado
Aplicación de acciones de ida y vuelta a valores de fecha y hora
Visualización de los milisegundos en valores de fecha y hora
Visualización de las fechas en calendarios no gregorianos
Operaciones con cadenas
Codificación de caracteres de .NET
Procedimiento para usar las clases de codificación de caracteres
Procedimientos recomendados
Comparar cadenas
Mostrar y conservar datos con formato
Cambios de comportamiento en .NET 5+ (Windows)
Operaciones básicas de cadenas
Información general
Creación de nuevas cadenas
Recorte y eliminación de caracteres
Relleno de cadenas
Métodos de comparación
Cambio de mayúsculas y minúsculas
 Separación de las partes de una cadena
Uso de la clase StringBuilder
Procedimiento para realizar manipulaciones básicas de cadena
Análisis (conversión) de cadenas
Información general
Análisis de cadenas numéricas
Análisis de cadenas de fecha y hora
Análisis de otras cadenas
Expresiones regulares
Información general
Referencia del lenguaje
Información general
Escapes de carácter
Clase de caracteres
Delimitadores
Construcciones de agrupamiento
Cuantificadores
Construcciones de referencia inversa
Construcciones de alternancia
Sustituciones
Opciones de expresiones regulares
Construcciones misceláneas
Procedimientos recomendados con expresiones regulares
Modelo de objetos de expresiones regulares
Comportamiento de expresiones regulares
Información general
Retroceso
Compilación y reutilización
Seguridad para subprocesos
Ejemplos
Búsqueda de HREF
Cambio de formatos de fecha
 Extracción de un protocolo y un número de puerto de una dirección URL
Eliminación de caracteres no válidos de una cadena
comprobar que las cadenas están en un formato de correo electrónico válido
Serialización
Información general
Serialización de JSON
Información general
Cómo serializar y deserializar JSON
Control del comportamiento de la serialización
Creación de una instancia de JsonSerializerOptions
Habilitación de la coincidencia sin distinción entre mayúsculas y minúsculas
Personalización de los nombres y valores de propiedad
Omisión de propiedades
Permiso del formato JSON no válido
JSON de desbordamiento de control
Conservación de las referencias
Tipos inmutables y descriptores de acceso no públicos
Serialización polimórfica
Migración desde Newtonsoft.json
Avanzado
Personalización de la codificación de caracteres
Serializadores y deserializadores personalizados
Convertidores personalizados
Serialización binaria
Información general
Guía de seguridad de BinaryFormatter
Origen de eventos de BinaryFormatter
Conceptos de serialización
Serialización básica
Serialización selectiva
Serialización personalizada
Pasos del proceso de serialización
 Serialización tolerante a versiones
Directrices de serialización
Procedimiento Fragmentación de datos serializados
Procedimiento para determinar si un objeto de .NET Standard es serializable
Serialización de SOAP y XML
Información general
Serialización XML en profundidad
Ejemplos
Herramienta de definición de esquemas XML
Control de la serialización XML mediante atributos
Atributos que controlan la serialización XML
Serialización XML con servicios web XML
Atributos que controlan la serialización SOAP codificada
Temas procedimentales
Serialización de un objeto
Deserialización de un objeto
Uso de la herramienta de definición de esquemas XML para generar clases y
documentos de esquema XML
Control de la serialización de clases derivadas
Especificación de un nombre de elemento alternativo para una secuencia XML
Calificación del elemento XML y los nombres del atributo XML
Serialización de un objeto como secuencia XML con codificación SOAP
Invalidación de la serialización XML SOAP codificada
Elementos de serialización XML
system.xml.serialization
dateTimeSerialization
schemaImporterExtensions
agregar elemento para schemaImporterExtensions
xmlSerializer
Herramientas
Herramienta Generador de serializador XML (Sgen.exe)
Herramienta Definición de esquemas XML (Xsd.exe)
E/S de archivos y secuencias
Información general
Formatos de ruta de acceso de archivo en los sistemas Windows
Tareas de E/S comunes
Procedimiento para copiar directorios
Procedimiento para enumerar directorios y archivos
Procedimiento para leer y escribir en un archivo de datos recién creado
Procedimiento para abrir y anexar a un archivo de registro
Procedimiento para escribir texto en un archivo
Procedimiento para leer texto de un archivo
Procedimiento para leer caracteres de una cadena
Procedimiento para escribir caracteres en una cadena
Procedimiento para agregar o quitar entradas de la lista de control de acceso
Procedimiento para comprimir y extraer archivos
Crear secuencias
Procedimiento para convertir flujos de .NET Framework en flujos de Windows
Runtime y viceversa
E/S de archivos asincrónica
Control de errores de E/S de disco
Almacenamiento aislado
Tipos de aislamiento
Procedimiento para obtener los almacenes de almacenamiento aislado
Procedimiento para enumerar los almacenes de almacenamiento aislado
Procedimiento para eliminar almacenes de almacenamiento aislado
Procedimiento para prever condiciones de espacio insuficiente con
almacenamiento aislado
Procedimiento para crear archivos y directorios en almacenamiento aislado
Procedimiento para buscar archivos y directorios existentes en almacenamiento
aislado
Procedimiento para leer y escribir en archivos en almacenamiento aislado
Procedimiento para eliminar archivos y directorios en almacenamiento aislado
Canalizaciones
Procedimiento para usar canalizaciones anónimas para la comunicación local entre
procesos
 Procedimiento para usar canalizaciones con nombre para la comunicación de red
entre procesos
Canalizaciones
Trabajo con búferes
Archivos asignados a memoria
Clase System.Console
Inserción de dependencias
Introducción
Usar la inserción de dependencias
Instrucciones para la inserción de dependencias
Configuración
Información general
Proveedores de configuración
Implementación de un proveedor de configuración personalizado
Patrón de opciones
Registro
Información general
Proveedores de registro
Implementación de un proveedor de registro personalizado
Registro de alto rendimiento
Formato de registro de la consola
HostBuilder (host genérico)
Acceso a datos
LINQ
Documentos y datos XML
Microsoft.Data.Sqlite
Entity Framework Core
Procesamiento paralelo, simultaneidad y asincronía
Información general
Programación asincrónica
Información general
Programación asincrónica en detalle
Patrones para la programación asincrónica
Programación en paralelo
Información general
Biblioteca de procesamiento paralelo basado en tareas (TPL)
Paralelismo de datos
Procedimiento para escribir un bucle Parallel.For simple
Procedimiento para escribir un bucle Parallel.ForEach sencillo
Procedimiento para escribir un bucle Parallel.For con variables locales de
subproceso
Procedimiento para escribir un bucle Parallel.ForEach con variables locales de
partición
Procedimiento para cancelar un bucle Parallel.For o ForEach
Procedimiento para controlar excepciones en bucles paralelos
Procedimiento para acelerar cuerpos de bucle pequeños
Procedimiento Iteración de directorios de archivos con la clase Parallel
Programación asincrónica basada en tareas
Encadenar tareas mediante tareas de continuación
Tareas secundarias asociadas y desasociadas
Cancelación de tareas
Control de excepciones
Procedimiento para usar Parallel.Invoke para ejecutar operaciones en paralelo
Procedimiento para devolver un valor a partir de una tarea
Procedimiento para cancelar una tarea y sus elementos secundarios
Procedimiento Creación de tareas precalculadas
Procedimiento para recorrer un árbol binario con tareas en paralelo
Procedimiento para desencapsular una tarea anidada
Procedimiento Evitar que una tarea secundaria se adjunte a su elemento primario
Flujo de datos
Procedimiento Escritura y lectura de mensajes en un bloque de flujo de datos
Procedimiento Implementación de un modelo de flujo de datos productor-
consumidor
Procedimiento Toma de medidas cuando un bloque de flujos de datos recibe
datos
Tutorial: Creación de una canalización de flujos de datos
 Procedimiento Desvinculación de bloques de flujos de datos
Tutorial: Uso de flujos de datos en aplicaciones de Windows Forms
Procedimiento para cancelar un bloque de flujo de datos
Tutorial: Creación de tipos de bloques de flujos de datos personalizados
Procedimiento Uso de JoinBlock para leer datos de diferentes orígenes
Procedimiento Especificación del grado de paralelismo en un bloque de flujos de
datos
Procedimiento para especificar un programador de tareas en un bloque de flujos
de datos
Tutorial: Uso de BatchBlock y BatchedJoinBlock para mejorar la eficacia
Uso de TPL con otros patrones asincrónicos
TPL y la programación asincrónica tradicional de .NET
Procedimiento para encapsular patrones de EAP en una tarea
Problemas potenciales en el paralelismo de datos y tareas
Parallel LINQ (PLINQ)
Introducción a PLINQ
Introducción a la velocidad en PLINQ
Conservar el orden en PLINQ
Opciones de fusión mediante combinación en PLINQ
Posibles problemas con PLINQ
Procedimiento para crear y ejecutar una consulta PLINQ simple
Procedimiento para controlar la ordenación en una consulta PLINQ
Procedimiento para combinar consultas LINQ paralelas y secuenciales
Procedimiento para controlar excepciones en una consulta PLINQ
Procedimiento para cancelar una consulta PLINQ
Procedimiento para escribir una función de agregado personalizada de PLINQ
Procedimiento para especificar el modo de ejecución en PLINQ
Procedimiento para especificar opciones de fusión mediante combinación en
PLINQ
Procedimiento para iterar directorios con PLINQ
Procedimiento para medir el rendimiento de consultas PLINQ
Ejemplo de datos de PLINQ
Estructuras de datos para la programación paralela
 Herramientas de diagnóstico paralelo
Particionadores personalizados para PLINQ y TPL
Información general
Procedimiento para implementar particiones dinámicas
Procedimiento para implementar un particionador para particionamiento estático
Expresiones lambda en PLINQ y TPL
Información adicional
Subprocesos
Pruebas
Información general
Procedimientos recomendados para pruebas unitarias
xUnit
Pruebas unitarias de C#
Pruebas unitarias de F#
Pruebas unitarias de VB
Organización de un proyecto y prueba con xUnit
NUnit
Pruebas unitarias de C#
Pruebas unitarias de F#
Pruebas unitarias de VB
MSTest
Pruebas unitarias de C#
Pruebas unitarias de F#
Pruebas unitarias de VB
Ejecución de pruebas unitarias selectivas
Ordenación de pruebas unitarias
Cobertura de código de prueba unitaria
Salida publicada de una prueba unitaria
Pruebas unitarias dinámicas de proyectos de .NET Core con Visual Studio
Seguridad
Temas avanzados
Rendimiento
 Administración de memoria
¿Qué es el "código administrado"?
Administración de memoria automática
Limpieza de recursos no administrados
Información general
Implementación de un método Dispose
Implementación de un método DisposeAsync
Uso de objetos que implementan IDisposable
Recolección de elementos no utilizados
Información general
Aspectos básicos
Estación de trabajo y GC de servidor
GC en segundo plano
El montón de objetos grandes
Recolección de elementos no utilizados y rendimiento
Recolecciones inducidas
Modos de latencia
Optimización de hospedaje web compartido
Notificaciones de recolección de elementos no utilizados
Supervisión de recursos de dominio de aplicación
Referencias parciales
Tipos relacionados con el intervalo y la memoria
Información general
Instrucciones de uso de Memory<T> y Span<T>
Tipos habilitados para SIMD
Interoperabilidad nativa
Información general
P/Invoke
Serialización de tipos
Personalización de la serialización de estructuras
Personalización de la serialización de parámetros
Guía de interoperabilidad
 Juegos de caracteres y serialización
Exposición de los componentes de .NET Core a COM
Hospedaje de .NET Core desde código nativo
Interoperabilidad COM
Información general
Contenedores COM
Información general
Contenedor al que se puede llamar en tiempo de ejecución
Contenedor CCW (COM callable wrapper)
Habilitación de tipos de .NET para la interoperabilidad COM
Aplicación de atributos de interoperabilidad
Excepciones
Empaquetado de distribución de .NET Core
Globalización y localización
Guía de la biblioteca de código abierto
Instrucciones de diseño de los marcos
Información general
Directrices de nomenclatura
Normas referentes al uso de minúsculas y mayúsculas
Convenciones generales de nomenclatura
Nombres de ensamblados y DLL
Nombres de espacios de nombres
Nombres de clases, estructuras e interfaces
Nombres de miembros de tipos
Asignación de nombres a parámetros
Asignación de nombres a recursos
Instrucciones de diseño de tipos
Elección entre clases y estructuras
Diseño de clases abstractas
Diseño de clases estáticas
Diseño de interfaces
Diseño de estructuras
 Diseño de enumeraciones
Tipos anidados
Instrucciones de diseño de miembros
Sobrecarga de miembros
Diseño de propiedades
Diseño de constructores
Diseño de eventos
Diseño de campos
Métodos de extensión
Sobrecargas de operadores
Diseño de parámetros
Diseño para la extensibilidad
Clases no selladas
Miembros protegidos
Eventos y devoluciones de llamadas
Miembros virtuales
Abstracciones (tipos e interfaces abstractos)
Clases base para la implementación de abstracciones
Sellar
Instrucciones de diseño de excepciones
Generación de excepciones
Uso de tipos de excepciones estándar
Excepciones y rendimiento
Instrucciones de uso
Matrices
Atributos
Colecciones
Serialización
Uso de System.Xml
Operadores de igualdad
Patrones de diseño comunes
Propiedades de dependencia
Guía de migración
Últimos cambios
Migración
.NET Core 2.0 a 2.1
Migración desde project.json
Asignación entre project.json y csproj
Cambios en la información general de la CLI
Migración desde DNX
Portabilidad de .NET Framework
Información general
Análisis de las dependencias de terceros
Portabilidad de las bibliotecas
Organización de proyectos para .NET Core
Tecnologías no disponibles
Herramientas
Uso del paquete de compatibilidad de Windows
Portabilidad de los proyectos de Windows Forms
Portabilidad de los proyectos de WPF
Portabilidad de los proyectos de C++/CLI
Selección entre .NET 5 y .NET Framework para aplicaciones de servidor
 Introducción a .NET
02/11/2020 • 2 minutes to read • Edit Online

En este artículo se enseña cómo crear y ejecutar una aplicación "Hola mundo" de .NET.
Si no está seguro de qué es .NET, comience con la Introducción a .NET.

Crear una aplicación

En primer lugar, descargue e instale el SDK de .NET en el equipo.
A continuación, abra un terminal como PowerShell , Símbolo del sistema o bash . Escriba los comandos dotnet
siguientes para crear y ejecutar una aplicación C#:

dotnet new console --output sample1

dotnet run --project sample1

Verá la salida siguiente:

Hello World!

Felicidades. Ha creado una sencilla aplicación .NET.

Pasos siguientes
Para comenzar a desarrollar aplicaciones .NET puede seguir un tutorial paso a paso, o bien ver los vídeos de
.NET 101 en YouTube.
 Tutoriales de introducción a .NET
18/12/2020 • 2 minutes to read • Edit Online

Los siguientes tutoriales paso a paso se ejecutan en Windows, Linux o macOS, salvo que se indique lo contrario.

Tutoriales para crear aplicaciones

Crear una aplicación de consola
mediante Visual Studio Code
mediante Visual Studio (Windows)
mediante Visual Studio para Mac (macOS)
Creación de una aplicación web
con la interfaz de usuario web del lado servidor
con la interfaz de usuario web del lado cliente
Creación de una API web
Creación de una aplicación web de llamada a procedimiento remoto
Creación de una aplicación web en tiempo real
Creación de una función sin servidor en la nube
Creación de una aplicación móvil para Android e iOS (Windows)
Creación de una aplicación de escritorio de Windows
WPF
Windows Forms
Plataforma universal de Windows (UWP)
Creación de un juego con Unity
Creación de un servicio de Windows

Tutoriales para crear bibliotecas de clases

Creación de una biblioteca de clases
mediante Visual Studio Code
mediante Visual Studio (Windows)
mediante Visual Studio para Mac (macOS)

Recursos de aprendizaje para lenguajes de .NET

Introducción a C#
Introducción a F#
Introducción a Visual Basic

Otros recursos de introducción

Los recursos siguientes permiten empezar a desarrollar aplicaciones .NET, pero no son tutoriales paso a paso:
Internet de las cosas (IoT)
Aprendizaje automático
Pasos siguientes
Para obtener más información sobre .NET, vea Introducción a .NET.
 Instalación de .NET en Windows
18/12/2020 • 18 minutes to read • Edit Online

En este artículo obtendrá información sobre cómo instalar .NET en Windows. .NET está formado por el entorno
de ejecución y el SDK. El entorno de ejecución se usa para ejecutar una aplicación de .NET, y puede o no incluirse
con la aplicación. El SDK se usa para crear aplicaciones y bibliotecas de .NET. El entorno de ejecución de .NET
siempre se instala con el SDK.
La versión más reciente de .NET es la 5.0.
DESCARGA DE
.NET

Versiones compatibles
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de
Windows en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llega al
fin del soporte técnico o la versión de Windows llega al final del ciclo de vida.
Las fechas de fin de servicio de Windows 10 están segmentadas por edición. En la tabla que hay a continuación
solo se tienen en cuenta las ediciones Home , Pro , Pro Education y Pro for Workstations . Para ver detalles
específicos, consulte la hoja informativa sobre el ciclo de vida de Windows.

TIP
Un símbolo + representa la versión mínima.

SIST EM A O P ERAT IVO . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5

Windows 10, versión 20H2 ️

✔ ️
✔ ️
✔

Windows 10, versión 2004 ️

✔ ️
✔ ️
✔

Windows 10, versión 1909 ️

✔ ️
✔ ️
✔

Windows 10, versión 1903 ️

✔ ️
✔ ️
✔

Windows 10, versión 1809 ️

✔ ️
✔ ️
✔

Windows 10, versión 1803 ️

✔ ️
✔ ️
✔

Windows 10, versión 1709 ️

✔ ️
✔ ️
✔

Windows 10, versión 1607 ️

✔ ️
✔ ️
✔

Windows 8.1 ️
✔ ️
✔ ️
✔

Windows 7 SP1 ESU ️

✔ ️
✔ ️
✔
 SIST EM A O P ERAT IVO . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5

Windows 10, versión 1607 ️

✔ ️
✔ ️
✔

Windows 10, versión 1607 ️

✔ ️
✔ ️
✔

Windows Server 2012 R2 ️

✔ ️
✔ ️
✔

Windows Server ️
✔ ️
✔ ️
✔
Core 2012 R2

Nano Server, versión 1809+ ️

✔ ️
✔ ️
✔

Nano Server, versión 1803 ️

✔ ️
✔ ❌

Versiones no admitidas
Las versiones siguientes de .NET ya ❌ no se admiten. Las descargas de estas siguen estando publicadas:
3.0
2.2
2.0

Información en tiempo de ejecución

El entorno de ejecución se usa para ejecutar aplicaciones creadas con .NET. Cuando un autor publica una
aplicación, puede incluir el tiempo de ejecución. Si no lo hace, el usuario elige si quiere instalar el tiempo de
ejecución.
Hay tres entornos de ejecución distintos que se pueden instalar en Windows:
Entorno de ejecución de ASP.NET Core
Ejecuta aplicaciones de ASP.NET Core. Incluye el entorno de ejecución de .NET.
Entorno de ejecución de escritorio
Ejecuta aplicaciones de escritorio WPF y Windows Forms de .NET para Windows. Incluye el entorno de ejecución
de .NET.
Entorno de ejecución de .NET
Este entorno de ejecución es el más sencillo y no incluye ningún otro. Se recomienda encarecidamente instalar el
entorno de ejecución de ASP.NET Core y el entorno de ejecución de escritorio para conseguir la mejor
compatibilidad con las aplicaciones de .NET.
D E S C A R G A D E L E N TO R N O D E E J E C U C I Ó N D E
.NET

Información del SDK

El SDK se usa para compilar y publicar aplicaciones y bibliotecas de .NET. La instalación del SDK incluye los tres
entornos de ejecución: el de ASP.NET Core, el de escritorio y el de .NET.

Dependencias
.NET 5.0
 .NET Core 3.1
.NET Core 3.0
.NET Core 2.2
.NET Core 2.1
Las versiones siguientes de Windows son compatibles con .NET 5.0:

NOTE
Un símbolo + representa la versión mínima.

SO VERSIÓ N A RQ UIT EC T URA S

Cliente de Windows 10 Versión 1607 y posteriores x64, x86, ARM64

Cliente Windows 7 SP1 y posteriores, y 8.1 x64, x86

Windows Server 2012 R2 y posteriores x64, x86

Windows Server Core 2012 R2 y posteriores x64, x86

Nano Server Versión 1809 y posteriores x64

Para obtener más información sobre los sistemas operativos compatibles con .NET 5.0, las distribuciones y la
directiva del ciclo de vida, vea Versiones de SO compatibles con .NET 5.0.
Windows 7 / Vista / 8.1 / Server 2008 R2 / Server 2012 R2
Se necesitan dependencias adicionales en caso de instalar el SDK o el entorno de ejecución de .NET en las
versiones siguientes de Windows:
Windows 7 SP1 ESU
Windows Vista SP2
Windows 8.1
Windows Server 2008 R2
Windows Server 2012 R2
Instale el software siguiente:
Microsoft Visual C++ 2015 Redistributable Update 3.
KB2533623
Los requisitos anteriores también son necesarios si se encuentra con uno de los errores siguientes:

El programa no se puede iniciar porque el archivo api-ms-win-crt-runtime-l1-1-0.dll falta en el equipo.

Intente volver a instalar el programa para corregir este problema.
-o-
El programa no se puede iniciar porque falta el archivo api-ms-win-cor-timezone-l1-1-0.dll en el equipo.
Intente volver a instalar el programa para corregir este problema.
-o-
La biblioteca hostfxr.dll se ha encontrado, pero no se ha podido cargar desde C:\<path_to_app>\hostfxr.dll.
Instalación mediante la automatización de PowerShell
Los scripts de dotnet-install se usan para la automatización de CI y las instalaciones que no son de administrador
del entorno de ejecución. Se puede descargar el script desde la página de referencia del script dotnet-install.
El valor predeterminado del script es instalar la versión más reciente de soporte técnico a largo plazo (LTS), que
actualmente es .NET Core 3.1. Puede elegir una versión concreta especificando el modificador Channel . Incluya el
modificador Runtime para instalar un entorno de ejecución. De lo contrario, el script instala el SDK.

dotnet-install.ps1 -Channel 5.0 -Runtime aspnetcore

Instale el SDK omitiendo el modificador -Runtime . El modificador -Channel de este ejemplo está establecido en
Current , con lo que se instala la versión admitida más reciente.

dotnet-install.ps1 -Channel Current

Instalación con Visual Studio

Si usa Visual Studio para desarrollar aplicaciones de .NET, en la tabla siguiente se describe la versión mínima
necesaria de Visual Studio, en función de la versión del SDK de .NET de destino.

VERSIÓ N DE SDK DE . N ET VERSIÓ N DE VISUA L ST UDIO

5.0 Visual Studio 2019, versión 16.8 o posterior.

3.1 Visual Studio 2019, versión 16.4 o posterior.

3.0 Visual Studio 2019, versión 16.3 o posterior.

2.2 Visual Studio 2017, versión 15.9 o posterior.

2.1 Visual Studio 2017, versión 15.7 o posterior.

Si ya tiene Visual Studio instalado, puede comprobar la versión siguiendo los pasos que se detallan a
continuación.
1. Abra Visual Studio.
2. Seleccione Ayuda > Acerca de Microsoft Visual Studio .
3. Lea el número de versión en el cuadro de diálogo Acerca de .
Visual Studio puede instalar el SDK y el entorno de ejecución de .NET más recientes.
DESCARGUE .
V IS U A L S TU D IO

Selección de una carga de trabajo

Al instalar o modificar Visual Studio, seleccione una de las cargas de trabajo siguientes o más, en función del tipo
de aplicación que quiera compilar:
La carga de trabajo Desarrollo multiplataforma de .NET Core en la sección Otros conjuntos de
herramientas .
La carga de trabajo Desarrollo de ASP.NET y web en la sección Web y nube .
La carga de trabajo Desarrollo de Azure en la sección Web y nube .
 La carga de trabajo Desarrollo de escritorio de .NET en la sección Móviles y de escritorio .

Instalación junto con Visual Studio Code

Visual Studio Code es un editor de código fuente ligero y eficaz que se ejecuta en el escritorio. Visual Studio Code
está disponible para Windows, macOS y Linux.
Aunque Visual Studio Code no viene con un instalador automatizado de .NET Core como Visual Studio, agregar
compatibilidad con .NET Core es sencillo.
1. Descargue e instale Visual Studio Code.
2. Descargue e instale el SDK de .NET Core.
3. Instale la extensión de C# desde el Marketplace de Visual Studio Code.

Windows Installer
La página de descarga de .NET proporciona ejecutables de Windows Installer.
Al usar los archivos MSI para instalar .NET, puede personalizar la ruta de instalación estableciendo los
parámetros DOTNETHOME_X64 y DOTNETHOME_X86 :

dotnet-sdk-3.1.301-win-x64.exe DOTNETHOME_X64="F:\dotnet\x64" DOTNETHOME_X86="F:\dotnet\x86"

Descarga e instalación de forma manual

Como alternativa a los instaladores de Windows para .NET, puede descargar e instalar manualmente el SDK o el
entorno de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua.
Para un desarrollador o usuario, generalmente es mejor usar un instalador.
Tanto el SDK como el entorno de ejecución de .NET se pueden instalar manualmente una vez que se han
descargado. Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer
lugar, descargue una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
Descargas de .NET 5.0
Descargas de .NET Core 3.1
Descargas de .NET Core 2.1
Todas las descargas de .NET Core
Cree un directorio en el que se extraerá .NET; por ejemplo, %USERPROFILE%\dotnet . Después, extraiga el archivo ZIP
descargado en ese directorio.
De forma predeterminada, los comandos y las aplicaciones de la CLI de .NET no usarán la versión de .NET
instalada de esta manera y debe elegir explícitamente usarla. Para ello, cambie las variables de entorno con las
que se inicia una aplicación:

set DOTNET_ROOT=%USERPROFILE%\dotnet
set PATH=%USERPROFILE%\dotnet;%PATH%
set DOTNET_MULTILEVEL_LOOKUP=0

Este enfoque permite instalar varias versiones en ubicaciones independientes y elegir explícitamente qué
ubicación de instalación debe usar una aplicación mediante la ejecución de la aplicación con variables de entorno
que apuntan a esa ubicación.
Cuando DOTNET_MULTILEVEL_LOOKUP se establece en 0 , .NET ignora cualquier versión de .NET instalada de forma
global. Elimine esa configuración de entorno para que .NET tenga en cuenta la ubicación de instalación global
predeterminada al seleccionar el mejor marco para ejecutar la aplicación. La ubicación predeterminada suele ser
C:\Program Files\dotnet , en la que los instaladores instalan .NET.

Docker
Los contenedores proporcionan una manera ligera de aislar la aplicación del resto del sistema host. Los
contenedores de la misma máquina comparten solo el kernel y usan los recursos proporcionados a la aplicación.
.NET se puede ejecutar en un contenedor de Docker. Las imágenes oficiales de Docker en .NET se publican en el
registro de contenedor de Microsoft (MCR) y se pueden encontrar en el repositorio de Docker Hub para
Microsoft .NET. Cada repositorio contiene imágenes para diferentes combinaciones de .NET (SDK o Runtime) y
del sistema operativo que puede usar.
Microsoft ofrece imágenes que se adaptan a escenarios específicos. Por ejemplo, el repositorio de ASP.NET Core
proporciona imágenes que se compilan para ejecutar aplicaciones de ASP.NET Core en producción.
Para obtener más información sobre el uso de .NET en un contenedor de Docker, vea Introducción a .NET y
Docker y Ejemplos.

Pasos siguientes
Procedimiento para comprobar que .NET ya está instalado.
Tutorial: Tutorial Hola mundo.
Tutorial: Creación de una aplicación con Visual Studio Code.
Tutorial: Inclusión de una aplicación de .NET Core en un contenedor.
 Instalación de .NET en macOS
18/12/2020 • 14 minutes to read • Edit Online

En este artículo obtendrá información sobre cómo instalar .NET en macOS. .NET está formado por el entorno de
ejecución y el SDK. El entorno de ejecución se usa para ejecutar una aplicación de .NET, y puede o no incluirse con
la aplicación. El SDK se usa para crear aplicaciones y bibliotecas de .NET. El entorno de ejecución de .NET siempre
se instala con el SDK.
La versión más reciente de .NET es la 5.0.
DESCARGAR .NET
CORE

Versiones compatibles
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de macOS
que se admiten. Estas versiones se siguen admitiendo hasta que la versión de .NET alcance la finalización del
soporte técnico.
Con la marca ✔
️ se indica que la versión de .NET Core se sigue admitiendo.
Con la marca ❌ se indica que la versión de .NET Core no se admite.

SIST EM A O P ERAT IVO . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

macOS 11.0 "Big Sur" ️ 2.1 (Notas de la versión)

✔ ️ 3.1 (Notas de la versión)
✔ ️ 5.0 (notas de la versión)
✔

macOS 10.15 "Catalina" ️ 2.1 (Notas de la versión)

✔ ️ 3.1 (Notas de la versión)
✔ ️ 5.0 (notas de la versión)
✔

macOS 10.14 "Mojave" ️ 2.1 (Notas de la versión)

✔ ️ 3.1 (Notas de la versión)
✔ ️ 5.0 (notas de la versión)
✔

macOS 10.13 "High Sierra" ️ 2.1 (Notas de la versión)

✔ ️ 3.1 (Notas de la versión)
✔ ️ 5.0 (notas de la versión)
✔

macOS 10.12 "Sierra" ️ 2.1 (Notas de la versión)

✔ ❌ 3.1 (Notas de la versión) ❌ 5.0 (notas de la versión)

Versiones no admitidas
Las versiones siguientes de .NET ya ❌ no se admiten. aunque sus descargas siguen estando publicadas:
3.0 (Notas de la versión)
2.2 (Notas de la versión)
2.0 (Notas de la versión)

Información en tiempo de ejecución

El entorno de ejecución se usa para ejecutar aplicaciones creadas con .NET. Cuando un autor publica una
aplicación, puede incluir el tiempo de ejecución. Si no lo hace, el usuario elige si quiere instalar el tiempo de
ejecución.
Hay tres tiempos de ejecución distintos que se pueden instalar en macOS:
Entorno de ejecución de ASP.NET Core
Ejecuta aplicaciones de ASP.NET Core. Incluye el entorno de ejecución de .NET.
Entorno de ejecución de .NET
Este entorno de ejecución es el más sencillo y no incluye ningún otro. Se recomienda encarecidamente instalar el
entorno de ejecución de ASP.NET Core para conseguir la mejor compatibilidad con las aplicaciones de .NET.
D E S C A R G A D E L E N TO R N O D E E J E C U C I Ó N D E
.NET

Información del SDK

El SDK se usa para compilar y publicar aplicaciones y bibliotecas de .NET. La instalación del SDK incluye ambos
entornos de ejecución: ASP.NET Core y .NET.

Dependencias
.NET es compatible con las versiones siguientes de macOS:

NOTE
Un símbolo + representa la versión mínima.

VERSIÓ N DE . N ET C O RE MAC OS A RQ UIT EC T URA S M Á S IN F O RM A C IÓ N

5.0 High Sierra (10.13 y x64 Más información

posteriores)

3.1 High Sierra (10.13 y x64 Más información

posteriores)

3.0 High Sierra (10.13 y x64 Más información

posteriores)

2.2 Sierra (10.12 y posteriores) x64 Más información

2.1 Sierra (10.12 y posteriores) x64 Más información

A partir de macOS Catalina (versión 10.15), se debe conceder la certificación a todo el software creado después
del 1 de junio de 2019 que se distribuye con el identificador de desarrollador. Este requisito se aplica al entorno
de ejecución de .NET, al SDK de .NET y al software creado con .NET.
Desde el 18 de febrero de 2020, se ha concedido la certificación a los instaladores del entorno de ejecución y el
SDK de .NET 5.0 y .NET Core 3.1, 3.0 y 2.1. A las versiones publicadas anteriores no se les ha concedido la
certificación. Si ejecuta una aplicación sin certificación, verá un error similar al de la imagen siguiente:
Para obtener más información sobre cómo afecta la certificación forzada a .NET (y a las aplicaciones de .NET), vea
Trabajo con la certificación de macOS Catalina.

libgdiplus
Para las aplicaciones de .NET en las que se usa el ensamblado System.Drawing.Common es necesario instalar
libgdiplus.
Una manera fácil de obtener libgdiplus es usar el administrador de paquetes Homebrew ("brew") para macOS.
Después de instalar brew , instale libgdiplus mediante la ejecución de los comandos siguientes en un símbolo del
sistema de Terminal (comando):

brew update
brew install mono-libgdiplus

Instalación mediante un instalador

macOS tiene instaladores independientes que se pueden usar para instalar el SDK de .NET 5.0:
CPU de x64 (64 bits)

Descarga e instalación de forma manual

Como alternativa a los instaladores de macOS para .NET, puede descargar e instalar manualmente el SDK y el
entorno de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua.
Para un desarrollador o usuario, generalmente es mejor usar un instalador.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes
comandos desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de
lo que haya descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-osx-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-osx-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos
disponibles para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Instalación con Visual Studio para Mac

Visual Studio para Mac instala el SDK de .NET cuando se selecciona la carga de trabajo .NET . Para empezar con el
desarrollo en .NET en macOS, vea Instalación de Visual Studio 2019 para Mac.

VERSIÓ N DE SDK DE . N ET VERSIÓ N DE VISUA L ST UDIO

5.0 Visual Studio 2019 para Mac, versión 8.8 o posterior.

3.1 Visual Studio 2019 para Mac, versión 8.4 o posterior.

2.1 Visual Studio 2019 para Mac, versión 8.0 o posterior.

Instalación junto con Visual Studio Code
Visual Studio Code es un editor de código fuente ligero y eficaz que se ejecuta en el escritorio. Visual Studio Code
está disponible para Windows, macOS y Linux.
Aunque Visual Studio Code no incluye un instalador automatizado de .NET como Visual Studio, resulta sencillo
agregar compatibilidad con .NET.
1. Descargue e instale Visual Studio Code.
2. Descargue e instale el SDK de .NET.
3. Instale la extensión de C# desde el Marketplace de Visual Studio Code.

Instalación mediante la automatización de Bash

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
entorno de ejecución. Se puede descargar el script desde la página de referencia del script dotnet-install.
El valor predeterminado del script es instalar la versión más reciente de soporte técnico a largo plazo (LTS), que
actualmente es .NET Core 3.1. Puede elegir una versión concreta especificando el modificador current . Incluya el
modificador runtime para instalar un entorno de ejecución. De lo contrario, el script instala el SDK.

./dotnet-install.sh --channel 5.0 --runtime aspnetcore

NOTE
El comando anterior instala el entorno de ejecución de ASP.NET Core para obtener la máxima compatibilidad. El entorno de
ejecución de ASP.NET Core también incluye el estándar de .NET.
Docker
Los contenedores proporcionan una manera ligera de aislar la aplicación del resto del sistema host. Los
contenedores de la misma máquina comparten solo el kernel y usan los recursos proporcionados a la aplicación.
.NET se puede ejecutar en un contenedor de Docker. Las imágenes oficiales de Docker en .NET se publican en el
registro de contenedor de Microsoft (MCR) y se pueden encontrar en el repositorio de Docker Hub para
Microsoft .NET Core. Cada repositorio contiene imágenes para diferentes combinaciones de .NET (SDK o Runtime)
y del sistema operativo que puede usar.
Microsoft ofrece imágenes que se adaptan a escenarios específicos. Por ejemplo, el repositorio de ASP.NET Core
proporciona imágenes que se compilan para ejecutar aplicaciones de ASP.NET Core en producción.
Para obtener más información sobre el uso de .NET Core en un contenedor de Docker, vea Introducción a .NET y
Docker y Ejemplos.

Pasos siguientes
Cómo comprobar que .NET Core ya está instalado.
Trabajo con la certificación de macOS Catalina.
Tutorial: Introducción a macOS.
Tutorial: Creación de una aplicación con Visual Studio Code.
Tutorial: Inclusión de una aplicación de .NET Core en un contenedor.
 Instalación de .NET en Linux
18/12/2020 • 13 minutes to read • Edit Online

.NET está disponible en diferentes distribuciones de Linux. La mayoría de las plataformas y distribuciones de
Linux tienen una versión principal cada año, y la mayoría proporcionan un administrador de paquetes que se
usa para instalar .NET. En este artículo se describe lo que se admite actualmente y el administrador de
paquetes que se usa.
El resto de este artículo es un desglose de cada una de las principales distribuciones de Linux que admite .NET.
Todas las versiones de .NET siguen siendo compatibles hasta que la versión de .NET llega al fin del soporte
técnico o la distribución de Linux llega al final del ciclo de vida.
Para conseguir la mejor compatibilidad, elija una versión de lanzamiento a largo plazo (LTS).

Versiones no admitidas
Las versiones siguientes de .NET ya ❌ no se admiten. Las descargas de estas siguen estando publicadas:
3.0
2.2
2.0
Estas versiones no admitidas no se detallan en las secciones siguientes y los resultados pueden variar si
intenta instalarlas.

Alpine
No hay instaladores para Alpine. Debe usar el script de instalación o seguir las instrucciones de instalación
manual.
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de
Alpine en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llega al
fin del soporte técnico o la versión de Alpine llega al final del ciclo de vida.
El símbolo ✔
️ indica que todavía se admite la versión de Alpine o de .NET.
El símbolo ❌ indica que la versión de Alpine o de .NET no se admite en esa versión de Alpine.
Si una versión de Alpine y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema
operativo y .NET se admite.

A L P IN E . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 3.12
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 3.11
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 3.10
✔ ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 3.9 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 3.8 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0
Para obtener más información, vea Instalación de .NET en Alpine.

CentOS
CentOS 7 usa Yum como administrador de paquetes y CentOS 8 emplea DNF.
En la tabla siguiente se muestra una lista de las versiones de .NET admitidas actualmente en CentOS 7 y
CentOS 8. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte
técnico o ya no se admita la versión de CentOS.

C EN TO S . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 8
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 7
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Para obtener más información, vea Instalación de .NET en CentOS.

Debian
Debian usa APT (herramienta avanzada de paquetes) como administrador de paquetes.
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de
Debian en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue
al final del soporte técnico o la versión de Debian llegue al final del ciclo de vida.
El símbolo ✔
️ indica que todavía se admite la versión de Debian o de .NET.
El símbolo ❌ indica que la versión de Debian o de .NET no se admite en esa versión de Debian.
Si una versión de Debian y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema
operativo y .NET se admite.

DEB IA N . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 10
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 9
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌8 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

Para obtener más información, vea Instalación de .NET en Debian.

Fedora
Fedora usa DNF como administrador de paquetes.
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de
Fedora en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al
final del soporte técnico o la versión de Fedora llegue al final del ciclo de vida.
El símbolo ✔
️ indica que todavía se admite la versión de Fedora o de .NET.
El símbolo ❌ indica que la versión de Fedora o de .NET no se admite en esa versión de Fedora.
Si una versión de Fedora y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema
operativo y .NET se admite.
 F EDO RA . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 33
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 32
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 31 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 30 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 29 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 28 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

❌ 27 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

Para obtener más información, vea Instalación de .NET en Fedora.

openSUSE
openSUSE usa zypper como administrador de paquetes.
En la tabla siguiente se muestra una lista de las versiones de .NET compatibles actualmente con openSUSE 15.
Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte técnico o ya
no se admita la versión de openSUSE.

O P EN SUSE . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 15
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Para obtener más información, vea Instalación de .NET en openSUSE.

Red Hat
Red Hat Enterprise Linux (RHEL) usa yum (RHEL 7) y DNF (RHEL 8) como administrador de paquetes.
En la tabla siguiente se muestra una lista de las versiones de .NET compatibles actualmente con RHEL 7 y
RHEL 8. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte
técnico o ya no se admita la versión de RHEL.
El símbolo ✔
️ indica que todavía se admite la versión de RHEL o de .NET.
El símbolo ❌ indica que la versión de RHEL o de .NET no se admite en esa versión de RHEL.
Si una versión de RHEL y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo
y .NET se admite.

RH EL . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 8
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 7
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Para obtener más información, vea Instalación de .NET en RHEL.

SLES
SLES usa zypper como administrador de paquetes.
En la tabla siguiente se muestra una lista de las versiones de .NET compatibles actualmente en SLES 12 SP2 y
SLES 15. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte
técnico o ya no se admita la versión de SLES.
El símbolo ✔
️ indica que todavía se admite la versión de SLES o de .NET.
El símbolo ❌ indica que la versión de SLES o de .NET no se admite en esa versión de SLES.
Si una versión de SLES y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo
y .NET se admite.

SL ES . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 15
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 12 SP2
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Para obtener más información, vea Instalación de .NET en SLES.

Ubuntu
Ubuntu usa APT (herramienta avanzada de paquetes) como administrador de paquetes.
En la tabla siguiente se representa el estado de compatibilidad de Ubuntu y .NET.
El símbolo ✔
️ indica que todavía se admite la versión de Ubuntu o de .NET.
El símbolo ❌ indica que la versión de Ubuntu o de .NET no se admite en esa versión de Ubuntu.
Si una versión de Ubuntu y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema
operativo y .NET se admite.

UB UN T U . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 20.10
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 20.04 (LTS)
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 19.10 ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 19.04 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 18.10 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

️ 18.04 (LTS)
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 17.10 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

❌ 17.04 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

❌ 16.10 ❌ 2.1 ❌ 3.1 ❌ 5.0

️ 16.04 (LTS)
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔
Para obtener más información, vea Instalación de .NET en Ubuntu.

Pasos siguientes
Procedimiento para comprobar que .NET ya está instalado.
Tutorial: Creación de una aplicación con Visual Studio Code.
Tutorial: Inclusión de una aplicación de .NET en un contenedor.
 Instalación del SDK y el entorno de ejecución de
.NET en Ubuntu
18/12/2020 • 44 minutes to read • Edit Online

.NET es compatible con Ubuntu. En este artículo se describe cómo instalar .NET en Ubuntu. Cuando una versión de
Ubuntu no es compatible, .NET deja de ser compatible con esa versión. Pero estas instrucciones pueden ayudarle a
conseguir que .NET se ejecute en esas versiones, aunque no se admita.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo necesita
ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se recomienda
instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de Ubuntu
en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al fin del
soporte técnico o la versión de Ubuntu llegue al final del ciclo de vida.
El símbolo ✔
️ indica que todavía se admite la versión de Ubuntu o de .NET.
El símbolo ❌ indica que la versión de Ubuntu o de .NET no se admite en esa versión de Ubuntu.
Si una versión de Ubuntu y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo y
.NET se admite.

UB UN T U . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 20.10
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 20.04 (LTS)
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 19.10 ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 19.04 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 18.10 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

️ 18.04 (LTS)
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 17.10 ️ 2.1
✔ ❌ 3.1 ❌ 5.0
 UB UN T U . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

❌ 17.04 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

❌ 16.10 ❌ 2.1 ❌ 3.1 ❌ 5.0

️ 16.04 (LTS)
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Las versiones siguientes de .NET ya no se admiten. Las descargas de estas siguen estando publicadas:
3.0
2.2
2.0

Eliminación de versiones preliminares

Cuando se usa un administrador de paquetes para administrar la instalación de .NET, es posible que se produzca
un conflicto si previamente se ha instalado una versión preliminar. El administrador de paquetes puede interpretar
la versión que no es preliminar como una versión anterior de .NET. Para instalar la versión que no es preliminar,
desinstale primero las versiones preliminares. Para obtener más información sobre cómo desinstalar .NET, vea
Procedimiento para quitar el entorno de ejecución y el SDK de .NET.

Procedimiento para instalar otras versiones

Los paquetes agregados a las fuentes del administrador de paquetes se denominan con un formato susceptible de
intrusiones: {product}-{type}-{version} .
product
Tipo de producto .NET que se va a instalar. Las opciones válidas son:
dotnet
aspnetcore
type
Elige el SDK o el entorno de ejecución. Las opciones válidas son:
sdk
motor en tiempo de ejecución
version
Versión del SDK o del entorno de ejecución que se va a instalar. En este artículo se proporcionarán siempre
las instrucciones para la última versión admitida. Las opciones válidas son cualquier versión de lanzamiento,
como las siguientes:
5.0
3.1
3.0
2.1
Es posible que el SDK o el entorno de ejecución que intenta descargar no esté disponible para su
distribución de Linux. Para obtener una lista de las distribuciones admitidas, consulte Dependencias y
requisitos de .NET Core.
Ejemplos
Instalación del entorno de ejecución de ASP.NET Core 5.0: aspnetcore-runtime-5.0
Instalación del entorno de ejecución de ASP.NET Core 2.1: dotnet-runtime-2.1
 Instalación del SDK de .NET 5.0: dotnet-sdk-5.0
Instalación del SDK de .NET Core 3.1: dotnet-sdk-3.1
Falta el paquete
Si la combinación de paquete y versión no funciona, no está disponible. Por ejemplo, no hay un SDK de ASP.NET
Core; los componentes del SDK se incluyen en el SDK de .NET. El valor aspnetcore-sdk-2.2 es no es correcto y debe
ser dotnet-sdk-2.2 . Para obtener una lista de las distribuciones de Linux compatibles con .NET, vea Dependencias
y requisitos de .NET.

20.10 ✔
️
IMPORTANT
.NET Core 2.1 todavía no está disponible en la fuente de paquetes.

La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/20.10/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-5.0 , vea la sección Solución de
problemas de APT.

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-5.0
 IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-5.0 , vea la sección
Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo apt-get install -y dotnet-runtime-5.0

20.04 ✔
️
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-5.0 , vea la sección Solución de
problemas de APT.

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-5.0 , vea la sección
Solución de problemas de APT.
Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo apt-get install -y dotnet-runtime-5.0

19.10 ❌
❌ Tenga en cuenta que ya no se admite esta versión de Ubuntu.
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/19.10/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-3.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-3.1 , consulte la sección Solución
de problemas de APT.

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-3.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-3.1 , consulte la
sección Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-3.1 por dotnet-runtime-3.1 .
 sudo apt-get install -y dotnet-runtime-3.1

19.04 ❌
❌ Tenga en cuenta que ya no se admite esta versión de Ubuntu.
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/19.04/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-3.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-3.1 , consulte la sección Solución
de problemas de APT.

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-3.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-3.1 , consulte la
sección Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-3.1 por dotnet-runtime-3.1 .

sudo apt-get install -y dotnet-runtime-3.1

18.10 ❌
❌ Tenga en cuenta que ya no se admite esta versión de Ubuntu.
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/18.10/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-2.1 , consulte la sección Solución
de problemas de APT.

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-2.1 , consulte la
sección Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-2.1 por dotnet-runtime-2.1 .

sudo apt-get install -y dotnet-runtime-2.1

18.04 ✔
️
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-5.0 , vea la sección Solución de
problemas de APT.

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-5.0 , vea la sección
Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo apt-get install -y dotnet-runtime-5.0

17.10 ❌
❌ Tenga en cuenta que ya no se admite esta versión de Ubuntu.
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/17.10/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-2.1 , consulte la sección Solución
de problemas de APT.

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-2.1 , consulte la
sección Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-2.1 por dotnet-runtime-2.1 .

sudo apt-get install -y dotnet-runtime-2.1

17.04 ❌
❌ Tenga en cuenta que ya no se admite esta versión de Ubuntu.
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:
 wget https://packages.microsoft.com/config/ubuntu/17.04/packages-microsoft-prod.deb -O packages-microsoft-
prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-2.1 , consulte la sección Solución
de problemas de APT.

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-2.1 , consulte la
sección Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-2.1 por dotnet-runtime-2.1 .

sudo apt-get install -y dotnet-runtime-2.1

16.10 ❌
❌ Tenga en cuenta que ya no se admite esta versión de Ubuntu.
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:
 wget https://packages.microsoft.com/config/ubuntu/16.10/packages-microsoft-prod.deb -O packages-microsoft-
prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-2.1 , consulte la sección Solución
de problemas de APT.

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-2.1 , consulte la
sección Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-2.1 por dotnet-runtime-2.1 .

sudo apt-get install -y dotnet-runtime-2.1

16.04 ✔
️
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:

wget https://packages.microsoft.com/config/ubuntu/16.04/packages-microsoft-prod.deb -O packages-microsoft-

prod.deb
sudo dpkg -i packages-microsoft-prod.deb
Instalación del SDK
El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-5.0 , vea la sección Solución de
problemas de APT.

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-5.0 , vea la sección
Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo apt-get install -y dotnet-runtime-5.0

SDK o entorno de ejecución de actualización de APT

Cuando hay disponible una nueva versión de revisión para .NET, basta con actualizarla mediante APT con los
comandos siguientes:

sudo apt-get update

sudo apt-get upgrade

Solución de problemas de APT

En esta sección se proporciona información sobre los errores comunes que puede recibir al usar APT para instalar
.NET.
No se puede encontrar el paquete
 IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

No se puede encontrar el paquete \ No se han podido instalar algunos paquetes

Si recibe un mensaje de error similar a No se puede encontrar el paquete {dotnet-package} o No se han
podido instalar algunos paquetes , ejecute los comandos siguientes.
Hay dos marcadores de posición en el siguiente conjunto de comandos.
{dotnet-package}
Representa el paquete de .NET que va a instalar, como aspnetcore-runtime-3.1 . Se usa en el comando
sudo apt-get install siguiente.

{os-version}
Representa la versión de Linux en la que está. Se usa en el comando wget siguiente.

Primero, pruebe a purgar la lista de paquetes:

sudo dpkg --purge packages-microsoft-prod && sudo dpkg -i packages-microsoft-prod.deb

sudo apt-get update

Después, intente volver a instalar .NET. Si eso no funciona, puede ejecutar una instalación manual con los
comandos siguientes:

sudo apt-get install -y gpg

wget -O - https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget https://packages.microsoft.com/config/ubuntu/{os-version}/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list
sudo apt-get update; \
sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y {dotnet-package}

No se pudo capturar el elemento

Al instalar el paquete de .NET, puede ver un error similar a
Failed to fetch ... File has unexpected size ... Mirror sync in progress? . Este error podría significar que la
fuente de paquetes de .NET se está actualizando con versiones de paquetes más recientes y que debe volver a
intentarlo más tarde. Durante una actualización, la falta de disponibilidad de la fuente de paquetes no debe ser
superior a 30 minutos. Si recibe este error continuamente durante más de 30 minutos, abra una incidencia en
https://github.com/dotnet/core/issues.

Snap
.NET Core está disponible desde el almacén de snaps.
Un snap es una agrupación de una aplicación y sus dependencias que funcionan sin modificaciones en muchas
distribuciones de Linux diferentes. Los snaps se reconocen y se instalan desde el almacén de snaps. Para más
información sobre Snap, consulte Introducción a Snap.
Solo las versiones admitidas de .NET Core están disponibles mediante Snap.
Instalación del SDK
Los paquetes Snap para el SDK de .NET se publican con el mismo identificador: dotnet-sdk . Se puede instalar una
versión específica del SDK mediante la especificación del canal. El SDK incluye el entorno de ejecución
correspondiente. En la tabla siguiente se enumeran los canales:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 5.0 o latest/stable

3.1 (LTS) 3.1 o lts/stable

2.1 (LTS) 2.1

Use el comando snap install para instalar un paquete Snap del SDK de .NET. Use el parámetro --channel para
indicar qué versión se va a instalar. Si se omite este parámetro, se usa latest/stable . En este ejemplo, se
especifica 5.0 :

sudo snap install dotnet-sdk --classic --channel=5.0

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-sdk.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-sdk.dotnet dotnet50 . Cuando use el comando dotnet50 , invocará
esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los tutoriales y
ejemplos, donde se espera que esté disponible un comando dotnet .
Instalación de la instancia en tiempo de ejecución
Los paquetes Snap de .NET Core Runtime se publican con su propio identificador de paquete. En la tabla siguiente
se muestra una lista de los identificadores de paquete:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 dotnet-runtime-50

3.1 (LTS) dotnet-runtime-31

3.0 dotnet-runtime-30

2.2 dotnet-runtime-22

2.1 (LTS) dotnet-runtime-21

Use el comando snap install para instalar un paquete Snap del entorno de ejecución de .NET. En este ejemplo, se
instala .NET 5.0:

sudo snap install dotnet-runtime-50 --classic

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-runtime-50.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-runtime-50.dotnet dotnet50 . Cuando use el comando dotnet50 ,
invocará esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los
tutoriales y ejemplos, donde se espera que esté disponible un comando dotnet .
Errores de certificado SSL
Cuando .NET se instala mediante Snap, es posible que en algunas distribuciones no se encuentren los certificados
SSL de .NET y que reciba un error similar al siguiente durante la acción restore :

Processing post-creation actions...

Running 'dotnet restore' on /home/myhome/test/test.csproj...
Restoring packages for /home/myhome/test/test.csproj...
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : Unable to load the service index for source
https://api.nuget.org/v3/index.json. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The SSL connection could not be established,
see inner exception. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The remote certificate is invalid according to
the validation procedure. [/home/myhome/test/test.csproj]

Para resolver este problema, establezca algunas variables de entorno:

export SSL_CERT_FILE=[path-to-certificate-file]
export SSL_CERT_DIR=/dev/null

La ubicación del certificado variará en función de la distribución. Estas son las ubicaciones de las distribuciones en
las que hemos experimentado el problema.
Fedora: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
OpenSUSE: /etc/ssl/ca-bundle.pem
Solus: /etc/ssl/certs/ca-certificates.crt

Dependencias
Al realizar la instalación con un administrador de paquetes, estas bibliotecas se instalan automáticamente. Pero si
instala manualmente .NET o publica una aplicación independiente, deberá asegurarse de que estas bibliotecas
estén instaladas:
libc6
libgcc1
libgssapi-krb5-2
libicu52 (para 14.x)
libicu55 (para 16.x)
libicu60 (para 18.x)
libicu66 (para 20.x)
libssl1.0.0 (para 14.x, 16.x)
libssl1.1 (para 18.x, 20.x)
libstdc++6
 zlib1g
Para las aplicaciones de .NET en las que se usa el ensamblado System.Drawing.Common, también se necesita la
dependencia siguiente:
libgdiplus (versión 6.0.1 o posteriores)

WARNING
Puede instalar una versión reciente de libgdiplus agregando el repositorio Mono al sistema. Para obtener más
información, vea https://www.mono-project.com/download/stable/.

Instalación con script

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use el
parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0

Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el entorno
de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o en
distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes comandos
desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de lo que haya
descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos disponibles
para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Instalación del SDK y el entorno de ejecución de
.NET en Alpine
18/12/2020 • 8 minutes to read • Edit Online

En este artículo se describe cómo instalar .NET en Alpine. Cuando una versión de Alpine no es compatible, .NET
deja de ser compatible con esa versión. Pero estas instrucciones pueden ayudarle a conseguir que .NET se
ejecute en esas versiones, aunque no se admita.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo
necesita ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se
recomienda instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.
No hay instaladores para Alpine. Debe usar el script de instalación o seguir las instrucciones de instalación
manual.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de
Alpine en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llega al fin
del soporte técnico o la versión de Alpine llega al final del ciclo de vida.
El símbolo ✔
️ indica que todavía se admite la versión de Alpine o de .NET.
El símbolo ❌ indica que la versión de Alpine o de .NET no se admite en esa versión de Alpine.
Si una versión de Alpine y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo
y .NET se admite.

A L P IN E . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 3.12
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 3.11
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 3.10
✔ ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 3.9 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 3.8 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

Las versiones siguientes de .NET ya no se admiten. aunque sus descargas siguen estando publicadas:
3.0
2.2
2.0

Dependencias
Para .NET en Alpine Linux es necesario que estén instaladas las dependencias siguientes:
icu-libs
krb5-libs
libgcc
libintl
libssl1.1 (Alpine 3.9 o superior)
libssl1.0 (Alpine 3.8 o inferior)
libstdc++
zlib

Instalación con script

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use
el parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0

Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el
entorno de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o
en distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar,
descargue una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el
terminal, en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes
comandos desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función
de lo que haya descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos
disponibles para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si
no se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Instalación del SDK y el entorno de ejecución de
.NET en CentOS
18/12/2020 • 21 minutes to read • Edit Online

.NET es compatible con CentOS. En este artículo se describe cómo instalar .NET en CentOS.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo necesita
ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se recomienda
instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de las versiones de .NET admitidas actualmente en CentOS 7 y CentOS 8.
Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte técnico o ya no
se admita la versión de CentOS.
El símbolo ✔
️ indica que todavía se admite la versión de CentOS o de .NET.
El símbolo ❌ indica que la versión de CentOS o de .NET no se admite en esa versión de CentOS.
Si una versión de CentOS y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo y
.NET se admite.

C EN TO S . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 8
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 7
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Las versiones siguientes de .NET ya no se admiten. Las descargas de estas siguen estando publicadas:
3.0
2.2
2.0

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

Eliminación de versiones preliminares

Cuando se usa un administrador de paquetes para administrar la instalación de .NET, es posible que se produzca
un conflicto si previamente se ha instalado una versión preliminar. El administrador de paquetes puede interpretar
la versión que no es preliminar como una versión anterior de .NET. Para instalar la versión que no es preliminar,
desinstale primero las versiones preliminares. Para obtener más información sobre cómo desinstalar .NET, vea
Procedimiento para quitar el entorno de ejecución y el SDK de .NET.

Procedimiento para instalar otras versiones

Los paquetes agregados a las fuentes del administrador de paquetes se denominan con un formato susceptible de
intrusiones: {product}-{type}-{version} .
product
Tipo de producto .NET que se va a instalar. Las opciones válidas son:
dotnet
aspnetcore
type
Elige el SDK o el entorno de ejecución. Las opciones válidas son:
sdk
motor en tiempo de ejecución
version
Versión del SDK o del entorno de ejecución que se va a instalar. En este artículo se proporcionarán siempre
las instrucciones para la última versión admitida. Las opciones válidas son cualquier versión de lanzamiento,
como las siguientes:
5.0
3.1
3.0
2.1
Es posible que el SDK o el entorno de ejecución que intenta descargar no esté disponible para su
distribución de Linux. Para obtener una lista de las distribuciones admitidas, consulte Dependencias y
requisitos de .NET Core.
Ejemplos
Instalación del entorno de ejecución de ASP.NET Core 5.0: aspnetcore-runtime-5.0
Instalación del entorno de ejecución de ASP.NET Core 2.1: dotnet-runtime-2.1
Instalación del SDK de .NET 5.0: dotnet-sdk-5.0
Instalación del SDK de .NET Core 3.1: dotnet-sdk-3.1
Falta el paquete
Si la combinación de paquete y versión no funciona, no está disponible. Por ejemplo, no hay un SDK de ASP.NET
Core; los componentes del SDK se incluyen en el SDK de .NET. El valor aspnetcore-sdk-2.2 es no es correcto y debe
ser dotnet-sdk-2.2 . Para obtener una lista de las distribuciones de Linux compatibles con .NET, vea Dependencias
y requisitos de .NET.

CentOS 8 ✔
️
.NET 5.0 está disponible en los repositorios de paquetes predeterminados de CentOS 8.
Instalación del SDK
El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:
 sudo dnf install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo dnf install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo dnf install dotnet-runtime-5.0

CentOS 7 ✔
️
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo yum install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo yum install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo yum install dotnet-runtime-5.0

Solución de problemas del administrador de paquetes

En esta sección se proporciona información sobre los errores comunes que puede obtener al usar el administrador
de paquetes para instalar .NET.
No se puede encontrar el paquete
 IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

No se pudo capturar el elemento

Al instalar el paquete de .NET, puede ver un error similar a
signature verification failed for file 'repomd.xml' from repository 'packages-microsoft-com-prod' . En términos
generales, este error significa que la fuente de paquetes para .NET se está actualizando con versiones de paquetes
más recientes y que debe volver a intentarlo más tarde. Durante una actualización, la fuente de paquetes no debe
estar disponible durante más de 2 horas. Si recibe este error continuamente durante más de 2 horas, abra una
incidencia en https://github.com/dotnet/core/issues.

Snap
.NET Core está disponible desde el almacén de snaps.
Un snap es una agrupación de una aplicación y sus dependencias que funcionan sin modificaciones en muchas
distribuciones de Linux diferentes. Los snaps se reconocen y se instalan desde el almacén de snaps. Para más
información sobre Snap, consulte Introducción a Snap.
Solo las versiones admitidas de .NET Core están disponibles mediante Snap.
Instalación del SDK
Los paquetes Snap para el SDK de .NET se publican con el mismo identificador: dotnet-sdk . Se puede instalar una
versión específica del SDK mediante la especificación del canal. El SDK incluye el entorno de ejecución
correspondiente. En la tabla siguiente se enumeran los canales:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 5.0 o latest/stable

3.1 (LTS) 3.1 o lts/stable

2.1 (LTS) 2.1

Use el comando snap install para instalar un paquete Snap del SDK de .NET. Use el parámetro --channel para
indicar qué versión se va a instalar. Si se omite este parámetro, se usa latest/stable . En este ejemplo, se
especifica 5.0 :

sudo snap install dotnet-sdk --classic --channel=5.0

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-sdk.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-sdk.dotnet dotnet50 . Cuando use el comando dotnet50 , invocará
esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los tutoriales y
ejemplos, donde se espera que esté disponible un comando dotnet .
Instalación de la instancia en tiempo de ejecución
Los paquetes Snap de .NET Core Runtime se publican con su propio identificador de paquete. En la tabla siguiente
se muestra una lista de los identificadores de paquete:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 dotnet-runtime-50

3.1 (LTS) dotnet-runtime-31

3.0 dotnet-runtime-30

2.2 dotnet-runtime-22

2.1 (LTS) dotnet-runtime-21

Use el comando snap install para instalar un paquete Snap del entorno de ejecución de .NET. En este ejemplo, se
instala .NET 5.0:

sudo snap install dotnet-runtime-50 --classic

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-runtime-50.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-runtime-50.dotnet dotnet50 . Cuando use el comando dotnet50 ,
invocará esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los
tutoriales y ejemplos, donde se espera que esté disponible un comando dotnet .
Errores de certificado SSL
Cuando .NET se instala mediante Snap, es posible que en algunas distribuciones no se encuentren los certificados
SSL de .NET y que reciba un error similar al siguiente durante la acción restore :

Processing post-creation actions...

Running 'dotnet restore' on /home/myhome/test/test.csproj...
Restoring packages for /home/myhome/test/test.csproj...
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : Unable to load the service index for source
https://api.nuget.org/v3/index.json. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The SSL connection could not be established,
see inner exception. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The remote certificate is invalid according to
the validation procedure. [/home/myhome/test/test.csproj]

Para resolver este problema, establezca algunas variables de entorno:

export SSL_CERT_FILE=[path-to-certificate-file]
export SSL_CERT_DIR=/dev/null

La ubicación del certificado variará en función de la distribución. Estas son las ubicaciones de las distribuciones en
las que hemos experimentado el problema.
 Fedora: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
OpenSUSE: /etc/ssl/ca-bundle.pem
Solus: /etc/ssl/certs/ca-certificates.crt

Dependencias
Al realizar la instalación con un administrador de paquetes, estas bibliotecas se instalan automáticamente. Sin
embargo, si instala manualmente .NET Core o publica una aplicación independiente, deberá asegurarse de que
estas bibliotecas estén instaladas:
krb5-libs
libicu
openssl-libs
Si la versión de OpenSSL del entorno de tiempo de ejecución de destino es 1.1 o más reciente, deberá instalar
compat-openssl10 .
Para obtener más información sobre las dependencias, vea Aplicaciones de Linux independientes.
En el caso de las aplicaciones de .NET Core que utilizan el ensamblado System.Drawing.Common, también se
necesitará la dependencia siguiente:
libgdiplus (versión 6.0.1 o posterior)

WARNING
Puede instalar una versión reciente de libgdiplus agregando el repositorio Mono al sistema. Para obtener más
información, vea https://www.mono-project.com/download/stable/.

Instalación con script

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use el
parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0

Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el entorno
de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o en
distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes comandos
desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de lo que haya
descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos disponibles
para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Instalación del SDK y el entorno de ejecución de
.NET en Debian
18/12/2020 • 27 minutes to read • Edit Online

En este artículo se describe cómo instalar .NET en Debian. Cuando una versión de Debian no es compatible, .NET
deja de ser compatible con esa versión. Pero estas instrucciones pueden ayudarle a conseguir que .NET se ejecute
en esas versiones, aunque no se admita.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo necesita
ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se recomienda
instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de Debian
en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del
soporte técnico o la versión de Debian llegue al final del ciclo de vida.
El símbolo ✔
️ indica que todavía se admite la versión de Debian o de .NET.
El símbolo ❌ indica que la versión de Debian o de .NET no se admite en esa versión de Debian.
Si una versión de Debian y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo y
.NET se admite.

DEB IA N . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 10
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 9
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌8 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

Las versiones siguientes de .NET ya no se admiten. aunque sus descargas siguen estando publicadas:
3.0
2.2
2.0

Eliminación de versiones preliminares

Cuando se usa un administrador de paquetes para administrar la instalación de .NET, es posible que se produzca
un conflicto si previamente se ha instalado una versión preliminar. El administrador de paquetes puede interpretar
la versión que no es preliminar como una versión anterior de .NET. Para instalar la versión que no es preliminar,
desinstale primero las versiones preliminares. Para obtener más información sobre cómo desinstalar .NET, vea
Procedimiento para quitar el entorno de ejecución y el SDK de .NET.

Procedimiento para instalar otras versiones

Los paquetes agregados a las fuentes del administrador de paquetes se denominan con un formato susceptible de
intrusiones: {product}-{type}-{version} .
product
Tipo de producto .NET que se va a instalar. Las opciones válidas son:
dotnet
aspnetcore
type
Elige el SDK o el entorno de ejecución. Las opciones válidas son:
sdk
motor en tiempo de ejecución
version
Versión del SDK o del entorno de ejecución que se va a instalar. En este artículo se proporcionarán siempre
las instrucciones para la última versión admitida. Las opciones válidas son cualquier versión de lanzamiento,
como las siguientes:
5.0
3.1
3.0
2.1
Es posible que el SDK o el entorno de ejecución que intenta descargar no esté disponible para su
distribución de Linux. Para obtener una lista de las distribuciones admitidas, consulte Dependencias y
requisitos de .NET Core.
Ejemplos
Instalación del entorno de ejecución de ASP.NET Core 5.0: aspnetcore-runtime-5.0
Instalación del entorno de ejecución de ASP.NET Core 2.1: dotnet-runtime-2.1
Instalación del SDK de .NET 5.0: dotnet-sdk-5.0
Instalación del SDK de .NET Core 3.1: dotnet-sdk-3.1
Falta el paquete
Si la combinación de paquete y versión no funciona, no está disponible. Por ejemplo, no hay un SDK de ASP.NET
Core; los componentes del SDK se incluyen en el SDK de .NET. El valor aspnetcore-sdk-2.2 es no es correcto y debe
ser dotnet-sdk-2.2 . Para obtener una lista de las distribuciones de Linux compatibles con .NET, vea Dependencias
y requisitos de .NET.

Debian 10 ✔
️
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:
 wget https://packages.microsoft.com/config/debian/10/packages-microsoft-prod.deb -O packages-microsoft-
prod.deb
sudo dpkg -i packages-microsoft-prod.deb

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-5.0 , vea la sección Solución de
problemas de APT.

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-5.0 , vea la sección
Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo apt-get install -y dotnet-runtime-5.0

Debian 9 ✔
️
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:
 wget -O - https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget https://packages.microsoft.com/config/debian/9/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-5.0 , vea la sección Solución de
problemas de APT.

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-5.0

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-5.0 , vea la sección
Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo apt-get install -y dotnet-runtime-5.0

Debian 8 ❌
❌ Tenga en cuenta que esta versión de Debian ya no se admite.
La instalación con APT puede realizarse con unos pocos comandos. Antes de instalar .NET, ejecute los siguientes
comandos para agregar la clave de la firma del paquete de Microsoft a la lista de claves de confianza y agregar el
repositorio de paquetes.
Abra un terminal y ejecute los comandos siguientes:
 wget -O - https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget https://packages.microsoft.com/config/debian/8/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete dotnet-sdk-2.1 , consulte la sección Solución
de problemas de APT.

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y aspnetcore-runtime-2.1

IMPORTANT
Si recibe un mensaje de error similar a No se puede encontrar el paquete aspnetcore-runtime-2.1 , consulte la
sección Solución de problemas de APT.

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-2.1 por dotnet-runtime-2.1 .

sudo apt-get install -y dotnet-runtime-2.1

SDK o entorno de ejecución de actualización de APT

Cuando hay disponible una nueva versión de revisión para .NET, basta con actualizarla mediante APT con los
comandos siguientes:

sudo apt-get update

sudo apt-get upgrade
Solución de problemas de APT
En esta sección se proporciona información sobre los errores comunes que puede recibir al usar APT para instalar
.NET.
No se puede encontrar el paquete

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

No se puede encontrar el paquete \ No se han podido instalar algunos paquetes

Si recibe un mensaje de error similar a No se puede encontrar el paquete {dotnet-package} o No se han
podido instalar algunos paquetes , ejecute los comandos siguientes.
Hay dos marcadores de posición en el siguiente conjunto de comandos.
{dotnet-package}
Representa el paquete de .NET que va a instalar, como aspnetcore-runtime-3.1 . Se usa en el comando
sudo apt-get install siguiente.

{os-version}
Representa la versión de Linux en la que está. Se usa en el comando wget siguiente.

Primero, pruebe a purgar la lista de paquetes:

sudo dpkg --purge packages-microsoft-prod && sudo dpkg -i packages-microsoft-prod.deb

sudo apt-get update

Después, intente volver a instalar .NET. Si eso no funciona, puede ejecutar una instalación manual con los
comandos siguientes:

sudo apt-get install -y gpg

wget -O - https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget https://packages.microsoft.com/config/debian/{os-version}/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list
sudo apt-get update; \
sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y {dotnet-package}

No se pudo capturar el elemento

Al instalar el paquete de .NET, puede ver un error similar a
Failed to fetch ... File has unexpected size ... Mirror sync in progress? . Este error podría significar que la
fuente de paquetes de .NET se está actualizando con versiones de paquetes más recientes y que debe volver a
intentarlo más tarde. Durante una actualización, la falta de disponibilidad de la fuente de paquetes no debe ser
superior a 30 minutos. Si recibe este error continuamente durante más de 30 minutos, abra una incidencia en
https://github.com/dotnet/core/issues.

Snap
.NET Core está disponible desde el almacén de snaps.
Un snap es una agrupación de una aplicación y sus dependencias que funcionan sin modificaciones en muchas
distribuciones de Linux diferentes. Los snaps se reconocen y se instalan desde el almacén de snaps. Para más
información sobre Snap, consulte Introducción a Snap.
Solo las versiones admitidas de .NET Core están disponibles mediante Snap.
Instalación del SDK
Los paquetes Snap para el SDK de .NET se publican con el mismo identificador: dotnet-sdk . Se puede instalar una
versión específica del SDK mediante la especificación del canal. El SDK incluye el entorno de ejecución
correspondiente. En la tabla siguiente se enumeran los canales:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 5.0 o latest/stable

3.1 (LTS) 3.1 o lts/stable

2.1 (LTS) 2.1

Use el comando snap install para instalar un paquete Snap del SDK de .NET. Use el parámetro --channel para
indicar qué versión se va a instalar. Si se omite este parámetro, se usa latest/stable . En este ejemplo, se
especifica 5.0 :

sudo snap install dotnet-sdk --classic --channel=5.0

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-sdk.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-sdk.dotnet dotnet50 . Cuando use el comando dotnet50 , invocará
esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los tutoriales y
ejemplos, donde se espera que esté disponible un comando dotnet .
Instalación de la instancia en tiempo de ejecución
Los paquetes Snap de .NET Core Runtime se publican con su propio identificador de paquete. En la tabla siguiente
se muestra una lista de los identificadores de paquete:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 dotnet-runtime-50

3.1 (LTS) dotnet-runtime-31

3.0 dotnet-runtime-30

2.2 dotnet-runtime-22

2.1 (LTS) dotnet-runtime-21

Use el comando snap install para instalar un paquete Snap del entorno de ejecución de .NET. En este ejemplo, se
instala .NET 5.0:

sudo snap install dotnet-runtime-50 --classic

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-runtime-50.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-runtime-50.dotnet dotnet50 . Cuando use el comando dotnet50 ,
invocará esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los
tutoriales y ejemplos, donde se espera que esté disponible un comando dotnet .
Errores de certificado SSL
Cuando .NET se instala mediante Snap, es posible que en algunas distribuciones no se encuentren los certificados
SSL de .NET y que reciba un error similar al siguiente durante la acción restore :

Processing post-creation actions...

Running 'dotnet restore' on /home/myhome/test/test.csproj...
Restoring packages for /home/myhome/test/test.csproj...
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : Unable to load the service index for source
https://api.nuget.org/v3/index.json. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The SSL connection could not be established,
see inner exception. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The remote certificate is invalid according to
the validation procedure. [/home/myhome/test/test.csproj]

Para resolver este problema, establezca algunas variables de entorno:

export SSL_CERT_FILE=[path-to-certificate-file]
export SSL_CERT_DIR=/dev/null

La ubicación del certificado variará en función de la distribución. Estas son las ubicaciones de las distribuciones en
las que hemos experimentado el problema.
Fedora: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
OpenSUSE: /etc/ssl/ca-bundle.pem
Solus: /etc/ssl/certs/ca-certificates.crt

Dependencias
Al realizar la instalación con un administrador de paquetes, estas bibliotecas se instalan automáticamente. Sin
embargo, si instala manualmente .NET Core o publica una aplicación independiente, deberá asegurarse de que
estas bibliotecas estén instaladas:
libc6
libgcc1
libgssapi-krb5-2
libicu52 (para 8.x)
libicu57 (para 9.x)
libicu63 (para 10.x)
libicu67 (para 11.x)
 libssl1.0.0 (para 8.x)
libssl1.1 (para 9.x-11.x)
libstdc++6
zlib1g
En el caso de las aplicaciones de .NET Core que utilizan el ensamblado System.Drawing.Common, también se
necesita la dependencia siguiente:
libgdiplus (versión 6.0.1 o posteriores)

WARNING
Puede instalar una versión reciente de libgdiplus agregando el repositorio Mono al sistema. Para obtener más
información, vea https://www.mono-project.com/download/stable/.

Instalación con script

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use el
parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0

Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el entorno
de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o en
distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes comandos
desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de lo que haya
descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos disponibles
para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Instalación del SDK y el entorno de ejecución de
.NET en Fedora
18/12/2020 • 31 minutes to read • Edit Online

.NET es compatible con Fedora. En este artículo se describe cómo instalar .NET en Fedora. Cuando una versión de
Fedora no es compatible, .NET deja de ser compatible con esa versión. Pero estas instrucciones pueden ayudarle a
conseguir que .NET se ejecute en esas versiones, aunque no se admita.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo necesita
ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se recomienda
instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de versiones de .NET actualmente compatibles y las versiones de Fedora
en las que se admiten. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del
soporte técnico o la versión de Fedora llegue al final del ciclo de vida.
El símbolo ✔
️ indica que todavía se admite la versión de Fedora o de .NET.
El símbolo ❌ indica que la versión de Fedora o de .NET no se admite en esa versión de Fedora.
Si una versión de Fedora y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo y
.NET se admite.

F EDO RA . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 33
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 32
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

❌ 31 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 30 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 29 ️ 2.1
✔ ️ 3.1
✔ ❌ 5.0

❌ 28 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

❌ 27 ️ 2.1
✔ ❌ 3.1 ❌ 5.0

Las versiones siguientes de .NET ya no se admiten. Las descargas de estas siguen estando publicadas:
 3.0
2.2
2.0

Eliminación de versiones preliminares

Cuando se usa un administrador de paquetes para administrar la instalación de .NET, es posible que se produzca
un conflicto si previamente se ha instalado una versión preliminar. El administrador de paquetes puede interpretar
la versión que no es preliminar como una versión anterior de .NET. Para instalar la versión que no es preliminar,
desinstale primero las versiones preliminares. Para obtener más información sobre cómo desinstalar .NET, vea
Procedimiento para quitar el entorno de ejecución y el SDK de .NET.

Procedimiento para instalar otras versiones

Los paquetes agregados a las fuentes del administrador de paquetes se denominan con un formato susceptible de
intrusiones: {product}-{type}-{version} .
product
Tipo de producto .NET que se va a instalar. Las opciones válidas son:
dotnet
aspnetcore
type
Elige el SDK o el entorno de ejecución. Las opciones válidas son:
sdk
motor en tiempo de ejecución
version
Versión del SDK o del entorno de ejecución que se va a instalar. En este artículo se proporcionarán siempre
las instrucciones para la última versión admitida. Las opciones válidas son cualquier versión de lanzamiento,
como las siguientes:
5.0
3.1
3.0
2.1
Es posible que el SDK o el entorno de ejecución que intenta descargar no esté disponible para su
distribución de Linux. Para obtener una lista de las distribuciones admitidas, consulte Dependencias y
requisitos de .NET Core.
Ejemplos
Instalación del entorno de ejecución de ASP.NET Core 5.0: aspnetcore-runtime-5.0
Instalación del entorno de ejecución de ASP.NET Core 2.1: dotnet-runtime-2.1
Instalación del SDK de .NET 5.0: dotnet-sdk-5.0
Instalación del SDK de .NET Core 3.1: dotnet-sdk-3.1
Falta el paquete
Si la combinación de paquete y versión no funciona, no está disponible. Por ejemplo, no hay un SDK de ASP.NET
Core; los componentes del SDK se incluyen en el SDK de .NET. El valor aspnetcore-sdk-2.2 es no es correcto y debe
ser dotnet-sdk-2.2 . Para obtener una lista de las distribuciones de Linux compatibles con .NET, vea Dependencias
y requisitos de .NET.
Fedora 33 ✔
️
TIP
.NET Core 3.1 está disponible en los repositorios de paquetes predeterminados para Fedora 33. Para instalar .NET Core 3.1,
use el comando dnf install con el paquete adecuado, como aspnetcore-runtime-3.1 o dotnet-sdk-3.1 . .NET 5.0
todavía no está disponible en los repositorios de paquetes predeterminados.

Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/33/prod.repo

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo dnf install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo dnf install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo dnf install dotnet-runtime-5.0

Fedora 32 ✔
️
TIP
.NET Core 3.1 está disponible en los repositorios de paquetes predeterminados para Fedora 32. Para instalar .NET Core 3.1,
use el comando dnf install con el paquete adecuado, como aspnetcore-runtime-3.1 o dotnet-sdk-3.1 . .NET 5.0
todavía no está disponible en los repositorios de paquetes predeterminados.

Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/32/prod.repo

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo dnf install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo dnf install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo dnf install dotnet-runtime-5.0

Fedora 31 ❌
❌ Tenga en cuenta que esta versión de Fedora ya no se admite.
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/31/prod.repo

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo dnf install dotnet-sdk-3.1

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo dnf install aspnetcore-runtime-3.1

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-3.1 por dotnet-runtime-3.1 .

sudo dnf install dotnet-runtime-3.1

Fedora 30 ❌
❌ Tenga en cuenta que esta versión de Fedora ya no se admite.
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/30/prod.repo

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo dnf install dotnet-sdk-3.1

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo dnf install aspnetcore-runtime-3.1

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-3.1 por dotnet-runtime-3.1 .

sudo dnf install dotnet-runtime-3.1

Fedora 29 ❌
❌ Tenga en cuenta que esta versión de Fedora ya no se admite.
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/29/prod.repo

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo dnf install dotnet-sdk-3.0

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo dnf install aspnetcore-runtime-3.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-3.0 por dotnet-runtime-3.0 .

sudo dnf install dotnet-runtime-3.0

Fedora 28 ❌
❌ Tenga en cuenta que esta versión de Fedora ya no se admite.
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/28/prod.repo

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo dnf install dotnet-sdk-2.0

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo dnf install aspnetcore-runtime-2.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-2.0 por dotnet-runtime-2.0 .

sudo dnf install dotnet-runtime-2.0

Fedora 27 ❌
❌ Tenga en cuenta que esta versión de Fedora ya no se admite.
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/27/prod.repo
Instalación del SDK
El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los comandos
siguientes:

sudo dnf install dotnet-sdk-2.0

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core, el más compatible con
.NET Core. En el terminal, ejecute los comandos siguientes.

sudo dnf install aspnetcore-runtime-2.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET Core, que no incluye compatibilidad
con ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-2.0 por dotnet-runtime-2.0 .

sudo dnf install dotnet-runtime-2.0

Solución de problemas del administrador de paquetes

En esta sección se proporciona información sobre los errores comunes que puede obtener al usar el administrador
de paquetes para instalar .NET Core.
No se puede encontrar el paquete

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

No se pudo capturar el elemento

Al instalar el paquete de .NET, puede ver un error similar a
signature verification failed for file 'repomd.xml' from repository 'packages-microsoft-com-prod' . En términos
generales, este error significa que la fuente de paquetes para .NET se está actualizando con versiones de paquetes
más recientes y que debe volver a intentarlo más tarde. Durante una actualización, la fuente de paquetes no debe
estar disponible durante más de 2 horas. Si recibe este error continuamente durante más de 2 horas, abra una
incidencia en https://github.com/dotnet/core/issues.

Snap
.NET Core está disponible desde el almacén de snaps.
Un snap es una agrupación de una aplicación y sus dependencias que funcionan sin modificaciones en muchas
distribuciones de Linux diferentes. Los snaps se reconocen y se instalan desde el almacén de snaps. Para más
información sobre Snap, consulte Introducción a Snap.
Solo las versiones admitidas de .NET Core están disponibles mediante Snap.
Instalación del SDK
Los paquetes Snap para el SDK de .NET se publican con el mismo identificador: dotnet-sdk . Se puede instalar una
versión específica del SDK mediante la especificación del canal. El SDK incluye el entorno de ejecución
correspondiente. En la tabla siguiente se enumeran los canales:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 5.0 o latest/stable

3.1 (LTS) 3.1 o lts/stable

2.1 (LTS) 2.1

Use el comando snap install para instalar un paquete Snap del SDK de .NET. Use el parámetro --channel para
indicar qué versión se va a instalar. Si se omite este parámetro, se usa latest/stable . En este ejemplo, se
especifica 5.0 :

sudo snap install dotnet-sdk --classic --channel=5.0

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-sdk.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-sdk.dotnet dotnet50 . Cuando use el comando dotnet50 , invocará
esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los tutoriales y
ejemplos, donde se espera que esté disponible un comando dotnet .
Instalación de la instancia en tiempo de ejecución
Los paquetes Snap de .NET Core Runtime se publican con su propio identificador de paquete. En la tabla siguiente
se muestra una lista de los identificadores de paquete:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 dotnet-runtime-50

3.1 (LTS) dotnet-runtime-31

3.0 dotnet-runtime-30

2.2 dotnet-runtime-22

2.1 (LTS) dotnet-runtime-21

Use el comando snap install para instalar un paquete Snap del entorno de ejecución de .NET. En este ejemplo, se
instala .NET 5.0:

sudo snap install dotnet-runtime-50 --classic

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-runtime-50.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-runtime-50.dotnet dotnet50 . Cuando use el comando dotnet50 ,
invocará esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los
tutoriales y ejemplos, donde se espera que esté disponible un comando dotnet .
Errores de certificado SSL
Cuando .NET se instala mediante Snap, es posible que en algunas distribuciones no se encuentren los certificados
SSL de .NET y que reciba un error similar al siguiente durante la acción restore :

Processing post-creation actions...

Running 'dotnet restore' on /home/myhome/test/test.csproj...
Restoring packages for /home/myhome/test/test.csproj...
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : Unable to load the service index for source
https://api.nuget.org/v3/index.json. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The SSL connection could not be established,
see inner exception. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The remote certificate is invalid according to
the validation procedure. [/home/myhome/test/test.csproj]

Para resolver este problema, establezca algunas variables de entorno:

export SSL_CERT_FILE=[path-to-certificate-file]
export SSL_CERT_DIR=/dev/null

La ubicación del certificado variará en función de la distribución. Estas son las ubicaciones de las distribuciones en
las que hemos experimentado el problema.
Fedora: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
OpenSUSE: /etc/ssl/ca-bundle.pem
Solus: /etc/ssl/certs/ca-certificates.crt

Dependencias
Al realizar la instalación con un administrador de paquetes, estas bibliotecas se instalan automáticamente. Sin
embargo, si instala manualmente .NET Core o publica una aplicación independiente, deberá asegurarse de que
estas bibliotecas estén instaladas:
krb5-libs
libicu
openssl-libs
Si la versión de OpenSSL del entorno de tiempo de ejecución de destino es 1.1 o más reciente, deberá instalar
compat-openssl10 .
Para obtener más información sobre las dependencias, vea Aplicaciones de Linux independientes.
En el caso de las aplicaciones de .NET Core que utilizan el ensamblado System.Drawing.Common, también se
necesitará la dependencia siguiente:
libgdiplus (versión 6.0.1 o posterior)
 WARNING
Puede instalar una versión reciente de libgdiplus agregando el repositorio Mono al sistema. Para obtener más
información, vea https://www.mono-project.com/download/stable/.

Instalación con script

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use el
parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0

Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el entorno
de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o en
distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes comandos
desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de lo que haya
descargado.
Use el comando siguiente para extraer el entorno de ejecución :
 mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"
export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos disponibles
para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Instalación del SDK y el entorno de ejecución de
.NET en openSUSE
18/12/2020 • 19 minutes to read • Edit Online

.NET es compatible con openSUSE. En este artículo se describe cómo instalar .NET en openSUSE.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo necesita
ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se recomienda
instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de las versiones de .NET compatibles actualmente con openSUSE 15.
Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte técnico o ya no
se admita la versión de openSUSE.
El símbolo ✔
️ indica que todavía se admite la versión de openSUSE o de .NET.
El símbolo ❌ indica que la versión de openSUSE o de .NET no se admite en esa versión de openSUSE.
Si una versión de openSUSE y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema
operativo y .NET se admite.

O P EN SUSE . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 15
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Las versiones siguientes de .NET ya no se admiten. aunque sus descargas siguen estando publicadas:
3.0
2.2
2.0

Eliminación de versiones preliminares

Cuando se usa un administrador de paquetes para administrar la instalación de .NET, es posible que se produzca
un conflicto si previamente se ha instalado una versión preliminar. El administrador de paquetes puede interpretar
la versión que no es preliminar como una versión anterior de .NET. Para instalar la versión que no es preliminar,
desinstale primero las versiones preliminares. Para obtener más información sobre cómo desinstalar .NET, vea
Procedimiento para quitar el entorno de ejecución y el SDK de .NET.
Procedimiento para instalar otras versiones
Los paquetes agregados a las fuentes del administrador de paquetes se denominan con un formato susceptible de
intrusiones: {product}-{type}-{version} .
product
Tipo de producto .NET que se va a instalar. Las opciones válidas son:
dotnet
aspnetcore
type
Elige el SDK o el entorno de ejecución. Las opciones válidas son:
sdk
motor en tiempo de ejecución
version
Versión del SDK o del entorno de ejecución que se va a instalar. En este artículo se proporcionarán siempre
las instrucciones para la última versión admitida. Las opciones válidas son cualquier versión de lanzamiento,
como las siguientes:
5.0
3.1
3.0
2.1
Es posible que el SDK o el entorno de ejecución que intenta descargar no esté disponible para su
distribución de Linux. Para obtener una lista de las distribuciones admitidas, consulte Dependencias y
requisitos de .NET Core.
Ejemplos
Instalación del entorno de ejecución de ASP.NET Core 5.0: aspnetcore-runtime-5.0
Instalación del entorno de ejecución de ASP.NET Core 2.1: dotnet-runtime-2.1
Instalación del SDK de .NET 5.0: dotnet-sdk-5.0
Instalación del SDK de .NET Core 3.1: dotnet-sdk-3.1
Falta el paquete
Si la combinación de paquete y versión no funciona, no está disponible. Por ejemplo, no hay un SDK de ASP.NET
Core; los componentes del SDK se incluyen en el SDK de .NET. El valor aspnetcore-sdk-2.2 es no es correcto y debe
ser dotnet-sdk-2.2 . Para obtener una lista de las distribuciones de Linux compatibles con .NET, vea Dependencias
y requisitos de .NET.

openSUSE 15 ✔
️
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo zypper install libicu

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
wget https://packages.microsoft.com/config/opensuse/15/prod.repo
sudo mv prod.repo /etc/zypp/repos.d/microsoft-prod.repo
sudo chown root:root /etc/zypp/repos.d/microsoft-prod.repo

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo zypper install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo zypper install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo zypper install dotnet-runtime-5.0

Solución de problemas del administrador de paquetes

En esta sección se proporciona información sobre los errores comunes que puede obtener al usar el administrador
de paquetes para instalar .NET.
No se puede encontrar el paquete

IMPORTANT
Las instalaciones del administrador de paquetes solo se admiten en la arquitectura x64 . Otras arquitecturas, como ARM ,
deben instalar .NET de forma manual. Para obtener más información, vea la sección Instalación manual.

No se pudo capturar el elemento

Al instalar el paquete de .NET, puede ver un error similar a
signature verification failed for file 'repomd.xml' from repository 'packages-microsoft-com-prod' . En términos
generales, este error significa que la fuente de paquetes para .NET se está actualizando con versiones de paquetes
más recientes y que debe volver a intentarlo más tarde. Durante una actualización, la fuente de paquetes no debe
estar disponible durante más de 2 horas. Si recibe este error continuamente durante más de 2 horas, abra una
incidencia en https://github.com/dotnet/core/issues.

Snap
.NET Core está disponible desde el almacén de snaps.
Un snap es una agrupación de una aplicación y sus dependencias que funcionan sin modificaciones en muchas
distribuciones de Linux diferentes. Los snaps se reconocen y se instalan desde el almacén de snaps. Para más
información sobre Snap, consulte Introducción a Snap.
Solo las versiones admitidas de .NET Core están disponibles mediante Snap.
Instalación del SDK
Los paquetes Snap para el SDK de .NET se publican con el mismo identificador: dotnet-sdk . Se puede instalar una
versión específica del SDK mediante la especificación del canal. El SDK incluye el entorno de ejecución
correspondiente. En la tabla siguiente se enumeran los canales:
 VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 5.0 o latest/stable

3.1 (LTS) 3.1 o lts/stable

2.1 (LTS) 2.1

Use el comando snap install para instalar un paquete Snap del SDK de .NET. Use el parámetro --channel para
indicar qué versión se va a instalar. Si se omite este parámetro, se usa latest/stable . En este ejemplo, se
especifica 5.0 :

sudo snap install dotnet-sdk --classic --channel=5.0

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-sdk.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-sdk.dotnet dotnet50 . Cuando use el comando dotnet50 , invocará
esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los tutoriales y
ejemplos, donde se espera que esté disponible un comando dotnet .
Instalación de la instancia en tiempo de ejecución
Los paquetes Snap de .NET Core Runtime se publican con su propio identificador de paquete. En la tabla siguiente
se muestra una lista de los identificadores de paquete:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 dotnet-runtime-50

3.1 (LTS) dotnet-runtime-31

3.0 dotnet-runtime-30

2.2 dotnet-runtime-22

2.1 (LTS) dotnet-runtime-21

Use el comando snap install para instalar un paquete Snap del entorno de ejecución de .NET. En este ejemplo, se
instala .NET 5.0:

sudo snap install dotnet-runtime-50 --classic

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-runtime-50.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-runtime-50.dotnet dotnet50 . Cuando use el comando dotnet50 ,
invocará esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los
tutoriales y ejemplos, donde se espera que esté disponible un comando dotnet .
Errores de certificado SSL
Cuando .NET se instala mediante Snap, es posible que en algunas distribuciones no se encuentren los certificados
SSL de .NET y que reciba un error similar al siguiente durante la acción restore :

Processing post-creation actions...

Running 'dotnet restore' on /home/myhome/test/test.csproj...
Restoring packages for /home/myhome/test/test.csproj...
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : Unable to load the service index for source
https://api.nuget.org/v3/index.json. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The SSL connection could not be established,
see inner exception. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The remote certificate is invalid according to
the validation procedure. [/home/myhome/test/test.csproj]

Para resolver este problema, establezca algunas variables de entorno:

export SSL_CERT_FILE=[path-to-certificate-file]
export SSL_CERT_DIR=/dev/null

La ubicación del certificado variará en función de la distribución. Estas son las ubicaciones de las distribuciones en
las que hemos experimentado el problema.
Fedora: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
OpenSUSE: /etc/ssl/ca-bundle.pem
Solus: /etc/ssl/certs/ca-certificates.crt

Dependencias
Al realizar la instalación con un administrador de paquetes, estas bibliotecas se instalan automáticamente. Pero si
instala manualmente .NET o publica una aplicación independiente, deberá asegurarse de que estas bibliotecas
estén instaladas:
krb5
libicu
libopenssl1_0_0
Si la versión de OpenSSL del entorno de tiempo de ejecución de destino es 1.1 o más reciente, deberá instalar
compat-openssl10 .
Para obtener más información sobre las dependencias, vea Aplicaciones de Linux independientes.
En el caso de las aplicaciones de .NET en las que se usa el ensamblado System.Drawing.Common, también se
necesitará la dependencia siguiente:
libgdiplus (versión 6.0.1 o posterior)

WARNING
Puede instalar una versión reciente de libgdiplus agregando el repositorio Mono al sistema. Para obtener más
información, vea https://www.mono-project.com/download/stable/.
Instalación con script
Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use el
parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0

Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el entorno
de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o en
distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes comandos
desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de lo que haya
descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

 mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"
export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos disponibles
para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Instalación del SDK y el entorno de ejecución de
.NET en RHEL
18/12/2020 • 21 minutes to read • Edit Online

.NET es compatible con RHEL. En este artículo se describe cómo instalar .NET en RHEL.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo necesita
ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se recomienda
instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.

Registro de la suscripción de Red Hat

Para instalar .NET desde Red Hat en RHEL, primero debe registrarse con el administrador de suscripciones de Red
Hat. Si esto no se ha realizado en el sistema, o si no tiene certeza de ello, vea la documentación del producto de
Red Hat para .NET.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de las versiones de .NET compatibles actualmente con RHEL 7 y RHEL 8.
Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte técnico o ya no
se admita la versión de RHEL.
El símbolo ✔
️ indica que todavía se admite la versión de RHEL o de .NET.
El símbolo ❌ indica que la versión de RHEL o de .NET no se admite en esa versión de RHEL.
Si una versión de RHEL y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo y
.NET se admite.

RH EL . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 8
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 7
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Las versiones siguientes de .NET ya no se admiten. Las descargas de estas siguen estando publicadas:
3.0
2.2
2.0

Eliminación de versiones preliminares

Cuando se usa un administrador de paquetes para administrar la instalación de .NET, es posible que se produzca
un conflicto si previamente se ha instalado una versión preliminar. El administrador de paquetes puede interpretar
la versión que no es preliminar como una versión anterior de .NET. Para instalar la versión que no es preliminar,
desinstale primero las versiones preliminares. Para obtener más información sobre cómo desinstalar .NET, vea
Procedimiento para quitar el entorno de ejecución y el SDK de .NET.
Procedimiento para instalar otras versiones
Consulte la documentación de Red Hat para .NET sobre los pasos necesarios para instalar otras versiones de .NET.

RHEL 8 ✔
️
.NET se incluye en los repositorios de AppStream para RHEL 8.
Instalación del SDK
El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo dnf install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo dnf install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo dnf install dotnet-runtime-5.0

RHEL 7 ✔
️ .NET 5.0
El siguiente comando instala el paquete scl-utils :

sudo yum install scl-utils

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

subscription-manager repos --enable=rhel-7-server-dotnet-rpms

yum install rh-dotnet50 -y
scl enable rh-dotnet50 bash

Red Hat no recomienda habilitar rh-dotnet50 de forma permanente porque puede afectar a otros programas. Si
quiere habilitar rh-dotnet de forma permanente, agregue la siguiente línea al archivo ~/.bashrc.

source scl_source enable rh-dotnet50

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de .NET permite ejecutar aplicaciones creadas con .NET, pero sin incluir el entorno de
ejecución. Los siguientes comandos instalan el entorno de ejecución de ASP.NET Core, que es el entorno de
ejecución más compatible con .NET Core. En el terminal, ejecute los comandos siguientes.
 subscription-manager repos --enable=rhel-7-server-dotnet-rpms
yum install rh-dotnet50-aspnetcore-runtime-5.0 -y
scl enable rh-dotnet50 bash

Red Hat no recomienda habilitar rh-dotnet50 de forma permanente porque puede afectar a otros programas. Si
quiere habilitar rh-dotnet50 de forma permanente, agregue la siguiente línea al archivo ~/.bashrc.

source scl_source enable rh-dotnet50

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core. Reemplace rh-dotnet50-aspnetcore-runtime-5.0 en los comandos anteriores por
rh-dotnet50-dotnet-runtime-5.0 .

RHEL 7 ✔
️ .NET Core 3.1
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:
El siguiente comando instala el paquete scl-utils :

sudo yum install scl-utils

Instalación del SDK

El SDK de .NET Core permite desarrollar aplicaciones con .NET Core. Si instala el SDK de .NET Core, no necesita
instalar el entorno de ejecución correspondiente. Para instalar el SDK de .NET Core, ejecute los siguientes
comandos:

subscription-manager repos --enable=rhel-7-server-dotnet-rpms

yum install rh-dotnet31 -y
scl enable rh-dotnet31 bash

Red Hat no recomienda habilitar rh-dotnet31 de forma permanente porque puede afectar a otros programas. Por
ejemplo, rh-dotnet31 incluye una versión de libcurl que varía con respecto a la versión base de RHEL. Esto
puede dar lugar a problemas en programas que no esperan una versión diferente de libcurl . Si quiere habilitar
rh-dotnet de forma permanente, agregue la siguiente línea al archivo ~/.bashrc.

source scl_source enable rh-dotnet31

Instalación de la instancia en tiempo de ejecución

.NET Core Runtime le permite ejecutar aplicaciones que se realizaron con .NET Core que no incluían el entorno de
ejecución. Los siguientes comandos instalan el entorno de ejecución de ASP.NET Core, que es el entorno de
ejecución más compatible con .NET Core. En el terminal, ejecute los comandos siguientes.

subscription-manager repos --enable=rhel-7-server-dotnet-rpms

yum install rh-dotnet31-aspnetcore-runtime-3.1 -y
scl enable rh-dotnet31 bash

Red Hat no recomienda habilitar rh-dotnet31 de forma permanente porque puede afectar a otros programas. Por
ejemplo, rh-dotnet31 incluye una versión de libcurl que varía con respecto a la versión base de RHEL. Esto
puede dar lugar a problemas en programas que no esperan una versión diferente de libcurl . Si quiere habilitar
rh-dotnet31 de forma permanente, agregue la siguiente línea al archivo ~/.bashrc.

source scl_source enable rh-dotnet31

Una alternativa al entorno de ejecución de ASP.NET Core es instalar la instancia de .NET Core Runtime que no
incluye compatibilidad con ASP.NET Core. Reemplace rh-dotnet31-aspnetcore-runtime-3.1 en los comandos
anteriores por rh-dotnet31-dotnet-runtime-3.1 .

Snap
.NET Core está disponible desde el almacén de snaps.
Un snap es una agrupación de una aplicación y sus dependencias que funcionan sin modificaciones en muchas
distribuciones de Linux diferentes. Los snaps se reconocen y se instalan desde el almacén de snaps. Para más
información sobre Snap, consulte Introducción a Snap.
Solo las versiones admitidas de .NET Core están disponibles mediante Snap.
Instalación del SDK
Los paquetes Snap para el SDK de .NET se publican con el mismo identificador: dotnet-sdk . Se puede instalar una
versión específica del SDK mediante la especificación del canal. El SDK incluye el entorno de ejecución
correspondiente. En la tabla siguiente se enumeran los canales:

VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 5.0 o latest/stable

3.1 (LTS) 3.1 o lts/stable

2.1 (LTS) 2.1

Use el comando snap install para instalar un paquete Snap del SDK de .NET. Use el parámetro --channel para
indicar qué versión se va a instalar. Si se omite este parámetro, se usa latest/stable . En este ejemplo, se
especifica 5.0 :

sudo snap install dotnet-sdk --classic --channel=5.0

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-sdk.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-sdk.dotnet dotnet50 . Cuando use el comando dotnet50 , invocará
esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los tutoriales y
ejemplos, donde se espera que esté disponible un comando dotnet .
Instalación de la instancia en tiempo de ejecución
Los paquetes Snap de .NET Core Runtime se publican con su propio identificador de paquete. En la tabla siguiente
se muestra una lista de los identificadores de paquete:
 VERSIÓ N DE . N ET PA Q UET E SN A P

5.0 dotnet-runtime-50

3.1 (LTS) dotnet-runtime-31

3.0 dotnet-runtime-30

2.2 dotnet-runtime-22

2.1 (LTS) dotnet-runtime-21

Use el comando snap install para instalar un paquete Snap del entorno de ejecución de .NET. En este ejemplo, se
instala .NET 5.0:

sudo snap install dotnet-runtime-50 --classic

A continuación, registre el comando dotnet del sistema con el comando snap alias :

sudo snap alias dotnet-runtime-50.dotnet dotnet

Este comando tiene el formato sudo snap alias {package}.{command} {alias} . Puede elegir cualquier nombre de
{alias} que prefiera. Por ejemplo, puede asignar un nombre al comando después de la versión específica
instalada por el snap sudo snap alias dotnet-runtime-50.dotnet dotnet50 . Cuando use el comando dotnet50 ,
invocará esta versión específica de .NET. Sin embargo, esta operación no es compatible con la mayoría de los
tutoriales y ejemplos, donde se espera que esté disponible un comando dotnet .
Errores de certificado SSL
Cuando .NET se instala mediante Snap, es posible que en algunas distribuciones no se encuentren los certificados
SSL de .NET y que reciba un error similar al siguiente durante la acción restore :

Processing post-creation actions...

Running 'dotnet restore' on /home/myhome/test/test.csproj...
Restoring packages for /home/myhome/test/test.csproj...
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : Unable to load the service index for source
https://api.nuget.org/v3/index.json. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The SSL connection could not be established,
see inner exception. [/home/myhome/test/test.csproj]
/snap/dotnet-sdk/27/sdk/2.2.103/NuGet.targets(114,5): error : The remote certificate is invalid according to
the validation procedure. [/home/myhome/test/test.csproj]

Para resolver este problema, establezca algunas variables de entorno:

export SSL_CERT_FILE=[path-to-certificate-file]
export SSL_CERT_DIR=/dev/null

La ubicación del certificado variará en función de la distribución. Estas son las ubicaciones de las distribuciones en
las que hemos experimentado el problema.
Fedora: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
OpenSUSE: /etc/ssl/ca-bundle.pem
Solus: /etc/ssl/certs/ca-certificates.crt
Dependencias
Al realizar la instalación con un administrador de paquetes, estas bibliotecas se instalan automáticamente. Sin
embargo, si instala manualmente .NET Core o publica una aplicación independiente, deberá asegurarse de que
estas bibliotecas estén instaladas:
krb5-libs
libicu
openssl-libs
Si la versión de OpenSSL del entorno de tiempo de ejecución de destino es 1.1 o más reciente, deberá instalar
compat-openssl10 .
Para obtener más información sobre las dependencias, vea Aplicaciones de Linux independientes.
En el caso de las aplicaciones de .NET Core que utilizan el ensamblado System.Drawing.Common, también se
necesitará la dependencia siguiente:
libgdiplus (versión 6.0.1 o posterior)

WARNING
Puede instalar una versión reciente de libgdiplus agregando el repositorio Mono al sistema. Para obtener más
información, vea https://www.mono-project.com/download/stable/.

Instalación con script

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use el
parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0

Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el entorno
de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o en
distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes comandos
desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de lo que haya
descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos disponibles
para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.

Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Instalación del SDK y el entorno de ejecución de
.NET en SLES
18/12/2020 • 15 minutes to read • Edit Online

.NET es compatible con SLES. En este artículo se describe cómo instalar .NET en SLES.
Instale el SDK (que incluye el entorno de ejecución) si quiere desarrollar aplicaciones .NET. O bien, si solo necesita
ejecutar aplicaciones, instale el entorno de ejecución. Si va a instalar el entorno de ejecución, se recomienda
instalar el entorno de ejecución de ASP.NET Core , ya que incluye los de .NET y ASP.NET Core.
Si ya ha instalado el SDK o el entorno de ejecución, use los comandos dotnet --list-sdks y
dotnet --list-runtimes para ver qué versiones están instaladas. Para obtener más información, vea Cómo
comprobar que .NET Core ya está instalado.

Distribuciones admitidas
En la tabla siguiente se muestra una lista de las versiones de .NET compatibles actualmente en SLES 12 SP2 y
SLES 15. Estas versiones siguen siendo compatibles hasta que la versión de .NET llegue al final del soporte técnico
o ya no se admita la versión de SLES.
El símbolo ✔
️ indica que todavía se admite la versión de SLES o de .NET.
El símbolo ❌ indica que la versión de SLES o de .NET no se admite en esa versión de SLES.
Si una versión de SLES y una versión de .NET tienen un símbolo ✔
️ , esa combinación de sistema operativo y
.NET se admite.

SL ES . N ET C O RE 2. 1 . N ET C O RE 3. 1 . N ET 5. 0

️ 15
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

️ 12 SP2
✔ ️ 2.1
✔ ️ 3.1
✔ ️ 5.0
✔

Las siguientes versiones de .NET Core ya no se admiten. aunque sus descargas siguen estando publicadas:
3.0
2.2
2.0

Eliminación de versiones preliminares

Cuando se usa un administrador de paquetes para administrar la instalación de .NET, es posible que se produzca
un conflicto si previamente se ha instalado una versión preliminar. El administrador de paquetes puede interpretar
la versión que no es preliminar como una versión anterior de .NET. Para instalar la versión que no es preliminar,
desinstale primero las versiones preliminares. Para obtener más información sobre cómo desinstalar .NET, vea
Procedimiento para quitar el entorno de ejecución y el SDK de .NET.

Procedimiento para instalar otras versiones

Los paquetes agregados a las fuentes del administrador de paquetes se denominan con un formato susceptible de
intrusiones: {product}-{type}-{version} .
 product
Tipo de producto .NET que se va a instalar. Las opciones válidas son:
dotnet
aspnetcore
type
Elige el SDK o el entorno de ejecución. Las opciones válidas son:
sdk
motor en tiempo de ejecución
version
Versión del SDK o del entorno de ejecución que se va a instalar. En este artículo se proporcionarán siempre
las instrucciones para la última versión admitida. Las opciones válidas son cualquier versión de lanzamiento,
como las siguientes:
5.0
3.1
3.0
2.1
Es posible que el SDK o el entorno de ejecución que intenta descargar no esté disponible para su
distribución de Linux. Para obtener una lista de las distribuciones admitidas, consulte Dependencias y
requisitos de .NET Core.
Ejemplos
Instalación del entorno de ejecución de ASP.NET Core 5.0: aspnetcore-runtime-5.0
Instalación del entorno de ejecución de ASP.NET Core 2.1: dotnet-runtime-2.1
Instalación del SDK de .NET 5.0: dotnet-sdk-5.0
Instalación del SDK de .NET Core 3.1: dotnet-sdk-3.1
Falta el paquete
Si la combinación de paquete y versión no funciona, no está disponible. Por ejemplo, no hay un SDK de ASP.NET
Core; los componentes del SDK se incluyen en el SDK de .NET. El valor aspnetcore-sdk-2.2 es no es correcto y debe
ser dotnet-sdk-2.2 . Para obtener una lista de las distribuciones de Linux compatibles con .NET, vea Dependencias
y requisitos de .NET.

SLES 15 ✔
️
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm -Uvh https://packages.microsoft.com/config/sles/15/packages-microsoft-prod.rpm

Actualmente, el paquete de instalación del repositorio de Microsoft de SLES 15 instala el archivo microsoft-
prod.repo en el directorio incorrecto, lo que impide que zypper pueda encontrar los paquetes de .NET. Para corregir
este problema, cree un symlink en el directorio apropiado.

sudo ln -s /etc/yum.repos.d/microsoft-prod.repo /etc/zypp/repos.d/microsoft-prod.repo

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo zypper install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo zypper install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo zypper install dotnet-runtime-5.0

SLES 12 ✔
️
.NET necesita SP2 como mínimo para la familia SLES 12.
Antes de instalar .NET, ejecute los siguientes comandos para agregar la clave de la firma del paquete de Microsoft a
la lista de claves de confianza y agregar el repositorio de paquetes de Microsoft. Abra un terminal y ejecute los
comandos siguientes:

sudo rpm -Uvh https://packages.microsoft.com/config/sles/12/packages-microsoft-prod.rpm

Instalación del SDK

El SDK de .NET permite desarrollar aplicaciones con .NET. Si instala el SDK de .NET, no necesita instalar el entorno
de ejecución correspondiente. Para instalar el SDK de .NET, ejecute los comandos siguientes:

sudo zypper install dotnet-sdk-5.0

Instalación de la instancia en tiempo de ejecución

El entorno de ejecución de ASP.NET Core le permite ejecutar aplicaciones creadas con .NET en las que no se ha
proporcionado el entorno de ejecución. Los comandos siguientes instalan el entorno de ejecución de ASP.NET Core,
el más compatible con .NET. En el terminal, ejecute los comandos siguientes:

sudo zypper install aspnetcore-runtime-5.0

Una alternativa al entorno de ejecución de ASP.NET Core es instalar el de .NET, que no incluye compatibilidad con
ASP.NET Core; en el comando anterior, reemplace aspnetcore-runtime-5.0 por dotnet-runtime-5.0 :

sudo zypper install dotnet-runtime-5.0

Solución de problemas del administrador de paquetes

En esta sección se proporciona información sobre los errores comunes que puede obtener al usar el administrador
de paquetes para instalar .NET.
No se pudo capturar el elemento
Al instalar el paquete de .NET, puede ver un error similar a
signature verification failed for file 'repomd.xml' from repository 'packages-microsoft-com-prod' . En términos
generales, este error significa que la fuente de paquetes para .NET se está actualizando con versiones de paquetes
más recientes y que debe volver a intentarlo más tarde. Durante una actualización, la fuente de paquetes no debe
estar disponible durante más de 2 horas. Si recibe este error continuamente durante más de 2 horas, abra una
incidencia en https://github.com/dotnet/core/issues.

Dependencias
Al realizar la instalación con un administrador de paquetes, estas bibliotecas se instalan automáticamente. Pero si
instala manualmente .NET o publica una aplicación independiente, deberá asegurarse de que estas bibliotecas
estén instaladas:
krb5
libicu
libopenssl1_1
Si la versión de OpenSSL del entorno de tiempo de ejecución de destino es 1.1 o más reciente, deberá instalar
compat-openssl10 .
Para obtener más información sobre las dependencias, vea Aplicaciones de Linux independientes.
En el caso de las aplicaciones de .NET en las que se usa el ensamblado System.Drawing.Common, también se
necesitará la dependencia siguiente:
libgdiplus (versión 6.0.1 o posterior)

WARNING
Puede instalar una versión reciente de libgdiplus agregando el repositorio Mono al sistema. Para obtener más
información, vea https://www.mono-project.com/download/stable/.

Instalación con script

Los scripts de dotnet-install se usan para la automatización y las instalaciones que no son de administrador del
SDK y del Runtime . Puede descargar el script de https://dot.net/v1/dotnet-install.sh.
El valor predeterminado del script es instalar la versión más reciente del SDK de soporte técnico a largo plazo
(LTS), que actualmente es .NET Core 3.1. Para instalar la versión actual, que puede no ser una versión (LTS), use el
parámetro -c Current .

./dotnet-install.sh -c Current

Para instalar el entorno de ejecución de .NET en lugar del SDK, use el parámetro --runtime .

./dotnet-install.sh -c Current --runtime aspnetcore

Para instalar una versión específica, modifique el parámetro -c para indicar la versión específica. El comando
siguiente instala el SDK de .NET 5.0.

./dotnet-install.sh -c 5.0
Para más información, consulte la referencia de los scripts de dotnet-install.

Instalación manual
Como alternativa a los administradores de paquetes, puede descargar e instalar manualmente el SDK y el entorno
de ejecución. La instalación manual se suele llevar a cabo durante las pruebas de integración continua o en
distribuciones de Linux no admitidas. Para un desarrollador o usuario, generalmente es mejor usar un
administrador de paquetes.
Si instala el SDK de .NET, no necesita instalar el entorno de ejecución correspondiente. En primer lugar, descargue
una versión binaria del SDK o del entorno de ejecución de uno de los siguientes sitios:
✔ Descargas de .NET 5.0
️
️ Descargas de .NET Core 3.1
✔
️ Descargas de .NET Core 2.1
✔
Todas las descargas de .NET Core
A continuación, extraiga el archivo descargado y use el comando export para establecer las variables que se
utilizan en .NET. Luego, asegúrese de que .NET esté en PATH.
Para extraer el entorno de ejecución y hacer que los comandos de la CLI de .NET estén disponibles en el terminal,
en primer lugar, descargue una versión binaria de .NET. Luego, abra un terminal y ejecute los siguientes comandos
desde el directorio donde se guardó el archivo. El nombre del archivo puede ser distinto en función de lo que haya
descargado.
Use el comando siguiente para extraer el entorno de ejecución :

mkdir -p "$HOME/dotnet" && tar zxf aspnetcore-runtime-5.0.0-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

Use el comando siguiente para extraer el SDK :

mkdir -p "$HOME/dotnet" && tar zxf dotnet-sdk-5.0.100-linux-x64.tar.gz -C "$HOME/dotnet"

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet

TIP
Los comandos export anteriores solo hacen que los de la CLI de .NET estén disponibles para la sesión del terminal en la
que se ha ejecutado.
Puede editar el perfil del shell para agregar los comandos de forma permanente. Hay una serie de shells distintos disponibles
para Linux, y cada uno de ellos tiene un perfil diferente. Por ejemplo:
Shell de Bash : ~/.bash_profile, ~/.bashrc
Shell de Korn : ~/.kshrc or .profile
Shell de Z : ~/.zshrc or .zprofile
Edite el archivo de origen adecuado para el shell y agregue :$HOME/dotnet al final de la instrucción PATH existente. Si no
se incluye ninguna instrucción PATH , agregue una nueva línea con export PATH=$PATH:$HOME/dotnet .
Además, agregue export DOTNET_ROOT=$HOME/dotnet al final del archivo.

Este enfoque le permite instalar diferentes versiones en ubicaciones independientes y elegir explícitamente cuál
usará cada aplicación.
Pasos siguientes
Tutorial: Creación de una aplicación de consola con el SDK de .NET mediante Visual Studio Code
 Procedimiento para quitar el entorno de ejecución
y el SDK de .NET
18/12/2020 • 12 minutes to read • Edit Online

Con el tiempo, a medida que instale versiones actualizadas del entorno de ejecución y el SDK de .NET, es
posible que quiera quitar del equipo las versiones obsoletas de .NET. Al quitar versiones anteriores del entorno
de ejecución es posible que se cambie el elegido para ejecutar aplicaciones de marco compartido, como se
detalla en el artículo sobre selección de la versión de .NET.

¿Puedo quitar una versión?

Los comportamientos de la selección de la versión de .NET y la compatibilidad del entorno de ejecución de
.NET entre actualizaciones permite quitar de forma segura las versiones anteriores. Las actualizaciones del
entorno de ejecución de .NET son compatibles con una banda de versión principal, como 1.x y 2.x. Además,
normalmente las versiones más recientes del SDK de .NET mantienen la capacidad de crear aplicaciones
destinadas a versiones anteriores del entorno de ejecución de una forma compatible.
En general, solo se necesita el SDK más reciente y la última versión de revisión de los runtimes necesarios para
la aplicación. Los casos en los que interesa conservar versiones anteriores del SDK o del runtime incluyen el
mantenimiento de aplicaciones basadas en project.json. A menos que la aplicación tenga motivos concretos
para utilizar SDK o runtimes anteriores, puede quitar las versiones anteriores.

Determinación de lo instalado
La CLI de .NET tiene opciones que puede usar para enumerar las versiones del SDK y del entorno de ejecución
instaladas en el equipo. Use dotnet --list-sdks para ver la lista de los SDK instalados en el equipo. Use
dotnet --list-runtimes para ver la lista de los runtimes instalados en el equipo. Para obtener más información,
vea Cómo comprobar que .NET Core ya está instalado.

Desinstalación de .NET
.NET usa el cuadro de diálogo Aplicaciones y características de Windows para quitar las versiones del
entorno de ejecución y del SDK de .NET. En la siguiente ilustración se muestra el cuadro de diálogo
Aplicaciones y características . Puede buscar core sdk o .net sdk para filtrar y mostrar las versiones
instaladas de .NET.
Seleccione las versiones que quiera quitar de su equipo y haga clic en Desinstalar .
Para desinstalar .NET (el SDK o el entorno de ejecución) en Linux tiene más opciones. La mejor forma de
desinstalar .NET es repetir la misma acción que se ha usado para instalarlo. Los detalles específicos dependerán
de la distribución que elija y del método de instalación.

IMPORTANT
Para las instalaciones de Red Hat, consulte la documentación del producto Red Hat para .NET.

No es necesario desinstalar el SDK de .NET al actualizarlo mediante un administrador de paquetes, a menos

que se actualice desde una versión preliminar. Los comandos update o refresh del administrador de
paquetes quitarán automáticamente la versión anterior tras la instalación correcta de una versión más reciente.
Si tiene instalada una versión preliminar, desinstálela.
Si ha instalado .NET con un administrador de paquetes, use ese mismo administrador de paquetes para
desinstalar el SDK o el entorno de ejecución de .NET. Las instalaciones de .NET admiten los administradores de
paquetes más conocidos. Consulte la documentación del administrador de paquetes de su distribución para
conocer la sintaxis exacta en su entorno:
apt-get(8) se utiliza en sistemas basados en Debian, incluido Ubuntu.
yum(8) se utiliza en Fedora, CentOS y Oracle Linux.
zypper(8) se utiliza en openSUSE y SUSE Linux Enterprise Server (SLES).
DNF(8) se utiliza en Fedora.
En casi todos los casos, el comando para quitar un paquete es remove .
El nombre del paquete para la instalación del SDK de .NET en la mayoría de administradores de paquetes es
dotnet-sdk , seguido por el número de versión. A partir de la versión 2.1.300 del SDK de .NET y de la versión
2.1 del entorno de ejecución, solo se necesitan el primer y el segundo número de versión: por ejemplo, puede
hacer referencia a la versión 2.1.300 del SDK de .NET como el paquete dotnet-sdk-2.1 . Para las versiones
anteriores se necesita la cadena de versión completa: por ejemplo, se necesitaría dotnet-sdk-2.1.200 para la
versión 2.1.200 del SDK de .NET.
En los equipos en los que solo se ha instalado el entorno de ejecución, y no el SDK, el nombre del paquete es
dotnet-runtime-<version> para el entorno de ejecución de .NET y aspnetcore-runtime-<version> para la pila de
entorno de ejecución entera.

TIP
Al instalar las versiones de .NET Core anteriores a 2.0 no se desinstaló la aplicación host al desinstalar el SDK mediante el
administrador de paquetes. Al usar apt-get , el comando es:

apt-get remove dotnet-host

No hay ninguna versión conectada a dotnet-host .

Si ha realizado la instalación mediante un archivo tarball, debe quitar .NET mediante el método manual.
En Linux, debe quitar los SDK y runtimes por separado, quitando los directorios con versiones. De esta manera,
se elimina el SDK y el runtime del disco. Por ejemplo, para quitar el runtime y el SDK 1.0.1, tendrá que usar los
siguientes comandos de bash:

version="1.0.1"
sudo rm -rf /usr/local/share/dotnet/sdk/$version
sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.NETCore.App/$version
sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.All/$version
sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/$version
sudo rm -rf /usr/local/share/dotnet/host/fxr/$version

Los directorios primarios para el SDK y runtime se enumeran en el resultado de los comandos
dotnet --list-sdks y dotnet --list-runtimes , como se muestra en la tabla anterior.

En Mac, debe quitar los SDK y runtimes por separado, quitando los directorios con versiones. De esta manera,
se elimina el SDK y el runtime del disco. Por ejemplo, para quitar el runtime y el SDK 1.0.1, tendrá que usar los
siguientes comandos de bash:

version="1.0.1"
sudo rm -rf /usr/local/share/dotnet/sdk/$version
sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.NETCore.App/$version
sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.All/$version
sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/$version
sudo rm -rf /usr/local/share/dotnet/host/fxr/$version

Los directorios primarios para el SDK y runtime se enumeran en el resultado de los comandos
dotnet --list-sdks y dotnet --list-runtimes , como se muestra en la tabla anterior.

Herramienta de desinstalación de .NET

La herramienta de desinstalación de .NET ( dotnet-core-uninstall ) permite quitar los SDK y los entornos de
ejecución de .NET de un sistema. Hay una colección de opciones disponible para especificar las versiones que
se deben desinstalar.

Dependencia de Visual Studio en versiones de SDK de .NET Core

Antes de la versión 16.3 de Visual Studio 2019, los instaladores de Visual Studio llamaron al instalador de SDK
de .NET Core independiente. Como resultado, las versiones del SDK aparecen en el cuadro de diálogo
Aplicaciones y características de Windows. La eliminación de los SDK de .NET Core que se instalaron con
Visual Studio mediante el instalador independiente podría interrumpir Visual Studio. Si Visual Studio tiene
problemas después de desinstalar los SDK, ejecute reparar en esa versión específica de Visual Studio. En la
tabla siguiente se muestran algunas de las dependencias de Visual Studio en las versiones de SDK de .NET
Core:

VERSIÓ N DE VISUA L ST UDIO VERSIÓ N DEL SDK DE . N ET C O RE

Visual Studio 2019, versión 16.2 SDK de .NET Core 2.2.4xx, 2.1.8xx

Visual Studio 2019, versión 16.1 SDK de .NET Core 2.2.3xx, 2.1.7xx

Visual Studio 2019, versión 16.0 SDK de .NET Core 2.2.2xx, 2.1.6xx

Visual Studio 2017, versión 15.9 SDK de .NET Core 2.2.1xx, 2.1.5xx

Visual Studio 2017, versión 15.8 SDK de .NET Core 2.1.4xx

A partir de la versión 16.3 de Visual Studio 2019, Visual Studio se encarga de su propia copia del SDK de .NET.
Por ese motivo, ya no verá las versiones del SDK en el cuadro de diálogo Aplicaciones y características .

Eliminación de la carpeta de reserva de NuGet

Antes del SDK de .NET Core 3.0, los instaladores del SDK de .NET Core usaban una carpeta denominada
NuGetFallbackFolder para almacenar una memoria caché de paquetes NuGet. Esta memoria caché se utilizó
durante operaciones como dotnet restore o dotnet build /t:Restore . La carpeta NuGetFallbackFolder se
encuentra en C:\Archivos de programa\dotnet\sdk en Windows y en /usr/local/share/dotnet/sdk en macOS.
Es posible que desee quitar esta carpeta si:
Solo desarrolla con el SDK de .NET Core 3.0, .NET 5.0 o versiones posteriores.
Está desarrollando con versiones del SDK de .NET Core anteriores a la 3.0, pero puede trabajar en línea.
Si desea quitar la carpeta de reserva de NuGet, puede eliminarla, pero necesitará privilegios de administrador
para hacerlo.
No se recomienda eliminar la carpeta dotnet. Si lo hace, se quitarán las herramientas globales que haya
instalado previamente. Además, en Windows:
Interrumpirá Visual Studio 2019 versión 16.3 y versiones posteriores. Puede ejecutar Reparar para
recuperarlo.
Si hay entradas del SDK de .NET Core en el cuadro de diálogo Aplicaciones y características , se
quedarán huérfanas.
 Administración de plantillas de proyectos y elementos
de .NET
02/11/2020 • 8 minutes to read • Edit Online

.NET Core proporciona un sistema de plantillas que permite a los usuarios instalar o desinstalar plantillas de NuGet,
un archivo de paquete NuGet o un directorio del sistema de archivos. En este artículo se describe cómo administrar
plantillas de .NET Core a través de la CLI del SDK de .NET Core.
Para obtener más información sobre la creación de plantillas, consulte Tutorial: Creación de plantillas.

Instalación de plantillas
Las plantillas se instalan mediante el comando dotnet new del SDK con el parámetro -i . Puede proporcionar el
identificador de paquete NuGet de una plantilla o una carpeta que contenga los archivos de plantilla.
Paquete hospedado en NuGet
Las plantillas de la CLI de .NET se cargan en NuGet para una distribución amplia. Las plantillas también se pueden
instalar desde una fuente privada. En lugar de cargar una plantilla en una fuente de NuGet, los archivos de plantilla
de nupkg se pueden distribuir e instalar manualmente, tal como se describe en la sección Paquete NuGet local.
Para obtener más información sobre cómo configurar las fuentes de NuGet, vea dotnet nuget add source.
Para instalar un paquete de plantillas desde la fuente de NuGet predeterminada, use el comando
dotnet new -i {package-id} :

dotnet new -i Microsoft.DotNet.Web.Spa.ProjectTemplates

Para instalar un paquete de plantillas desde la fuente de NuGet predeterminada con una versión específica, use el
comando dotnet new -i {package-id}::{version} :

dotnet new -i Microsoft.DotNet.Web.Spa.ProjectTemplates::2.2.6

Paquete NuGet local

Cuando se crea un paquete de plantillas, se genera un archivo nupkg. Si tiene un archivo nupkg que contiene
plantillas, puede instalarlo con el comando dotnet new -i {path-to-package} :

dotnet new -i c:\code\nuget-packages\Some.Templates.1.0.0.nupkg

dotnet new -i ~/code/nuget-packages/Some.Templates.1.0.0.nupkg

Carpeta
Como alternativa a la instalación de una plantilla desde un archivo nupkg, también puede instalar plantillas desde
una carpeta directamente con el comando dotnet new -i {folder-path} . La carpeta especificada se trata como el
identificador del paquete de plantillas para cualquier plantilla que se encuentre. Se instalarán todas las plantillas
que estén en la jerarquía de la carpeta especificada.
 dotnet new -i c:\code\nuget-packages\some-folder\

dotnet new -i ~/code/nuget-packages/some-folder/

La ruta {folder-path} especificada en el comando se convierte en el identificador del paquete de plantillas para
todas las plantillas que se encuentren. Tal como se especifica en la sección Enumeración de las plantillas, puede
obtener una lista de las plantillas instaladas con el comando dotnet new -u . En este ejemplo, el identificador del
paquete de plantillas se muestra como la carpeta que se ha usado para la instalación:

dotnet new -u
Template Instantiation Commands for .NET Core CLI

Currently installed items:

... cut to save space ...

c:\code\nuget-packages\some-folder
Templates:
A Template Console Class (templateconsole) C#
Project for some technology (contosoproject) C#
Uninstall Command:
dotnet new -u c:\code\nuget-packages\some-folder

dotnet new -u
Template Instantiation Commands for .NET Core CLI

Currently installed items:

... cut to save space ...

/home/username/code/templates
Templates:
A Template Console Class (templateconsole) C#
Project for some technology (contosoproject) C#
Uninstall Command:
dotnet new -u /home/username/code/templates

Desinstalación de plantillas
Las plantillas se desinstalan mediante el comando dotnet new del SDK con el parámetro -u . Puede proporcionar el
identificador de paquete NuGet de una plantilla o una carpeta que contenga los archivos de plantilla.
Detección de
Una vez instalado el paquete de plantillas de NuGet, ya sea desde una fuente de NuGet o un archivo nupkg, puede
desinstalarlo mediante una referencia al identificador de paquete NuGet.
Para desinstalar un paquete de plantillas, use el comando dotnet new -u {package-id} :

dotnet new -u Microsoft.DotNet.Web.Spa.ProjectTemplates

Carpeta
Cuando las plantillas se instalan a través de una ruta de acceso de carpeta, dicha ruta se convierte en el
identificador del paquete de plantillas.
Para desinstalar un paquete de plantillas, use el comando dotnet new -u {package-folder-path} :
 dotnet new -u c:\code\nuget-packages\some-folder

dotnet new -u /home/username/code/templates

Enumeración de plantillas
Al usar el comando de desinstalación estándar sin un identificador de paquete, puede ver una lista de las plantillas
instaladas, junto con el comando que desinstala cada plantilla.

dotnet new -u
Template Instantiation Commands for .NET Core CLI

Currently installed items:

... cut to save space ...

c:\code\nuget-packages\some-folder
Templates:
A Template Console Class (templateconsole) C#
Project for some technology (contosoproject) C#
Uninstall Command:
dotnet new -u c:\code\nuget-packages\some-folder

Instalación de plantillas desde otros SDK

Si ha instalado cada versión del SDK secuencialmente (por ejemplo, si ha instalado el SDK 2.0, después el SDK 2.1,
etc.), tendrá instaladas todas las plantillas del SDK. Pero si comienza con una versión posterior del SDK, como la 3.1,
solo se incluyen las plantillas para las versiones LTS (compatibilidad a largo plazo), que en el momento de la
versión 3.1 del SDK son SDK 2.1 y el SDK 3.1. No se incluyen las plantillas para ninguna otra versión.
Las plantillas de .NET Core están disponibles en NuGet y se pueden instalar como cualquier otra plantilla. Para
obtener más información, consulte Instalación del paquete hospedado en NuGet.

SDK IDEN T IF IC A DO R DEL PA Q UET E N UGET

.NET Core 2.1 Microsoft.DotNet.Common.ProjectTemplates.2.1

.NET Core 2.2 Microsoft.DotNet.Common.ProjectTemplates.2.2

.NET Core 3.0 Microsoft.DotNet.Common.ProjectTemplates.3.0

.NET Core 3.1 Microsoft.DotNet.Common.ProjectTemplates.3.1

ASP.NET Core 2.1 Microsoft.DotNet.Web.ProjectTemplates.2.1

ASP.NET Core 2.2 Microsoft.DotNet.Web.ProjectTemplates.2.2

ASP.NET Core 3.0 Microsoft.DotNet.Web.ProjectTemplates.3.0

ASP.NET Core 3.1 Microsoft.DotNet.Web.ProjectTemplates.3.1

Por ejemplo, el SDK de .NET Core incluye plantillas para una aplicación de consola que tiene como destino .NET
Core 2.1 y .NET Core 3.1. Si quiere que el destino sea .NET Core 3.0, deberá instalar las plantillas de 3.0.
1. Pruebe a crear una aplicación destinada a .NET Core 3.0.

dotnet new console --framework netcoreapp3.0

Si ve un mensaje de error, debe instalar las plantillas.

No se pudo encontrar una plantilla instalada que coincida con la entrada. Buscando en línea una que
coincida…

2. Instale las plantillas de proyecto de .NET Core 3.0.

dotnet new -i Microsoft.DotNet.Common.ProjectTemplates.3.0

3. Pruebe a crear la aplicación otra vez.

dotnet new console --framework netcoreapp3.0

Debería ver un mensaje que indica que se ha creado el proyecto.

La plantilla "Console Application" se creó correctamente.

Procesando acciones posteriores a la creación… Ejecutando "dotnet restore" en path-to-project-
file.csproj… Determinando los proyectos que se van a restaurar… Restauración completada en 1,05 s
para path-to-project-file.csproj.
Restauración correcta.

Vea también
Tutorial: Creación de una plantilla de elemento.
dotnet new
dotnet nuget add source
 Certificación de macOS Catalina y el impacto en las
descargas y proyectos de .NET Core
02/11/2020 • 9 minutes to read • Edit Online

A partir de macOS Catalina (versión 10.15), se debe conceder la certificación a todo el software creado después
del 1 de junio de 2019 y que se distribuya con el identificador de desarrollador. Este requisito se aplica al runtime
de .NET Core, al SDK de .NET Core y al software creado con .NET Core. En este artículo se describen los escenarios
comunes con los que puede encontrarse con la certificación de .NET Core y macOS.

Instalación de .NET Core

Desde el 18 de febrero de 2020, se ha concedido la certificación a los instaladores de las versiones 3.1, 3.0 y 2.1
de .NET Core (tanto el runtime como el SDK). A las versiones publicadas anteriores no se les ha concedido la
certificación. Puede instalar manualmente una versión de .NET Core sin certificación si descarga primero el
instalador y, después, usa el comando sudo installer . Para obtener más información, vea Descarga e instalación
manual de macOS.
A partir de las versiones siguientes, los instaladores de .NET Core están certificados:
Runtime de .NET Core
2.1.16
3.0.3
3.1.2
SDK de .NET Core
2.1.512
3.0.103
3.1.102

appHost está deshabilitado de manera predeterminada

De forma predeterminada, las versiones sin certificación del SDK de .NET Core 3.0 y posteriores generan un
ejecutable Mach-O nativo (conocido como appHost ) cuando el proyecto se compila, se publica o se ejecuta. Este
ejecutable es una forma cómoda de ejecutar la aplicación. De lo contrario, la aplicación se debe iniciar mediante la
ejecución de dotnet <filename.dll> . Cuando appHost está habilitado, se invoca el comando dotnet run en el
contexto de appHost. Para obtener más información, vea Contexto de appHost.
A partir de las versiones con certificación del SDK de .NET Core 3.0 y posteriores, el archivo ejecutable appHost
no se genera de forma predeterminada. Puede activar la generación de appHost con el valor booleano
UseAppHost en el archivo del proyecto. También puede alternar appHost con el parámetro -p:UseAppHost en la
línea de comandos para el comando dotnet específico que ejecute:
Archivo del proyecto

<PropertyGroup>
<UseAppHost>true</UseAppHost>
</PropertyGroup>

Parámetro de línea de comandos

 dotnet run -p:UseAppHost=true

Siempre se crea un instancia de appHost al publicar la aplicación de manera independiente.

Para obtener más información sobre la configuración de UseAppHost , vea Propiedades de MSBuild para
Microsoft.NET.Sdk.
Contexto de appHost
Cuando appHost está habilitado en el proyecto y se usa el comando dotnet run para ejecutar la aplicación, la
aplicación se invoca en el contexto de appHost y no en el host predeterminado (que es el comando dotnet ). Si
appHost está deshabilitado en el proyecto, el comando dotnet run ejecuta la aplicación en el contexto del host
predeterminado. Incluso si appHost está deshabilitado, la publicación de la aplicación como independiente genera
un ejecutable appHost que los usuarios utilizan para ejecutar la aplicación. La ejecución de la aplicación con
dotnet <filename.dll> invoca la aplicación con el host predeterminado, el entorno de ejecución compartido.

Cuando se invoca una aplicación que usa appHost, la partición de certificado a la que accede la aplicación es
diferente del host predeterminado certificado. Si la aplicación tiene que acceder a los certificados instalados a
través del host predeterminado, use el comando dotnet run para ejecutarla desde su archivo del proyecto, o bien
use el comando dotnet <filename.dll> para iniciar la aplicación directamente.
En la sección ASP.NET Core y macOS y los certificados se proporciona más información sobre este escenario.

ASP.NET Core y macOS y los certificados

.NET Core proporciona la capacidad de administrar certificados en la cadena de claves de macOS con la clase
System.Security.Cryptography.X509Certificates. El acceso a la cadena de claves de macOS usa la identidad de las
aplicaciones como clave principal al decidir qué partición se debe tener en cuenta. Por ejemplo, las aplicaciones
sin firmar almacenan secretos en la partición sin firmar, pero las aplicaciones con firma almacenan sus secretos
en particiones a las que solo ellas pueden acceder. El origen de ejecución que invoca la aplicación decide qué
partición se va a usar.
.NET Core proporciona tres orígenes de ejecución: appHost, host predeterminado (el comando dotnet ) y un host
personalizado. Cada modelo de ejecución puede tener identidades diferentes, con firma o sin firma, y tiene acceso
a diferentes particiones dentro de la cadena de claves. Es posible que los certificados importados por un modo no
sean accesibles desde otro. Por ejemplo, las versiones certificadas de .NET Core tienen un host predeterminado
que está firmado. Los certificados se importan en una partición segura en función de su identidad. No se puede
acceder a estos certificados desde un archivo appHost generado, ya que appHost no está firmado.
Otro ejemplo, de forma predeterminada, ASP.NET Core importa un certificado SSL predeterminado a través del
host predeterminado. Las aplicaciones ASP.NET Core que usan appHost no tendrán acceso a este certificado y
recibirán un error cuando .NET Core detecte que el certificado no es accesible. El mensaje de error proporciona
instrucciones sobre cómo corregir este problema.
Si se requiere el uso compartido de certificados, macOS proporciona opciones de configuración con la utilidad
security .

Para obtener más información sobre cómo solucionar problemas de certificados de ASP.NET Core, vea Aplicación
de HTTPS en ASP.NET Core.

Derechos predeterminados
El host predeterminado de .NET Core (el comando dotnet ) tiene un conjunto de derechos predeterminados.
Estos derechos son necesarios para el funcionamiento correcto de .NET Core. Es posible que la aplicación necesite
derechos adicionales, en cuyo caso tendrá que generar y usar un archivo appHost y, después, agregar los
derechos necesarios de forma local.
Conjunto predeterminado de derechos para .NET Core:
com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.disable-library-validation

Certificación de una aplicación de .NET Core

Si quiere que la aplicación se ejecute en macOS Catalina (versión 10.15) o superior, le interesará certificarla. El
archivo appHost que envíe con la aplicación para la certificación se debe usar con al menos los mismos derechos
predeterminados para .NET Core.

Pasos siguientes
Dependencias y requisitos de .NET Core.
Instalación del runtime y SDK de .NET Core.
 Cómo comprobar que .NET Core ya está instalado
18/12/2020 • 4 minutes to read • Edit Online

En este artículo se explica cómo comprobar las versiones del entorno de ejecución y el SDK de .NET que
están instaladas en el equipo. Si tiene un entorno de desarrollo integrado, como Visual Studio o Visual Studio
para Mac, es posible que .NET ya se haya instalado.
Al instalar un SDK, se instala el entorno de ejecución correspondiente.
Si se produce un error en alguno de los comandos de este artículo, no tendrá instalado el entorno de
ejecución o el SDK. Para obtener más información, consulte los artículos de instalación para Windows,
macOS o Linux.

Comprobación de las versiones del SDK

Se pueden ver las versiones del SDK de .NET que están instaladas actualmente con un terminal. Abra un
terminal y ejecute el comando siguiente.

dotnet --list-sdks

Verá un resultado similar al siguiente.

2.1.500 [C:\program files\dotnet\sdk]

2.1.502 [C:\program files\dotnet\sdk]
2.1.504 [C:\program files\dotnet\sdk]
2.1.600 [C:\program files\dotnet\sdk]
2.1.602 [C:\program files\dotnet\sdk]
3.1.100 [C:\program files\dotnet\sdk]
5.0.100 [C:\program files\dotnet\sdk]

2.1.500 [/home/user/dotnet/sdk]
2.1.502 [/home/user/dotnet/sdk]
2.1.504 [/home/user/dotnet/sdk]
2.1.600 [/home/user/dotnet/sdk]
2.1.602 [/home/user/dotnet/sdk]
3.1.100 [/home/user/dotnet/sdk]
5.0.100 [/home/user/dotnet/sdk]

2.1.500 [/usr/local/share/dotnet/sdk]
2.1.502 [/usr/local/share/dotnet/sdk]
2.1.504 [/usr/local/share/dotnet/sdk]
2.1.600 [/usr/local/share/dotnet/sdk]
2.1.602 [/usr/local/share/dotnet/sdk]
3.1.100 [/usr/local/share/dotnet/sdk]
5.0.100 [/usr/local/share/dotnet/sdk]

Comprobación de las versiones del entorno de ejecución

Se pueden ver las versiones del entorno de ejecución de .NET que están instaladas actualmente con el
comando siguiente.
 dotnet --list-runtimes

Verá un resultado similar al siguiente.

Microsoft.AspNetCore.All 2.1.7 [c:\program files\dotnet\shared\Microsoft.AspNetCore.All]

Microsoft.AspNetCore.All 2.1.13 [c:\program files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.7 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.7 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.0 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.0 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]

Microsoft.AspNetCore.All 2.1.7 [/home/user/dotnet/shared/Microsoft.AspNetCore.All]

Microsoft.AspNetCore.All 2.1.13 [/home/user/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.7 [/home/user/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [/home/user/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0 [/home/user/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [/home/user/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.7 [/home/user/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [/home/user/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0 [/home/user/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [/home/user/dotnet/shared/Microsoft.NETCore.App]

Microsoft.AspNetCore.All 2.1.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]

Microsoft.AspNetCore.All 2.1.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Buscar carpetas de instalación

Es posible que .NET esté instalado, pero no se haya agregado a la variable PATH del sistema operativo o el
perfil de usuario. En este caso, es posible que no funcionen los comandos de las secciones anteriores. Como
alternativa, puede comprobar que existen las carpetas de instalación de .NET.
Al instalar .NET desde un instalador o un script, la instalación se efectúa en una carpeta estándar. La mayor
parte del tiempo, el instalador o el script que usa para instalar .NET le ofrece la opción de realizar la
instalación en otra carpeta. Si decide instalar en una carpeta diferente, ajuste el inicio de la ruta de acceso de
la carpeta.
archivo ejecutable de dotnet
C:\archivos de programa\dotnet\dotnet.exe
.NET SDK
C:\archivos de programa\dotnet\sdk\{versión}\
Runtime de .NET
 C:\archivos de programa\dotnet\shared\{tipo de runtime}\{versión}\
archivo ejecutable de dotnet
/home/user/share/dotnet/dotnet
.NET SDK
/home/user/share/dotnet/sdk/{versión}/
Runtime de .NET
/home/user/share/dotnet/shared/{tipo de runtime}/{versión}/
archivo ejecutable de dotnet
/usr/local/share/dotnet/dotnet
.NET SDK
/usr/local/share/dotnet/sdk/{versión}/
Runtime de .NET
/usr/local/share/dotnet/shared/{tipo de runtime}/{versión}/

Más información
Se pueden ver las versiones del SDK y del entorno de ejecución con el comando dotnet --info . También
obtendrá otra información relacionada con el entorno, como la versión del sistema operativo y el
identificador del entorno de ejecución (RID).

Pasos siguientes
Instalación del SDK y el entorno de ejecución de .NET para Windows.
Instalación del SDK y el entorno de ejecución de .NET para macOS.
Instalación del SDK y el entorno de ejecución de .NET para Linux.

Vea también
Determinación de las versiones instaladas de .NET Framework
 Procedimiento para instalar archivos de IntelliSense
localizados para .NET
18/12/2020 • 7 minutes to read • Edit Online

IntelliSense es una característica que ayuda a completar código y que está disponible en diferentes entornos de
desarrollo integrado (IDE), como Visual Studio. De manera predeterminada, al desarrollar proyectos de .NET, el SDK
solo incluye la versión en inglés de los archivos de IntelliSense. En este artículo, se explica lo siguiente:
Procedimiento para instalar la versión localizada de estos archivos.
Procedimiento para modificar la instalación de Visual Studio para usar otro idioma.

Requisitos previos
SDK de .NET Core 3.0 o una versión posterior, como el SDK de .NET 5.
Versión 16.3 de Visual Studio 2019 u otra posterior.

Descarga e instalación de los archivos de IntelliSense localizados

IMPORTANT
Para poder realizar este procedimiento, necesita tener permiso de administrador para copiar los archivos de IntelliSense en la
carpeta de instalación de .NET.

1. Vaya a la página Descarga de archivos de IntelliSense.

2. Descargue el archivo de IntelliSense en el idioma y la versión que prefiera.
3. Extraiga el contenido del archivo ZIP.
4. Vaya a la carpeta Intellisense de .NET.
a. Vaya a la carpeta de instalación de .NET. De manera predeterminada, se encuentra en %Archivos de
programa%\dotnet\packs.
b. Elija para qué SDK quiere instalar el archivo de IntelliSense y vaya a la ruta de acceso correspondiente.
Dispone de las siguientes opciones:

T IP O DE SDK PAT H

.NET 5+ y .NET Core Microsoft.NETCore.App.Ref

Escritorio de Windows Microsoft.WindowsDesktop.App.Ref

.NET Standard NETStandard.Library.Ref

c. Vaya a la versión para la que quiera instalar el archivo de IntelliSense localizado. Por ejemplo, 5.0.0.
d. Abra la carpeta ref.
e. Abra la carpeta del moniker. Por ejemplo, net5.0.
Así pues, la ruta de acceso completa tendrá un aspecto similar al siguiente: C:\Archivos de
 programa\dotnet\packs\Microsoft.NETCore.App.Ref\5.0.0\ref\net5.0.
5. Cree una subcarpeta en la carpeta del moniker que acaba de abrir. El nombre de la carpeta indicará el idioma
que quiere usar. En la siguiente tabla, se especifican las diferentes opciones:

L EN GUA JE N O M B RE DE C A RP ETA

Portugués (Brasil) pt-br

Chino simplificado zh-hans

Chino tradicional zh-hant

Francés fr

Alemán de

Italiano it

Japonés ja

Coreano ko

Ruso ru

Español es

6. Copie en esta nueva carpeta los archivos .xml que ha extraído en el paso 3. Los archivos .xml se mostrarán
agrupados según las diferentes carpetas de SDK, de modo que debe copiarlos en la del SDK que haya
elegido en el paso 4.

Modificación del idioma de Visual Studio

Para que Visual Studio use otro idioma para IntelliSense, instale el paquete de idioma correspondiente. Esto se
puede realizar durante la instalación o después modificando la instalación de Visual Studio. Si ya tiene Visual Studio
configurado en el idioma que quiere, su instalación de IntelliSense está lista.
Instalación del paquete de idioma
Si no ha instalado el paquete de idioma deseado durante la configuración, actualice Visual Studio como se indica a
continuación para instalar el paquete de idioma:

IMPORTANT
Para instalar, actualizar o modificar Visual Studio, debe iniciar sesión con una cuenta que tenga permisos de administrador.
Para obtener más información, consulte Permisos de usuario y Visual Studio.

1. Busque el instalador de Visual Studio en su equipo.

Por ejemplo, en un equipo que ejecuta Windows 10, seleccione Iniciar y, después, desplácese hasta la letra I
donde lo verá como Instalador de Visual Studio .
 NOTE
También pude encontrar el instalador de Visual Studio en la siguiente ubicación:
C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe

Es posible que tenga que actualizar el instalador antes de continuar. De ser así, siga las indicaciones.
2. En el instalador, busque la edición de Visual Studio a la que quiera agregar el paquete de idioma y, luego,
elija Modificar .

IMPORTANT
Si no ve el botón Modificar , pero sí el botón Actualizar , significa que necesita actualizar su versión de Visual Studio
para poder modificar su instalación. Cuando haya finalizado la actualización, aparecerá el botón Modificar .

3. En la pestaña Paquetes de idioma , seleccione o anule la selección de los idiomas que quiera instalar o
 desinstalar.

4. Elija Modificar . Se inicia la actualización.

Modificación de la configuración de idioma en Visual Studio
Una vez que haya instalado los paquete de idioma deseados, modifique la configuración de Visual Studio para usar
otro idioma:
1. Abra Visual Studio.
2. En la ventana de inicio, elija Continuar sin código .
3. En la barra de menús, seleccione Herramientas > Opciones . Se abrirá el cuadro de diálogo Opciones.
4. En el nodo Entorno , seleccione Configuración internacional .
5. En la lista desplegable Idioma , seleccione el que quiera usar. Elija Aceptar .
6. Aparecerá un cuadro de diálogo en el que se le informará de que debe reiniciar Visual Studio para que se
apliquen los cambios. Elija Aceptar .
7. Reinicie Visual Studio.
Después de esto, IntelliSense deberá funcionar según lo esperado al abrir un proyecto de .NET que tenga como
destino la versión de los archivos de IntelliSense que acaba de instalar.

Vea también
IntelliSense en Visual Studio
 Introducción a .NET
18/12/2020 • 31 minutes to read • Edit Online

.NET es una plataforma de desarrollo gratuita de código abierto para compilar muchos tipos de aplicaciones,
como las siguientes:
Aplicaciones web, API web y microservicios
Funciones sin servidor en la nube
Aplicaciones nativas de la nube
Aplicaciones móviles
Aplicaciones de escritorio
Windows WPF
Windows Forms
Plataforma universal de Windows (UWP)
Juegos
Internet de las cosas (IoT)
Aprendizaje automático
Aplicaciones de consola
Servicios de Windows
Comparta la funcionalidad entre diferentes aplicaciones y tipos de aplicación mediante bibliotecas de clases.
Con .NET, el código y los archivos del proyecto tienen el mismo aspecto, con independencia del tipo de aplicación
que compile. Con cada aplicación tiene acceso a las mismas funcionalidades de tiempo de ejecución, API y
lenguaje.

Multiplataforma
Puede crear aplicaciones .NET para muchos sistemas operativos, entre los que se incluyen los siguientes:
Windows
macOS
Linux
Android
iOS
tvOS
watchOS
Las arquitecturas de procesador compatibles incluyen las siguientes:
x64
x86
ARM32
ARM64
.NET le permite usar funcionalidades específicas de la plataforma, como las API del sistema operativo. Algunos
ejemplos son Windows Forms y WPF en Windows, y los enlaces nativos a cada plataforma móvil desde Xamarin.
Para obtener más información, vea Directiva de ciclo de vida del sistema operativo compatible y Catálogo de
.NET RID.

Código abierto
.NET es de código abierto y usa las licencias de MIT y Apache 2. .NET es un proyecto de .NET Foundation.
Para obtener más información, vea la lista de repositorios de proyectos en GitHub.com.

Soporte técnico
Microsoft admite .NET en Windows, macOS y Linux. Se actualiza de forma periódica por motivos de seguridad y
calidad, el segundo martes de cada mes.
Las distribuciones binarias de .NET de Microsoft se compilan y prueban en servidores mantenidos por Microsoft
en Azure y siguen los procedimientos de seguridad e ingeniería de Microsoft.
Red Hat admite .NET en Red Hat Enterprise Linux (RHEL). Red Hat y Microsoft colaboran para asegurarse de que
.NET Core funciona bien en RHEL.
Tizen admite .NET en las plataformas Tizen.
Para obtener más información, vea Versiones y compatibilidad con .NET Core y .NET 5.

Herramientas y productividad
.NET ofrece una selección de lenguajes, entornos de desarrollo integrados (IDE) y otras herramientas.
Lenguajes de programación
.NET admite tres lenguajes de programación:
C#
C# (pronunciado "si sharp" en inglés) es un lenguaje de programación moderno, basado en objetos y con
seguridad de tipos. C# tiene sus raíces en la familia de lenguajes C, y a los programadores de C, C++, Java
y JavaScript les resultará familiar inmediatamente.
F#
El lenguaje F# admite los modelos de programación funcional, orientada a objetos e imperativa.
Visual Basic
Entre los lenguajes de .NET, la sintaxis de Visual Basic es la más parecida al lenguaje humano normal, lo
que facilita su aprendizaje. A diferencia de C# y F#, para los que Microsoft desarrolla nuevas características
de forma activa, el lenguaje Visual Basic es estable. Visual Basic no es compatible con las aplicaciones web,
pero sí con las API web.
Estas son algunas de las funcionalidades que admiten los lenguajes de .NET:
Seguridad de tipos
Inferencia de tipos: C#, F#, Visual Basic
Tipos genéricos
Delegados
Expresiones lambda
Eventos
Excepciones
Atributos
 Código asincrónico
Programación en paralelo en .NET
Analizadores de código
IDE
Los entornos de desarrollo integrado para .NET incluyen los siguientes:
Visual Studio
Solo se ejecuta en Windows. Dispone de una amplia funcionalidad integrada diseñada para trabajar con
.NET. La edición Community es gratuita para estudiantes, colaboradores de código abierto y particulares.
Visual Studio Code
Es compatible con Windows, macOS y Linux. De código abierto y gratuito. Hay extensiones disponibles
para trabajar con lenguajes de .NET.
Visual Studio para Mac
Solo se ejecuta en macOS. Para desarrollar aplicaciones y juegos de .NET para iOS, Android y la web.
GitHub Codespaces
Un entorno de Visual Studio Code en línea, actualmente en versión beta.
SDK y entornos de ejecución
El SDK de .NET es un conjunto de bibliotecas y herramientas para desarrollar y ejecutar aplicaciones .NET.
Al descargar .NET, puede elegir el SDK o un entorno de ejecución, como el de .NET o el de ASP.NET Core. Instale
un entorno de ejecución en un equipo que quiera preparar para ejecutar aplicaciones .NET. Instale el SDK en un
equipo que quiera usar para el desarrollo. Al descargar el SDK, obtiene automáticamente los entornos de
ejecución.
La descarga del SDK incluye los componentes siguientes:
La CLI de .NET. Herramientas de la línea de comandos que puede usar para scripts de desarrollo local e
integración continua.
El controlador dotnet . Un comando de la CLI que ejecuta aplicaciones dependientes del marco.
Los compiladores de los lenguajes de programación Roslyn y F#.
El motor de compilación MSBuild.
El entorno de ejecución de .NET. Proporciona un sistema de tipos, la carga de ensamblados, un recolector de
elementos no utilizados, interoperabilidad nativa y otros servicios básicos.
Bibliotecas tiempo de ejecución. Proporciona tipos de datos primitivos y utilidades fundamentales.
El entorno de ejecución de ASP.NET Core. Proporciona servicios básicos para las aplicaciones conectadas a
Internet, como aplicaciones web, aplicaciones de IoT y back-ends para dispositivos móviles.
El entorno de ejecución de escritorio. Proporciona servicios básicos para las aplicaciones de escritorio de
Windows, como Windows Forms y WPF.
Para obtener más información, vea los siguientes recursos:
Información general sobre el SDK de .NET
Información general sobre la CLI de .NET
comando dotnet
Sistema del proyecto y MSBuild
Una aplicación .NET se crea a partir de código fuente mediante MSBuild. Un archivo del proyecto ( .csproj, .fsproj
o .vbproj) especifica destinos y tareas asociadas que se encargan de compilar, empaquetar y publicar código.
Existen identificadores de SDK que hacen referencia a colecciones estándar de destinos y tareas. El uso de estos
identificadores ayuda a reducir el tamaño de los archivos del proyecto y facilita el trabajo con ellos. Por ejemplo,
este es un archivo del proyecto para una aplicación de consola:

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>

Y este es otro para una aplicación web:

<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>

En estos ejemplos, el atributo Sdk del elemento Project especifica un conjunto de destinos y tareas de MSBuild
que compilan el proyecto. El elemento TargetFramework especifica la versión de .NET de la que depende la
aplicación. Puede editar el archivo del proyecto para agregar destinos y tareas adicionales específicos del
proyecto.
Para obtener más información, vea Información general sobre el SDK de proyectos .NET y Plataformas de destino.
CI/CD
MSBuild y la CLI de .NET se pueden usar con diversas herramientas y entornos de integración continua, como:
Acciones de GitHub
Azure DevOps
CAKE
FAKE
Para obtener más información, vea Uso del SDK de .NET y herramientas de integración continua (CI)
NuGet
NuGet es un administrador de paquetes de código abierto diseñado para .NET. Un paquete NuGet es un archivo
.zip con la extensión .nupkg que contiene código compilado (archivos DLL), otros archivos relacionados con ese
código y un manifiesto descriptivo que incluye información como el número de versión del paquete. Los
desarrolladores con código para compartir crean paquetes y los publican en nuget.org o un host privado. Los
desarrolladores que quieren usar código compartido agregan un paquete a su proyecto y, después, pueden
llamar a la API expuesta por el paquete en el código del proyecto.
Para obtener más información, vea la documentación de NuGet.
Documentación interactiva de .NET
.NET Interactive es un grupo de API y herramientas de la CLI que permiten a los usuarios crear experiencias
interactivas en la web, markdown y cuadernos.
Para obtener más información, vea los siguientes recursos:
Tutorial de .NET en el explorador
Uso de cuadernos de .NET con Jupyter en el equipo
Documentación de .NET Interactive
Modelos de ejecución
Las aplicaciones .NET ejecutan código administrado en un entorno de tiempo de ejecución conocido como
Common Language Runtime (CLR).
CLR
El CLR de .NET es un entorno de ejecución multiplataforma que incluye compatibilidad con Windows, macOS y
Linux. CLR controla la asignación y administración de memoria. El CLR es además una máquina virtual que no
solo ejecuta aplicaciones, sino que también genera y compila código mediante un compilador Just-In-Time (JIT).
Para obtener más información, vea Información general de Common Language Runtime (CLR).
Compilador JIT y lenguaje intermedio
Los lenguajes .NET de nivel alto, como C#, compilan en un conjunto de instrucciones independiente del hardware,
lo que se denomina lenguaje intermedio (IL). Cuando se ejecuta una aplicación, el compilador JIT convierte el
lenguaje intermedio en código máquina comprensible para el procesador. La compilación JIT se produce en el
mismo equipo en el que se va a ejecutar el código.
Como la compilación JIT tiene lugar durante la ejecución de la aplicación, el tiempo de compilación es parte del
tiempo de ejecución. Por tanto, los compiladores JIT tienen que compensar el tiempo invertido en optimizar el
código con el ahorro que puede generar el código resultante. Pero un compilador JIT conoce el hardware real y
puede liberar a los desarrolladores de tener que enviar diferentes implementaciones para distintas plataformas.
El compilador JIT de .NET puede realizar la compilación en niveles, lo que significa que puede volver a compilar
métodos concretos en tiempo de ejecución. Esta característica le permite compilar rápidamente mientras todavía
puede generar una versión muy optimizada del código para los métodos que se usan con frecuencia.
Para obtener más información, vea Proceso de ejecución administrada y Compilación en niveles.
Compilador AOT
La experiencia predeterminada para la mayoría de las cargas de trabajo de .NET es el compilador JIT, pero .NET
ofrece dos formas de compilación anticipada (AOT):
Algunos escenarios requieren una compilación AOT del 100 %. Un ejemplo es iOS.
En otros escenarios, la mayor parte del código de una aplicación se compilada mediante AOT, pero otra
mediante JIT. Algunos patrones de código no son descriptivos para AOT (como los genéricos). Un ejemplo de
este tipo de compilación AOT es la opción de publicación listo para ejecutar. Esta forma de AOT ofrece las
ventajas de AOT sin sus inconvenientes.
Administración de memoria automática
El recolector de elementos no utilizados (GC) administra la asignación y liberación de la memoria para las
aplicaciones. Cada vez que el código crea un objeto, el CLR le asigna memoria del montón administrado. Siempre
que haya espacio de direcciones disponible en el montón nativo, el motor en tiempo de ejecución continúa
asignando espacio a los objetos nuevos. Cuando no queda suficiente espacio de direcciones libre, el GC
comprueba los objetos del montón administrado que la aplicación ya no usa. Después, reclama esa memoria.
El recolector de elementos no utilizados es uno de los servicios del CLR que ayudan a garantizar la protección de
la memoria. Un programa tiene protección de la memoria si tiene acceso solo a la memoria asignada. Por
ejemplo, el entorno de ejecución garantiza que una aplicación no accede a memoria sin asignar más allá de los
límites de una matriz.
Para obtener más información, vea Administración de memoria automática y Fundamentos de la recolección de
elementos no utilizados.
Trabajar con recursos no administrados
En ocasiones el código debe hacer referencia a recursos no administrados. Los recursos no administrados son
recursos que el entorno de ejecución .NET no mantiene de forma automática. Por ejemplo, un identificador de
archivo es un recurso no administrado. Un objeto FileStream es un objeto administrado, pero hace referencia a un
identificador de archivo, que es uno no administrado. Cuando haya acabado de usar FileStream, tiene que liberar
de forma explícita el identificador de archivo.
En .NET, los objetos que hacen referencia a recursos no administrados implementan la interfaz de IDisposable.
Cuando haya acabado de usar el objeto, deberá llamar al método Dispose() del objeto, que es el responsable de
liberar cualquier recurso no administrado. Los lenguajes de .NET proporcionan una práctica instrucción using
(C#, F#, VB) que garantiza la llamada al método Dispose .
Para obtener más información, vea Limpieza de recursos no administrados.

Modelos de implementación
Las aplicaciones .NET se pueden publicar en dos modos diferentes:
La publicación de una aplicación como independiente genera un archivo ejecutable que incluye el entorno
de ejecución y las bibliotecas de .NET, así como la aplicación y sus dependencias. Los usuarios de la
aplicación pueden ejecutarla en un equipo que no tenga instalado el entorno de ejecución de .NET. Las
aplicaciones independientes son específicas de la plataforma y, opcionalmente, se pueden publicar
mediante una forma de compilación AOT.
La publicación de una aplicación como dependiente del marco genera un archivo ejecutable y archivos
binarios (archivos .dll) que solo incluyen la propia aplicación y sus dependencias. Los usuarios de la
aplicación tienen que instalar el entorno de ejecución de .NET por separado. El archivo ejecutable es
específico de la plataforma, pero los archivos .dll de las aplicaciones dependientes del marco son
multiplataforma.
Puede instalar varias versiones del tiempo de ejecución en paralelo para ejecutar aplicaciones
dependientes del marco destinadas a otras versiones del tiempo de ejecución. Para obtener más
información, vea Plataformas de destino.
Los archivos ejecutables se generan para plataformas de destino concretas, que se especifican con un
identificador en tiempo de ejecución (RID).
Para obtener más información, vea Información general sobre la publicación de aplicaciones .NET e Introducción a
.NET y Docker.

Bibliotecas en tiempo de ejecución

.NET tiene un amplio conjunto estándar de bibliotecas de clases, conocidas como bibliotecas en tiempo de
ejecución, bibliotecas de marco o la biblioteca de clases base (BCL). Estas bibliotecas proporcionan
implementaciones para muchos tipos de propósito general y específicos de la carga de trabajo, y funcionalidad de
la utilidad.
Estos son algunos ejemplos de los tipos definidos en las bibliotecas en tiempo de ejecución de .NET:
Tipos primitivos, como System.Boolean y System.Int32.
Colecciones, como System.Collections.Generic.List<T> y System.Collections.Generic.Dictionary<TKey,TValue>.
Tipos de datos, como System.Data.DataSet y System.Data.DataTable.
Tipos de utilidad de red, como System.Net.Http.HttpClient.
Tipos de utilidad de E/S de archivos y secuencias, como System.IO.FileStream y System.IO.TextWriter.
Tipos de utilidad de serialización, como System.Text.Json.JsonSerializer y
System.Xml.Serialization.XmlSerializer.
Tipos de alto rendimiento, como System.Span<T>, System.Numerics.Vector y Canalizaciones.
Para obtener más información, vea Introducción a las bibliotecas en tiempo de ejecución. El código fuente de las
bibliotecas está en el repositorio dotnet/runtime de GitHub.
Extensiones de las bibliotecas en tiempo de ejecución
Las bibliotecas de algunas funcionalidades de aplicación de uso común no se incluyen en las bibliotecas en
tiempo de ejecución, sino que están disponibles en paquetes NuGet como los siguientes:

PA Q UET E DE N UGET DO C UM EN TA C IÓ N

Microsoft.Extensions.Hosting Administración de la duración de la aplicación (host genérico)

Microsoft.Extensions.DependencyInjection Inserción de dependencias (ID)

Microsoft.Extensions.Configuration Configuración

Microsoft.Extensions.Logging Logging

Microsoft.Extensions.Options Patrón de opciones

Para obtener más información, vea el repositorio dotnet/extensions en GitHub.

Acceso a datos
.NET proporciona un asignador relacional/de objeto (ORM) y una manera de escribir consultas SQL en el código.
Entity Framework Core
Entity Framework (EF) Core es una tecnología de acceso a datos multiplataforma y de código abierto que puede
servir como ORM. EF Core le permite trabajar con una base de datos si hace referencia a los objetos .NET en el
código. Reduce la cantidad de código de acceso a datos que, de lo contrario, tendría que escribir y probar. EF Core
es compatible con muchos motores de base de datos.
Para obtener más información, vea Entity Framework Core y Proveedores de base de datos.
LINQ
Language Integrated Query (LINQ) permite escribir código declarativo para trabajar en los datos. Los datos
pueden estar en muchos formatos (como objetos en memoria, una base de datos SQL o un documento XML),
pero el código LINQ que escriba normalmente no es diferente según el origen de datos.
Para obtener más información, vea Información general de LINQ (Language Integrated Query).

Terminología de .NET
Para entender la documentación de .NET, puede ser de ayuda saber cómo ha cambiado el uso de algunos
términos con el tiempo.
.NET Core y .NET 5
En 2002, Microsoft publicó .NET Framework, una plataforma de desarrollo para la creación de aplicaciones
Windows. En la actualidad, .NET Framework se encuentra en la versión 4.8 y Microsoft todavía la admite.
En 2014, Microsoft comenzó a escribir un sucesor multiplataforma de código abierto para .NET Framework. Esta
nueva implementación de .NET se denominó .NET Core hasta que alcanzó la versión 3.1. La siguiente versión
después de .NET Core 3.1 es .NET 5.0, que actualmente se encuentra en versión preliminar. Se omitió el número
de versión 4 para evitar la confusión entre esta implementación de .NET y .NET Framework 4.8. El nombre "Core"
se quitó para aclarar que ahora esta es la implementación principal de .NET.
Este artículo trata sobre .NET 5, pero en gran parte de la documentación de .NET 5 todavía se incluyen referencias
a ".NET Core" o ".NET Framework". Además, "Core" permanece en los nombres ASP.NET Core y Entity
Framework Core.
En la documentación también se hace referencia a .NET Standard. .NET Standard es una especificación de API que
permite desarrollar bibliotecas de clases para varias implementaciones de .NET.
Para obtener más información, vea Componentes de la arquitectura de .NET.
Términos sobrecargados
Parte de la terminología de .NET puede resultar confusa porque la misma palabra se usa de maneras diferentes
en contextos distintos. Estos son algunos de los casos más destacados:
motor en tiempo de ejecución

C O N T EXT SIGN IF IC A DO DE " RUN T IM E"

Common Language Runtime (CLR) El entorno de ejecución de un programa administrado. El

sistema operativo forma parte del entorno de tiempo de
ejecución, pero no del tiempo de ejecución de .NET.

Entorno de ejecución de .NET en la página de descarga de El CLR y las bibliotecas en tiempo de ejecución, que de
.NET manera conjunta proporcionan compatibilidad para
ejecutar aplicaciones dependientes del marco de trabajo.
En la página también se ofrecen opciones de tiempo de
ejecución para aplicaciones de servidor de ASP.NET Core y
aplicaciones de escritorio de Windows.

Identificador en tiempo de ejecución (RID) La plataforma del sistema operativo y la arquitectura de la

CPU en la que se ejecuta una aplicación .NET. Por ejemplo:
Windows x64, Linux x64.

marco de trabajo

C O N T EXT SIGN IF IC A DO DE " M A RC O "

.NET Framework La implementación original de .NET, solo para Windows.

La "F" de "Framework" está en mayúsculas.

versión de .NET Framework de destino La colección de API de las que depende una aplicación o
biblioteca de .NET. Ejemplos: .NET Core 3.1,
.NET Standard 2.0

Moniker de la plataforma de destino (TFM) TFM es un formato de token normalizado para especificar
la plataforma de destino de una aplicación o biblioteca de
.NET. Ejemplo: net462 para .NET Framework 4.6.2.

Aplicación dependiente de la plataforma Una aplicación que solo se puede ejecutar en un equipo
en el que se ha instalado el tiempo de ejecución desde la
página de descargas de .NET. En este caso, "marco" es lo
mismo que el "tiempo de ejecución" que se descarga de la
página de descargas de .NET.

Bibliotecas de marco A veces se usa como sinónimo de las bibliotecas en

tiempo de ejecución.

SDK
 C O N T EXT SIGN IF IC A DO DE " SDK "

SDK en la página de descargas de .NET Una colección de herramientas y bibliotecas que se

descargan e instalan para desarrollar y ejecutar
aplicaciones .NET. Incluye la CLI, MSBuild, el entorno de
tiempo de ejecución de .NET y otros componentes.

Proyecto de estilo SDK Conjunto de destinos y tareas de MSBuild que especifica

cómo compilar un proyecto para un tipo de aplicación
concreto. En este sentido, el SDK se especifica mediante el
atributo Sdk del elemento Project en un archivo del
proyecto.

platform

C O N T EXT SIGN IF IC A DO DE " P L ATA F O RM A "

multiplataforma En este término, "plataforma" significa un sistema

operativo y el hardware en que se ejecuta, como
Windows, macOS, Linux, iOS y Android.

Plataforma .NET El uso varía. La referencia puede ser una implementación

de .NET (como .NET Framework o .NET 5), o bien un
concepto general de .NET que incluye todas las
implementaciones.

Para obtener más información sobre la terminología de .NET, vea el Glosario de .NET.

Escenarios avanzados
En las secciones siguientes se explican algunas de las funciones de .NET que son útiles en escenarios avanzados.
Interoperabilidad nativa
Cada sistema operativo incluye una interfaz de programación de aplicaciones (API) que proporciona servicios del
sistema. .NET proporciona varias maneras de llamar a esas API.
La principal manera de interoperar con API nativas es a través de la "invocación de plataforma" (o P/Invoke para
abreviar). P/Invoke se admite en las plataformas Windows y Linux. Una manera de interoperabilidad nativa
exclusiva de Windows se denomina "Interoperabilidad COM", que se usa con componentes COM en código
administrado. Se basa en la infraestructura de P/Invoke, pero funciona de forma ligeramente diferente.
Para obtener más información, vea Interoperabilidad nativa.
Código no seguro
Según la compatibilidad con el lenguaje, CLR le permite tener acceso a memoria nativa y usar la aritmética de
punteros a través de código unsafe . Estas operaciones son necesarias para determinados algoritmos y para la
interoperabilidad del sistema. Aunque es eficaz, se desaconseja el uso de código no seguro a menos que sea
necesario para la interoperabilidad con las API del sistema o para implementar el algoritmo más eficaz. Es posible
que el código no seguro no se ejecute del mismo modo en entornos diferentes y que también pierda las ventajas
de un recolector de elementos no utilizados y de la seguridad de tipos. Se recomienda limitar y centralizar el
código no seguro lo máximo posible, y probar el código a conciencia.
Para obtener más información, vea Código no seguro y punteros.

Pasos siguientes
Elección de un tutorial de .NET
Prueba de .NET en el explorador
Un paseo por C#
Un paseo por F#
 Componentes de la arquitectura .NET
18/12/2020 • 10 minutes to read • Edit Online

Una aplicación de .NET se desarrolla y se ejecuta en una o varias implementaciones de .NET. Las implementaciones
de .NET incluyen .NET Framework, .NET 5 (y .NET Core) y Mono. Hay una especificación de API común a varias
implementaciones de .NET que se denomina .NET Standard. En este artículo, se ofrece una breve introducción a
cada uno de estos conceptos.

.NET Standard
.NET Standard es un conjunto de API que se implementan mediante la biblioteca de clases base de una
implementación de .NET. Más formalmente, es una especificación de API de .NET que constituyen un conjunto
uniforme de contratos contra los que se compila el código. Estos contratos se implementan en varias
implementaciones de .NET.
.NET Standard es una plataforma de destino. Si el código tiene como destino una versión de .NET Standard, se
puede ejecutar en cualquier implementación de .NET que sea compatible con esa versión de .NET Standard.
.NET Standard se creó para permitir la portabilidad en diferentes implementaciones de .NET, pero ahora .NET 5
ofrece una mejor manera de compartir código entre varias plataformas y cargas de trabajo. Para obtener más
información, vea .NET 5 y .NET Standard.

Implementaciones de .NET
Cada implementación de .NET incluye los siguientes componentes:
Uno o varios entornos de ejecución. Ejemplos: CLR de .NET Framework, CLR de .NET 5.
Una biblioteca de clases. Ejemplos: biblioteca de clases base de .NET Framework, biblioteca de clases base de
.NET 5.
Opcionalmente, uno o varios marcos de trabajo de la aplicación. Ejemplos: ASP.NET, Windows Forms y
Windows Presentation Foundation (WPF) se incluyen en .NET Framework y .NET 5.
Opcionalmente, herramientas de desarrollo. Algunas herramientas de desarrollo se comparten entre varias
implementaciones.
Microsoft admite cuatro implementaciones de .NET:
.NET 5 (y .NET Core) y versiones posteriores
.NET Framework
Mono
UWP
.NET 5 es ahora la implementación principal, la que recibe desarrollo continuo. .NET 5 se basa en una única base de
código que admite varias plataformas y muchas cargas de trabajo, como aplicaciones de escritorio de Windows y
aplicaciones de consola multiplataforma, servicios en la nube y sitios web.
.NET 5
.NET 5 es una implementación multiplataforma de .NET diseñada para controlar cargas de trabajo de servidor y en
la nube a escala. También admite otras cargas de trabajo, incluidas las aplicaciones de escritorio. Se ejecuta en
Windows, macOS y Linux. Implementa .NET Standard, de forma que cualquier código que tenga como destino .NET
Standard se puede ejecutar en .NET 5. ASP.NET Core, Windows Forms y Windows Presentation Foundation (WPF)
se ejecutan en .NET 5.
Para obtener más información, vea los siguientes recursos:
Introducción a .NET
Elección entre .NET 5 y .NET Framework para aplicaciones de servidor
.NET 5 y .NET Standard
.NET Framework
.NET Framework es la implementación de .NET original que existe desde 2002. Las versiones 4.5 y posteriores
implementan .NET Standard, de forma que el código que tiene como destino .NET Standard se puede ejecutar en
esas versiones de .NET Framework. Contiene API específicas de Windows adicionales, como API para el desarrollo
de escritorio de Windows con Windows Forms y WPF. .NET Framework está optimizado para crear aplicaciones de
escritorio de Windows.
Para obtener más información, vea la guía de .NET Framework.
Mono
Mono es una implementación de .NET que se usa principalmente cuando se requiere un entorno de ejecución
pequeño. Es el entorno de ejecución que activa las aplicaciones Xamarin en Android, macOS, iOS, tvOS y watchOS,
y se centra principalmente en una superficie pequeña. Mono también proporciona juegos creados con el motor de
Unity.
Admite todas las versiones de .NET Standard publicadas actualmente.
Históricamente, Mono implementaba la API de .NET Framework más grande y emulaba algunas de las funciones
más populares en Unix. A veces, se usa para ejecutar aplicaciones de .NET que se basan en estas capacidades en
Unix.
Mono se suele usar con un compilador Just-In-Time, pero también incluye un compilador estático completo
(compilación Ahead Of Time) que se usa en plataformas como iOS.
Para obtener más información, vea la documentación de Mono.
Plataforma universal de Windows (UWP)
UWP es una implementación de .NET que se usa para compilar aplicaciones Windows modernas y táctiles y
software para Internet de las cosas (IoT). Se ha diseñado para unificar los diferentes tipos de dispositivos de
destino, incluidos equipos, tabletas, teléfonos e incluso la consola Xbox. UWP proporciona muchos servicios, como
una tienda de aplicaciones centralizada, un entorno de ejecución (AppContainer) y un conjunto de API de Windows
para usar en lugar de Win32 (WinRT). Pueden escribirse aplicaciones en C++, C#, Visual Basic y JavaScript.
Para obtener más información, vea Introducción a la Plataforma universal de Windows.

Entornos de tiempo de ejecución .NET

Un entorno de ejecución es el entorno de ejecución de un programa administrado. El sistema operativo forma
parte del entorno de ejecución, pero no del entorno de ejecución .NET. Estos son algunos ejemplos de los entornos
de ejecución .NET:
Common Language Runtime (CLR) para .NET Framework
Common Language Runtime (CLR) para .NET 5
.NET Native para la Plataforma universal de Windows
El entorno de ejecución Mono para Xamarin.iOS, Xamarin.Android, Xamarin.Mac y el marco de escritorio de
Mono

Herramientas de .NET e infraestructura común

Tiene acceso a un amplio conjunto de herramientas y componentes de infraestructura que funcionan con todas las
implementaciones de .NET. Estas herramientas y componentes incluyen:
Los lenguajes .NET y sus compiladores
El sistema de proyectos de .NET (basado en archivos .csproj, .vbproj y .fsproj)
MSBuild, el motor de compilación usado para compilar proyectos
NuGet, administrador de paquetes de Microsoft para .NET
Herramientas de organización de compilación de código abierto, como CAKE y FAKE
Para obtener más información, vea Herramientas y productividad.

Estándares aplicables
El lenguaje C# y las especificaciones de Common Language Infrastructure (CLI) se normalizan a través de Ecma
International®. Las primeras ediciones de estos estándares las publicó ECMA en diciembre de 2001.
Las revisiones posteriores de los estándares las han desarrollado los grupos de tareas TC49-TG2 (C#) y TC49-TG3
(CLI) en el Comité Técnico de Lenguajes de Programación (TC49) y adoptadas por la Asamblea general de ECMA y,
posteriormente, por ISO/IEC JTC 1 a través del proceso Fast-Track de ISO.
Estándares más recientes
Los siguientes documentos oficiales de ECMA están disponibles para C# y la CLI (TR-84):
El estándar del lenguaje C# (versión 5.0) : ECMA-334.pdf
Common Language Infrastructure : disponible en los formatos pdf y zip.
Información derivada del archivo XML de la par te IV : disponible en los formatos pdf y zip.
Los documentos ISO/IEC oficiales están disponibles en la página ISO/IEC Estándares disponibles públicamente.
Estos vínculos son directos de esa página:
Tecnología de la información: lenguajes de programación, C# : ISO/IEC 23270:2018
Tecnologías de la información: Common Language Infrastructure (CLI), par tes I a VI : ISO/IEC
23271:2012
Tecnología de la información: Common Language Infrastructure (CLI); informe técnico sobre la
información derivada del archivo XML de la par te IV : ISO/IEC TR 23272:2011

Vea también
Introducción a .NET
Introducción a .NET Standard
Elección entre .NET 5 y .NET Framework para aplicaciones de servidor
Guía de .NET Framework
Guía de C#
Guía de F#
Guía de Visual Basic
 Bibliotecas de clases de .NET
18/12/2020 • 7 minutes to read • Edit Online

Las bibliotecas de clases son el concepto de biblioteca compartida de .NET. Le permiten dividir funcionalidades
útiles en módulos que pueden usar varias aplicaciones. También se pueden usar para cargar la funcionalidad no
necesaria o no conocida al inicio de la aplicación. Las bibliotecas de clases se describen mediante el formato de
archivo de Ensamblado de .NET.
Hay tres tipos de bibliotecas de clases que puede usar:
Las bibliotecas de clases específicas de la plataforma tienen acceso a todas las API de una plataforma
determinada (por ejemplo, .NET Framework, Xamarin iOS), pero solo las pueden usar las aplicaciones y
bibliotecas destinadas a esa plataforma.
Las bibliotecas de clases por tables tienen acceso a un subconjunto de API y las pueden usar las aplicaciones y
bibliotecas que tienen como destino varias plataformas.
Las bibliotecas de clases de .NET Standard son una fusión del concepto de biblioteca específica de la
plataforma y portable en un único modelo que ofrece lo mejor de ambas.

Bibliotecas de clases específicas de la plataforma

Las bibliotecas específicas de la plataforma se enlazan a una única implementación de .NET (por ejemplo, .NET
Framework en Windows) y, por tanto, pueden tomar dependencias significativas de un entorno de ejecución
conocido. Este entorno expondrá un conjunto conocido de API (API de .NET y SO) y mantendrán y expondrán el
estado esperado (por ejemplo, Registro de Windows).
Los desarrolladores que creen bibliotecas específicas de la plataforma pueden aprovechar al máximo la plataforma
subyacente. Las bibliotecas solo se ejecutarán en esa plataforma determinada, por lo que las comprobaciones de
plataforma u otras formas de código condicional son innecesarios (código de abastecimiento único de módulo
para varias plataformas).
Las bibliotecas específicas de la plataforma han sido el tipo de biblioteca de clases principal de .NET Framework.
Incluso con la aparición de otras implementaciones de .NET, las bibliotecas específicas de la plataforma continúan
siendo el tipo de biblioteca dominante.

Bibliotecas de clases portables

Las bibliotecas portables son compatibles con varias implementaciones de .NET. Pueden tomar dependencias en
un entorno de ejecución conocido; en cambio, el entorno es sintético y está generado por la intersección de un
conjunto de implementaciones concretas de .NET. Las hipótesis de plataforma y API expuestas son un subconjunto
de lo que estaría disponible para una biblioteca específica de la plataforma.
Puede elegir una configuración de plataforma al crear una biblioteca portable. La configuración de plataforma es el
conjunto de plataformas que tiene que admitir (por ejemplo, .NET Framework 4.5+, Windows Phone 8.0+).
Cuantas más plataformas decida admitir, menos API y menos hipótesis de plataforma puede hacer, el mínimo
común denominador. Esta característica puede ser confusa al principio, ya que la gente suele pensar que "más es
mejor", pero más plataformas compatibles suponen menos API disponibles.
Muchos desarrolladores de bibliotecas han pasado de producir bibliotecas específicas de varias plataformas de un
origen (con las directivas de compilación condicionales) a bibliotecas portables. Hay varios enfoques para acceder
a la funcionalidad específica de la plataforma en las bibliotecas portables con bait-and-switch como la técnica más
aceptada en este momento.
Bibliotecas de clases .NET Standard
Las bibliotecas de .NET Standard son un reemplazo de los conceptos de bibliotecas específicas de la plataforma y
portables. Son específicas de la plataforma ya que exponen toda la funcionalidad de la plataforma subyacente (sin
plataformas sintéticas ni intersecciones de plataforma). Son portables ya que funcionan en todas las plataformas
compatibles.
.NET Standard expone un conjunto de contratos de bibliotecas. Las implementaciones de .NET deben admitir cada
contrato por completo o no admitirlo. Cada implementación, por tanto, admite un conjunto de contratos de .NET
Standard. Como consecuencia, cada biblioteca de clases de .NET Standard es compatible con las plataformas que
admiten sus dependencias del contrato.
.NET Standard no expone toda la funcionalidad de .NET Framework (ni es un objetivo); en cambio, expone muchas
más API que las bibliotecas de clases portables. Se agregarán más API con el tiempo.
Las siguientes plataformas admiten las bibliotecas de .NET Standard:
.NET Core
.NET Framework
Mono
Xamarin.iOS, Xamarin.Mac, Xamarin.Android
Plataforma universal de Windows (UWP)
Windows
Windows Phone
Windows Phone Silverlight
Para más información, consulte .NET Standard.

Bibliotecas de clases de Mono

Las bibliotecas de clases se admiten en Mono, incluidos los tres tipos de bibliotecas que se han descrito
anteriormente. A menudo, Mono se considera (correctamente) como una implementación multiplataforma de .NET
Framework. En parte, se debía a que las bibliotecas de .NET Framework específicas de la plataforma podrían
ejecutarse en el tiempo de ejecución Mono sin modificarse ni volver a compilarse. Esta característica ya existía
antes de la creación de las bibliotecas de clases portables, por lo que era una elección obvia para habilitar la
portabilidad binaria entre .NET Framework y Mono (aunque solo funcionaba en una dirección).
 .NET Standard
18/12/2020 • 24 minutes to read • Edit Online

.NET Standard es una especificación formal de las API de .NET que están disponibles en varias
implementaciones de .NET. La finalidad de .NET Standard ha sido establecer una mayor uniformidad en el
ecosistema de .NET. Pero en .NET 5 se adopta otro enfoque para establecer la uniformidad, en el que se
elimina la necesidad de .NET Standard en muchos escenarios. Para obtener más información, vea .NET 5 y
.NET Standard más adelante en este artículo.

Compatibilidad con implementaciones de .NET

Las diversas implementaciones de .NET tienen como destino versiones concretas de .NET Standard. Cada
implementación de .NET anuncia la última versión más alta de .NET Standard que admite, indicación de que
también es compatible con versiones anteriores. Por ejemplo, .NET Framework 4.6 implementa .NET Standard
1.3, lo que significa que expone todas las API definidas en las versiones de .NET Standard de 1.0 a 1.3. De
forma similar, .NET Framework 4.6.1 implementa .NET Standard 1.4, mientras que .NET 5.0 implementa .NET
Standard 2.1.
En la tabla siguiente se enumeran las versiones de implementación mínimas compatibles con cada versión
de .NET Standard. Esto significa que las versiones posteriores de una implementación de la lista también son
compatibles con la versión correspondiente de .NET Standard. Por ejemplo, .NET Core 2.1 y versiones
posteriores admiten .NET Standard 2.0 y versiones anteriores.

. N ET
STA N D
A RD 1. 0 1. 1 1. 2 1. 3 1. 4 1. 5 1. 6 2. 0 2. 1

.NET Co 1.0 1.0 1.0 1.0 1.0 1.0 1.0 2.0 3.0
re y
.NET 5

.NET 4.5 4.5 4.5.1 4.6 4.6.1 4.6.1 2 4.6.1 2 4.6.1 2 N/A3
Framew
ork 1

Mono 4.6 4.6 4.6 4.6 4.6 4.6 4.6 5.4 6.4

Xamarin 10.0 10.0 10.0 10.0 10.0 10.0 10.0 10.14 12.16
.iOS

Xamarin 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.8 5.16
.Mac

Xamarin 7.0 7.0 7.0 7.0 7.0 7.0 7.0 8.0 10.0
.Androi
d
 . N ET
STA N D
A RD 1. 0 1. 1 1. 2 1. 3 1. 4 1. 5 1. 6 2. 0 2. 1

Platafor 10.0 10.0 10.0 10.0 10.0 10.0.16 10.0.16 10.0.16 TBD
ma 299 299 299
univers
al de
Window
s

Unity 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 TBD

1 Las versiones que se muestran de .NET Framework se aplican al SDK de .NET Core 2.0 y versiones posteriores de la herramienta. Las versiones
anteriores usaban una asignación diferente para .NET Standard 1.5 y versiones posteriores. Puede descargar herramientas para .NET Core para
Visual Studio 2015 si no se puede actualizar a Visual Studio 2017 ni a una versión posterior.

2 Las versiones siguientes representan las reglas que usa NuGet para determinar si una determinada biblioteca de .NET Standard es aplicable.
Aunque NuGet considera a .NET Framework 4.6.1 compatible con .NET Standard (versiones 1.5 a 2.0) hay varios problemas con el consumo de
bibliotecas de .NET Standard que se compilaron para esas versiones desde proyectos de .NET Framework 4.6.1. Para los proyectos de .NET
Framework que tengan que usar estas bibliotecas, se recomienda actualizar el proyecto para destinarlo a .NET Framework 4.7.2 o una versión
posterior.

3 .NET Framework no es compatible con .NET Standard 2.1. Para obtener más información, vea el anuncio de .NET Standard 2.1.

Las columnas representan las versiones de .NET Standard. Cada celda de encabezado es un vínculo a un
documento que muestra qué API se han agregado en esa versión de .NET Standard.
Las filas representan las diferentes implementaciones de .NET.
El número de versión de cada celda indica la versión mínima de la implementación que necesitará para
tener como destino dicha versión de .NET Standard.
Para ver una tabla interactiva, consulte Versiones de .NET Standard.
Para encontrar la versión más reciente de .NET Standard que puede usar como destino, haga lo siguiente:
1. Busque la fila en la que se indica la implementación de .NET en la que quiere realizar la ejecución.
2. Busque la columna de esa fila que indica la versión de derecha a izquierda.
3. El encabezado de columna indica la versión de .NET Standard que admite el destino. También se puede
seleccionar como destino cualquier versión anterior de .NET Standard. Las versiones superiores de .NET
Standard también serán compatibles con la implementación.
4. Repita este proceso para cada plataforma a la que quiera dirigirse. Si tiene más de una plataforma de
destino, debe elegir la versión más baja. Por ejemplo, si quiere ejecutar en .NET Framework 4.8 y .NET 5.0,
la versión de .NET Standard más alta que puede usar es .NET Standard 2.0.
Versión de .NET Standard de destino
Al elegir una versión de .NET Standard como destino, debe tener en cuenta lo siguiente:
Cuanto mayor sea la versión, más API estarán disponibles para el código de la biblioteca.
Cuanto menor sea la versión, más aplicaciones y bibliotecas podrá usar la biblioteca.
Se recomienda elegir como destino la versión más baja posible de .NET Standard. Así, después de buscar la
versión de .NET Standard superior que puede elegir como destino, siga estos pasos:
1. Diríjase a la siguiente versión menor de .NET Standard y cree el proyecto.
2. Si el proyecto se crea correctamente, repita el paso 1. De lo contrario, vuelva a dirigirse a la siguiente
versión mayor, que es la que debe usar.
Sin embargo, el establecimiento como destino de las versiones inferiores de .NET Standard introduce
diferentes dependencias de compatibilidad. Si el proyecto establece como destino .NET Standard 1.x, le
recomendamos que también establezca .NET Standard 2.0 como destino. Esto simplifica el gráfico de
dependencias para los usuarios de la biblioteca que se ejecutan en implementaciones compatibles de .NET
Standard 2.0 y reduce el número de paquetes que necesitan descargar.
Reglas de control de versiones de .NET Standard
Hay dos reglas de control de versiones principales:
Adición: las versiones de .NET Standard son círculos lógicamente concéntricos: las versiones superiores
incorporan todas las API de las versiones anteriores. No hay ningún cambio importante entre versiones.
Inmutable: Una vez publicadas, las versiones de .NET Standard se congelan.
No habrá nuevas versiones de .NET Standard después de la versión 2.1. Para obtener más información, vea
.NET 5 y .NET Standard más adelante en este artículo.

Especificación
La especificación de .NET Standard es un conjunto estandarizado de API. La especificación se mantiene
mediante implementadores de .NET, específicamente Microsoft (que incluye .NET Framework, .NET Core y
Mono) y Unity.
Artefactos oficiales
La especificación oficial es un conjunto de archivos .cs que definen las API que forman parte del estándar. El
directorio ref en el repositorio dotnet/standard define las API de .NET Standard.
El metapaquete NETStandard.Library (código fuente) describe el conjunto de bibliotecas que definen (en
parte) una o varias versiones de .NET Standard.
Un componente determinado, como System.Runtime , describe lo siguiente:
Parte de .NET Standard (solo su ámbito).
Varias versiones de .NET Standard para ese ámbito.
Se proporcionan artefactos derivados para permitir una lectura más cómoda y habilitar ciertos escenarios de
desarrollo (por ejemplo, el uso de un compilador).
Lista de API en Markdown
Ensamblados de referencia, distribuidos como paquetes NuGet y a los que hace referencia el metapaquete
NETStandard.Library.
Representación de paquetes
El principal vehículo de distribución de los ensamblados de referencia de .NET Standard son los paquetes
NuGet. Las implementaciones se entregarán de diversas formas, adecuadas para cada implementación de
.NET.
Los paquetes NuGet tienen como destino uno o varios marcos. Los paquetes de .NET Standard tienen como
destino el marco ".NET Standard". Puede establecer como destino el marco de .NET Standard mediante el TFM
compacto netstandard (por ejemplo, netstandard1.4 ). Las bibliotecas diseñadas para ejecutarse en varias
implementaciones de .NET deben tener como destino este marco. Para obtener el conjunto más amplio de
API, indique netstandard2.0 como destino, puesto que el número de API disponibles se ha doblado entre
.NET Standard 1.6 y 2.0.
El metapaquete NETStandard.Library hace referencia al conjunto completo de paquetes NuGet que definen
.NET Standard. La manera más común de establecer como destino netstandard consiste en hacer referencia a
este metapaquete. Describe y proporciona acceso a las aproximadamente 40 bibliotecas de .NET y las API
asociadas que definen .NET Standard. Puede hacer referencia a paquetes adicionales que tienen como destino
netstandard para obtener acceso a otras API.

Control de versiones
La especificación no es única, sino que se trata de un conjunto de API con versiones lineales. La primera
versión del estándar establece un conjunto básico de API. Las versiones posteriores agregan API y heredan las
API definidas por las versiones anteriores. No se ha establecido ninguna disposición para quitar API del
estándar.
.NET Standard no es específico de ninguna implementación de .NET, ni coincide con el sistema de control de
versiones de ninguna de esas implementaciones.
Como se ha mencionado antes, no habrá nuevas versiones de .NET Standard después de la versión 2.1.

.NET Standard como destino

Puede compilar bibliotecas de .NET Standard mediante una combinación del marco netstandard y el
metapaquete NETStandard.Library .

Modo de compatibilidad de .NET Framework

A partir de .NET Standard 2.0 se ha introducido el modo de compatibilidad de .NET Framework. Este modo de
compatibilidad permite que los proyectos de .NET Standard hagan referencia a bibliotecas de .NET Framework
como si estuviesen compiladas para .NET Standard. Las referencias a bibliotecas de .NET Framework no
funcionan para todos los proyectos, por ejemplo, en bibliotecas que usan API de Windows Presentation
Foundation (WPF).
Para obtener más información, consulte Modo de compatibilidad de .NET Framework.

Bibliotecas de .NET standard y Visual Studio

Para crear bibliotecas de .NET Standard en Visual Studio, asegúrese de tener Visual Studio 2019 o la
versión 15.3 de Visual Studio 2017 o posterior instalada en Windows, o bien la versión 7.1 de Visual Studio
para Mac o posterior instalada en macOS.
Si solo necesita consumir bibliotecas de .NET Standard 2.0 en sus proyectos, también puede hacerlo en Visual
Studio 2015. Sin embargo, necesitará tener el cliente 3.6 de NuGet o uno posterior instalado. Puede descargar
el cliente de NuGet para Visual Studio 2015 desde la página de descargas de NuGet.

.NET 5 y .NET Standard

.NET 5 es la implementación de .NET que Microsoft desarrolla de forma activa. Se trata de un único producto
con un conjunto uniforme de funcionalidades y API que se pueden usar para aplicaciones de escritorio de
Windows y aplicaciones de consola multiplataforma, servicios en la nube y sitios web. Los moniker de la
plataforma de destino de .NET 5.0 reflejan esta amplia gama de escenarios:
net5.0

Este TFM es para el código que se ejecuta en todas partes. Con algunas excepciones, solo incluye
tecnologías que funcionan entre plataformas. En el código de .NET 5, net5.0 reemplaza los TFM
netcoreapp y netstandard .

net5.0-windows

Este es un ejemplo de TFM específicos del sistema operativo que agregan funcionalidad específica del
sistema operativo a todo a lo que net5.0 hace referencia.
Diferencias entre elegir .NET 5.0 y .NET Standard como destino
Para el código existente que tiene como destino netstandard , no es necesario cambiar el TFM por net5.0 .
.NET 5.0 implementa .NET Standard 2.1 y versiones anteriores. La única razón para cambiar el destino de .NET
Standard a .NET 5.0 sería para obtener acceso a más características de tiempo de ejecución, del lenguaje o API.
Por ejemplo, para usar C# 9, debe tener como destino .NET 5.0. Puede tener como destino .NET 5.0 y
.NET Standard para obtener acceso a las características más recientes y seguir teniendo la biblioteca
disponible para otras implementaciones de .NET.
Estas son algunas instrucciones para el código nuevo de .NET 5:
Componentes de la aplicación
Si usa bibliotecas para dividir una aplicación en varios componentes, se recomienda seleccionar como
destino net5.x , donde 5.x es la versión más antigua de .NET 5 que la aplicación puede tener como
destino. Para simplificar, es mejor mantener todos los proyectos que componen la aplicación en la
misma versión de .NET. Después, puede suponer las mismas características de BCL en todas partes.
Bibliotecas reutilizables
Si va a compilar bibliotecas reutilizables que planea enviar en NuGet, tenga en cuenta el equilibrio
entre el alcance y el conjunto de características disponibles. .NET Standard 2.0 es la última versión
admitida por .NET Framework, por lo que ofrece un buen alcance con un conjunto de características
bastante amplio. No se recomienda establecer .NET Standard 1.x como destino, ya que se limitaría el
conjunto de características disponibles a cambio de un mínimo aumento del alcance.
Si no necesita admitir .NET Framework, puede usar .NET Standard 2.1 o .NET 5. Se recomienda omitir
.NET Standard 2.1 y pasar directamente a .NET 5. En última instancia,. las bibliotecas más utilizadas
tendrán como destino tanto .NET Standard 2.0 como .NET 5. Al admitir .NET Standard 2.0 se obtiene el
máximo alcance, mientras que al admitir .NET 5 se garantiza el aprovechamiento de las características
más recientes de la plataforma para los clientes que ya usan .NET 5.
Problemas con .NET Standard
Estos son algunos problemas con .NET Standard que ayudan a explicar por qué .NET 5 es la mejor manera de
compartir código entre plataformas y cargas de trabajo:
Lentitud para agregar API nuevas
.NET Standard se creó como un conjunto de API que todas las implementaciones de .NET debían
admitir, por lo que hubo un proceso de revisión de las propuestas para agregar API nuevas. El objetivo
era normalizar solo las API que se pudieran implementar en todas las plataformas .NET, actuales y
futuras. Como resultado, si faltaba una característica en una versión concreta, es posible que tuviera
que esperar un par de años antes de que se agregara a una versión de Standard. Después, tendría que
esperar incluso más a que la nueva versión de .NET Standard tuviera compatibilidad suficiente.
Solución en .NET 5: Cuando se implementa una característica, ya está disponible para cada
aplicación y biblioteca de .NET 5, porque la base de código está compartida. Y como no hay ninguna
diferencia entre la especificación de la API y su implementación, puede aprovechar las ventajas de las
nuevas características mucho más rápido que con .NET Standard.
Complejidad del control de versiones
La separación de la especificación de la API de sus implementaciones da lugar a una asignación
compleja entre las versiones de especificación de la API y las de implementación. Esta complejidad es
evidente en la tabla que se ha mostrado antes en este artículo y en las instrucciones sobre cómo
interpretarla.
Solución en .NET 5: No existe separación entre la especificación de una API de .NET 5.x y su
 implementación. El resultado es un esquema de TFM simplificado. Hay un prefijo de TFM para todas las
cargas de trabajo: se usa net5.0 para bibliotecas, aplicaciones de consola y aplicaciones web. La única
variante es un sufijo que especifica las API específicas de la plataforma para una plataforma concreta,
como net5.0-windows . Gracias a esta convención de nomenclatura de TFM, puede saber con facilidad
si una aplicación concreta puede usar una biblioteca determinada. No se necesita una tabla de
números de versión equivalentes como la de .NET Standard.
Excepciones no admitidas por la plataforma en tiempo de ejecución
.NET Standard expone API específicas de la plataforma. El código se podría compilar sin errores y
parecer ser portable a cualquier plataforma aunque lo no sea. Cuando se ejecuta en una plataforma
que no tiene una implementación de una API determinada, se obtienen errores en tiempo de ejecución.
Solución en .NET 5: El SDK de .NET 5 incluye analizadores de código que están habilitados de forma
predeterminada. El analizador de compatibilidad de plataformas detecta el uso involuntario de las API
que no se admiten en las plataformas en las se que pretenden ejecutar. Para obtener más información,
vea Analizador de compatibilidad de plataformas.
.NET Standard no está en desuso
.NET Standard sigue siendo necesario para las bibliotecas que se pueden usar en varias implementaciones de
.NET. Se recomienda seleccionar .NET Standard como destino en los escenarios siguientes:
Use netstandard2.0 para compartir código entre .NET Framework y todas las demás implementaciones de
.NET.
Use netstandard2.1 para compartir código entre Mono, Xamarin y .NET Core 3.x.

Consulte también
Versiones de .NET Standard (código fuente)
Versiones de .NET Standard (IU interactiva)
Compilación de una biblioteca de .NET Standard
Destinatarios multiplataforma
 Glosario de .NET
18/12/2020 • 30 minutes to read • Edit Online

El objetivo principal de este glosario es aclarar los significados de algunos de los términos y acrónimos que
aparecen frecuentemente en la documentación de .NET sin definiciones.

AOT
Compilador Ahead Of Time.
Similar a JIT, este compilador también convierte IL en código de máquina. A diferencia de la compilación JIT, la
compilación AOT ocurre antes de que la aplicación se ejecute y, normalmente, se realiza en un equipo diferente.
Dado que las cadenas de la herramienta de AOT no se compilan en tiempo de ejecución, no tienen que minimizar
el tiempo dedicado a compilar. Esto significa que pueden dedicar más tiempo a la optimización. Puesto que el
contexto de AOT es toda la aplicación, el compilador AOT también realiza vinculación entre módulos y el análisis de
todo el programa, lo que significa que se siguen todas las referencias y se genera un archivo ejecutable único.
Vea CoreRT y .NET Native.

Modelo de aplicación
Una API específica de la carga de trabajo. A continuación se muestran algunos ejemplos:
ASP.NET
ASP.NET Web API
Entity Framework (EF)
Windows Presentation Foundation (WPF)
Windows Communication Foundation (WCF)
Windows Workflow Foundation (WF)
Windows Forms (WinForms)

ASP.NET
La implementación original de ASP.NET que se distribuye con .NET Framework.
A veces, ASP.NET es un término genérico que hace referencia a ambas implementaciones de ASP.NET, incluido
ASP.NET Core. El significado que lleva el término en una instancia específica se determina según el contexto. Haga
referencia a ASP.NET 4.x cuando desee dejar claro que no usa ASP.NET para indicar ambas implementaciones.
Vea la documentación de ASP.NET.

ASP.NET Core
Implementación multiplataforma, de alto rendimiento y de código abierto de ASP.NET.
Vea la documentación de ASP.NET Core.

ensamblado
Un archivo .dll/ .exe que puede contener una colección de API a la que puede llamarse mediante aplicaciones u
otros ensamblados.
Un ensamblado puede incluir tipos como interfaces, clases, estructuras, enumeraciones y delegados. A veces, se
hace referencia a los ensamblados de la carpeta bin de un proyecto como archivos binarios. Vea también
biblioteca.

BCL
Biblioteca de clases base.
Un conjunto de bibliotecas que conforman los espacios de nombres de System.* (y hasta cierto punto Microsoft.*).
BCL es un marco de nivel inferior de uso general donde se compilan marcos de trabajo de la aplicación de nivel
superior, como ASP.NET Core.
El código fuente de la BCL para .NET 5 (y .NET Core) y versiones posteriores se encuentra en el repositorio del
entorno de ejecución de .NET. La mayoría de estas API de BCL también están disponibles en .NET Framework, por
lo que puede considerar este código fuente como una bifurcación del de la BCL de .NET Framework.
Los siguientes términos a menudo hacen referencia a la misma colección de API a las que se refiere BCL:
bibliotecas de .NET básicas
bibliotecas de marco
bibliotecas en tiempo de ejecución
marco compartido

CLR
Common Language Runtime.
El significado exacto depende del contexto. Common Language Runtime normalmente hace referencia al entorno
de ejecución de .NET Framework o de .NET 5 (y .NET Core) y versiones posteriores.
CLR controla la asignación y administración de memoria. CLR es también una máquina virtual que no solo ejecuta
aplicaciones, sino que también genera y compila código sobre la marcha mediante un compilador JIT.
La implementación de CLR para .NET Framework es solo para Windows.
La implementación de CLR para .NET 5 y versiones posteriores (también conocida como CoreCLR) se crea a partir
del mismo código base que el CLR de .NET Framework. Originalmente, CoreCLR era el entorno de ejecución de
Silverlight y estaba diseñado para ejecutarse en varias plataformas, concretamente Windows y OS X. Sigue siendo
un entorno de ejecución multiplataforma y ahora incluye compatibilidad con muchas distribuciones de Linux.
Vea también entorno de ejecución.

CoreCLR
Common Language Runtime para .NET 5 (y .NET Core) y versiones posteriores.
Vea CLR.

CoreRT
A diferencia de CLR, CoreRT no es una máquina virtual, lo que significa que no incluye las funciones para generar y
ejecutar código sobre la marcha porque no incluye un compilador JIT. En cambio, incluye GC, reflexión y capacidad
de identificación del tipo en tiempo de ejecución (RTTI). Con todo, su sistema de tipos está diseñado para que no
sean necesarios los metadatos para la reflexión. No requerir los metadatos permite tener una cadena de
herramientas de AOT que puede vincular metadatos superfluos y (más importante) identificar código que no usa la
aplicación. CoreRT está en desarrollo.
Consulte Introducción a .NET Native u CoreRT.

multiplataforma
La capacidad para desarrollar y ejecutar una aplicación que se puede usar en varios sistemas operativos diferentes,
como Linux, Windows e iOS, sin tener que volver a escribir específicamente para cada uno de ellos. Esto permite
reutilizar el código y posibilita la coherencia entre aplicaciones en distintas plataformas.

ecosistema
Todo el software en tiempo de ejecución, las herramientas de desarrollo y los recursos de la comunidad que se
usan para compilar y ejecutar aplicaciones de una tecnología determinada.
El término "ecosistema de .NET" se diferencia de términos parecidos como "pila de .NET" en que incluye bibliotecas
y aplicaciones de terceros. Aquí se muestra un ejemplo en una frase:
"La finalidad de .NET Standard es establecer una mayor uniformidad en el ecosistema de .NET".

marco de trabajo
En general, una colección completa de API que facilita el desarrollo y la implementación de aplicaciones que se
basan en una tecnología concreta. En este sentido general, ASP.NET Core y Windows Forms son ejemplos de
marcos de trabajo de la aplicación. Vea también biblioteca.
Los siguientes términos tienen un significado diferente:
bibliotecas de marco
.NET Framework
marco compartido
Plataforma de destino
TFM (moniker de la plataforma de destino)
Aplicación dependiente de la plataforma
En ocasiones, "marco" hace referencia a una implementación de .NET. Por ejemplo, un artículo puede llamar marco
de trabajo a .NET 5.

Bibliotecas de marco
El significado depende del contexto. Puede hacer referencia a las bibliotecas de marco para .NET 5 (y .NET Core) y
versiones posteriores, en cuyo caso hace referencia a las mismas bibliotecas a las que hace referencia BCL.
También puede hacer referencia a las bibliotecas de marco de ASP.NET Core, que se basan en la BCL y
proporcionan API adicionales para las aplicaciones web.

GC
Recolector de elementos no utilizados.
El recolector de elementos no utilizados es una implementación de administración de memoria automática. GC
libera la memoria ocupada por objetos que ya no se usan.
Vea Recolección de elementos no utilizados.

IL
Lenguaje intermedio.
Los lenguajes .NET de nivel alto, como C#, compilan en un conjunto de instrucciones independiente del hardware,
lo que se denomina lenguaje intermedio (IL). A veces, se hace referencia al IL como MSIL (IL de Microsoft) o CIL
(Common IL).

JIT
Compilador Just-In-Time.
Similar a AOT, este compilador convierte el IL en código de máquina que entienda el procesador. A diferencia de
AOT, la compilación JIT se produce a petición y se lleva a cabo en el mismo equipo en que debe ejecutarse el
código. Puesto que la compilación JIT tiene lugar durante la ejecución de la aplicación, el tiempo de compilación es
parte del tiempo de ejecución. Por tanto, los compiladores JIT tienen que compensar el tiempo invertido en
optimizar el código con el ahorro que puede generar el código resultante. Pero un JIT conoce el hardware real y
puede liberar a los desarrolladores de tener que enviar diferentes implementaciones.

implementación de .NET
Una implementación de .NET incluye lo siguiente:
Uno o varios entornos de ejecución. Ejemplos: CLR y CoreRT.
Biblioteca de clases que implementa una versión de .NET Standard y puede incluir API adicionales. Ejemplos:
BCL para .NET Framework y para .NET 5 (y .NET Core) y versiones posteriores.
Opcionalmente, uno o varios marcos de trabajo de la aplicación. Ejemplos: ASP.NET, Windows Forms y WPF se
incluyen en .NET Framework y .NET 5.
Opcionalmente, herramientas de desarrollo. Algunas herramientas de desarrollo se comparten entre varias
implementaciones.
Ejemplos de implementaciones de .NET:
.NET Framework
.NET 5 y versiones posteriores (incluido .NET Core 2.1-3.1)
Plataforma universal de Windows (UWP)
Mono

biblioteca
Una colección de API que pueden llamarse mediante aplicaciones u otras bibliotecas. Una biblioteca de .NET se
compone de uno o varios ensamblados.
Las palabras biblioteca y marco de trabajo se usan a menudo como sinónimos.

Mono
Mono es una implementación de .NET multiplataforma y de código abierto que se usa principalmente cuando se
requiere un entorno de ejecución pequeño. Es el entorno de ejecución que activa las aplicaciones de Xamarin en
Android, Mac, iOS, tvOS y watchOS, y se centra principalmente en aplicaciones que requieren una superficie
pequeña.
Admite todas las versiones de .NET Standard publicadas actualmente.
Históricamente, Mono implementaba la API de .NET Framework más grande y emulaba algunas de las funciones
más populares en Unix. A veces, se usa para ejecutar aplicaciones de .NET que se basan en estas capacidades en
Unix.
Mono se suele usar con un compilador Just-In-Time, pero también incluye un compilador estático completo
(compilación Ahead Of Time) que se usa en plataformas como iOS.
Consulte la documentación de Mono.

.NET
El término que engloba .NET Standard y todas las cargas de trabajo e implementaciones de .NET. Siempre
totalmente en mayúsculas, nunca ".Net".
Cuando se publique .NET 5 (actualmente en versión preliminar), será la implementación de .NET recomendada
para todo el nuevo desarrollo de .NET, por lo que en algunos contextos ".NET" implicará ".NET 5 y versiones
posteriores".
Vea Aspectos básicos de .NET.

.NET 5 y versiones posteriores

Una implementación multiplataforma, de alto rendimiento y de código abierto de .NET. Incluye Common Language
Runtime (CLR), un entorno de ejecución AOT (CoreRT, en desarrollo), una biblioteca de clases base (BCL) y el SDK
de .NET.
Las versiones anteriores de esta implementación de .NET se conocen como .NET Core. .NET 5.0 es la siguiente
versión después de .NET Core 3.1. La versión 4 se ha omitido para no confundir esta nueva implementación de
.NET con la implementación anterior conocida como .NET Framework. La versión actual de .NET Framework es 4.8.
Vea Aspectos básicos de .NET.

CLI de .NET
Una cadena de herramientas multiplataforma para desarrollar aplicaciones y bibliotecas para .NET 5 (y .NET Core)
y versiones posteriores. También conocida como la CLI de .NET Core.
Vea CLI de .NET.

.NET Core
Vea .NET 5 y versiones posteriores.

.NET Framework
Una implementación de .NET que se ejecuta solo en Windows. Incluye Common Language Runtime (CLR), la
biblioteca de clases base (BCL) y las bibliotecas de marco de trabajo de la aplicación, como ASP.NET,
Windows Forms y WPF.
Vea Guía de .NET Framework.

.NET Native
Cadena de herramientas del compilador que genera código nativo Ahead Of Time (AOT), en lugar de Just-In-Time
(JIT).
La compilación se produce en el equipo del desarrollador, de forma similar a cómo funcionan el compilador y el
enlazador de C++. Quita el código que no se usa y emplea más tiempo en optimizarlo. Extrae código de bibliotecas
y lo combina en el archivo ejecutable. El resultado es un módulo único que representa toda la aplicación.
UWP fue el primer marco de trabajo de la aplicación compatible con .NET Native. Ahora, se admite la compilación
de aplicaciones de consola nativas para Windows, macOS y Linux.
Vea Intro to .NET Native and CoreRT (Introducción a .NET Native y CoreRT).

.NET SDK
Conjunto de bibliotecas y herramientas que permiten a los desarrolladores crear aplicaciones y bibliotecas de .NET
para .NET 5 (y .NET Core) y versiones posteriores. También se conoce como el SDK de .NET Core.
Incluye la CLI de .NET para compilar aplicaciones, el entorno de ejecución, y las bibliotecas de .NET para compilar y
ejecutar aplicaciones, y el ejecutable dotnet (dotnet.exe) que ejecuta comandos de la CLI y ejecuta aplicaciones.
Vea Información general sobre el SDK de .NET.

.NET Standard
Una especificación formal de las API de .NET que están disponibles en cada implementación de .NET.
La especificación de .NET Standard a veces se denomina "biblioteca" en la documentación. Dado que una biblioteca
incluye implementaciones de API, no solo especificaciones (interfaces), es confuso denominar "biblioteca" a .NET
Standard.
Vea .NET Standard.

NGEN
Generación (de imágenes) nativas.
Esta tecnología se puede considerar como un compilador JIT persistente. Normalmente, compila código en el
equipo en que se ejecuta el código, pero la compilación se suele producir durante la instalación.

paquete
Un paquete de NuGet — o simplemente un paquete — es un archivo .zip con uno o varios ensamblados del
mismo nombre junto con metadatos adicionales, como el nombre del autor.
El archivo .zip tiene una extensión .nupkg y puede contener recursos (como archivos .dll y .xml) para usar con
varios marcos de destino y versiones. Cuando se instala en una aplicación o biblioteca, se seleccionan los recursos
adecuados en función de la plataforma de destino especificada por la aplicación o biblioteca. Los recursos que
definen la interfaz se encuentran en la carpeta ref y los recursos que definen la implementación se encuentran en
la carpeta lib.

platform
Un sistema operativo y el hardware en que se ejecuta, como Windows, macOS, Linux, iOS y Android.
Aquí tiene ejemplos de uso en frases:
".NET Core es una implementación multiplataforma de .NET".
"Los perfiles de PCL representan plataformas de Microsoft, mientras que .NET Standard es independiente de la
plataforma".
La documentación heredada de .NET a veces usa el término "plataforma de .NET" para referirse a una
implementación de .NET o a la pila de .NET que incluyen todas las implementaciones. Estos dos usos tienden a
confundirse con el significado principal (sistema operativo o hardware), por tanto, tratamos de evitar estos usos.
"Plataforma" tiene un significado diferente en "plataforma del desarrollador", ya que hace referencia al software
que proporciona herramientas y bibliotecas para compilar y ejecutar aplicaciones. .NET es una plataforma para el
desarrollo de contenido de código abierto multiplataforma que permite crear una gran variedad de tipos de
aplicaciones.

motor en tiempo de ejecución

En términos generales, el entorno de ejecución de un programa administrado. El sistema operativo forma parte del
entorno de ejecución, pero no del entorno de ejecución .NET. Estos son algunos ejemplos de los entornos de
ejecución de .NET en este sentido de la palabra:
Common Language Runtime (CLR)
.NET Native (para UWP)
Entorno de ejecución Mono
El término "entorno de ejecución" tiene un significado diferente en algunos contextos:
Entorno de ejecución de .NET en la página de descarga de .NET 5.0.
Puede descargar el entorno de ejecución de .NET u otros, como el entorno de ejecución de ASP.NET Core. En
este caso, un entorno de ejecución es el conjunto de componentes que se deben instalar en un equipo para
ejecutar una aplicación dependiente del marco en el equipo. El entorno de ejecución de .NET incluye el CLR
y el marco compartido de .NET, que proporciona la BCL.
Bibliotecas en tiempo de ejecución de .NET
Hace referencia a las mismas bibliotecas a las que hace referencia BCL. Pero otros entornos de ejecución,
como el de ASP.NET Core, tienen otros marcos compartidos, con bibliotecas adicionales que se basan en la
BCL.
Identificador en tiempo de ejecución (RID).
Aquí, tiempo de ejecución hace referencia a la plataforma del sistema operativo y a la arquitectura de la CPU
en la que se ejecuta una aplicación de .NET, por ejemplo, linux-x64 .
En ocasiones, se usa "entorno de ejecución" para indicar una implementación de .NET, como en los ejemplos
siguientes:
"Los diversos entornos de ejecución .NET implementan versiones concretas de .NET Standard. … Cada
versión del entorno de ejecución de .NET anuncia la última versión de .NET Standard que admite...".
"Las bibliotecas diseñadas para ejecutarse en varios entornos de ejecución deben tener como destino
este marco de trabajo". (Hace referencia a .NET Standard).

marco compartido
El significado depende del contexto. El marco compartido de .NET hace referencia a las bibliotecas incluidas en el
entorno de ejecución de .NET. En este caso, el marco compartido para .NET 5 (y .NET Core) y versiones posteriores
hace referencia a las mismas bibliotecas a las que hace referencia BCL.
Hay otros marcos compartidos. El marco compartido de ASP.NET Core hace referencia a las bibliotecas incluidas en
el entorno de ejecución de ASP.NET Core, que incluye la BCL y API adicionales para su uso por parte de
aplicaciones web.
En el caso de las aplicaciones dependientes del marco, el marco compartido consta de bibliotecas que se
encuentran en los ensamblados instalados en una carpeta en el equipo que ejecuta la aplicación. En el caso de las
aplicaciones independientes, los ensamblados de marco compartido se incluyen con la aplicación.
Para obtener más información, vea Profundización en los primitivos de .NET Core, parte 2: el marco compartido.

pila
Un conjunto de tecnologías de programación que se usan para compilar y ejecutar aplicaciones.
La "pila de .NET" hace referencia a .NET Standard y a todas las implementaciones de .NET. La frase "una pila de
.NET" puede hacer referencia a una implementación de .NET.

versión de .NET Framework de destino

La colección de API de las que depende una aplicación o biblioteca de .NET.
Una aplicación o biblioteca puede tener como destino una versión de .NET Standard (por ejemplo,
.NET Standard 2.0), que es la especificación de un conjunto estándar de API de todas las implementaciones de .NET.
Una aplicación o biblioteca también puede tener como destino una versión de una implementación específica de
.NET; en este caso, obtiene acceso a las API específicas de la implementación. Por ejemplo, una aplicación que tenga
como destino Xamarin.iOS obtiene acceso a contenedores de la API de iOS proporcionados por Xamarin.
Para algunas plataformas de destino (por ejemplo, .NET Framework), las API disponibles se definen mediante los
ensamblados que una implementación de .NET instala en un sistema y pueden incluir las API del marco de trabajo
de la aplicación (por ejemplo, ASP.NET o Windows Forms). Para plataformas de destino basadas en paquetes (por
ejemplo, .NET Standard y .NET Core), las API se definen mediante los paquetes instalados en la aplicación o
biblioteca. En ese caso, la plataforma de destino especifica implícitamente un paquete que hace referencia a todos
los paquetes que forman el marco de trabajo.
Vea Plataformas de destino.

TFM
Moniker de la plataforma de destino.
Un formato de token normalizado para especificar la plataforma de destino de una aplicación o biblioteca de .NET.
Se suele hacer referencia a las plataformas de destino mediante un nombre corto, como net462 . Los TFM de
formato largo (como .NETFramework,Version=4.6.2) existen, pero no se suelen usar para especificar una
plataforma de destino.
Vea Plataformas de destino.

UWP
Plataforma universal de Windows.
Una implementación de .NET que se usa para compilar aplicaciones Windows modernas y táctiles y software para
Internet de las cosas (IoT). Se ha diseñado para unificar los diferentes tipos de dispositivos de destino, incluidos
equipos, tabletas, teléfonos e incluso la consola Xbox. UWP proporciona muchos servicios, como una tienda de
aplicaciones centralizada, un entorno de ejecución (AppContainer) y un conjunto de API de Windows para usar en
lugar de Win32 (WinRT). Pueden escribirse aplicaciones en C++, C#, Visual Basic y JavaScript. Al usar C# y
Visual Basic, .NET 5 (y .NET Core), así como sus versiones posteriores, proporcionan las API de .NET.

carga de trabajo
Un tipo de aplicación que alguien compila. Más genérico que modelo de aplicación. Por ejemplo, en la parte
superior de todas las páginas de documentación de .NET, incluida esta, hay una lista desplegable para Cargas de
trabajo , que permite cambiar a la documentación de Web , Dispositivos móviles , Nube , Escritorio y Machine
Learning y datos .
En algunos contextos, carga de trabajo hace referencia a una colección de características de Visual Studio que
puede elegir instalar para admitir un tipo determinado de aplicación. Para obtener un ejemplo, vea Selección de
una carga de trabajo.
Vea también
Aspectos básicos de .NET
Guía de .NET Framework
ASP.NET Overview (Información general de ASP.NET)
ASP.NET Core Overview (Información general de ASP.NET Core)
 Tutorial: Creación de una aplicación de consola de
.NET con Visual Studio
18/12/2020 • 6 minutes to read • Edit Online

En este tutorial se muestra cómo crear y ejecutar una aplicación de consola de .NET en Visual Studio 2019.

Requisitos previos
Visual Studio 2019, versión 16.8 o posterior con la carga de trabajo Desarrollo multiplataforma de
.NET Core instalada. El SDK de .NET 5.0 se instala automáticamente al seleccionar esta carga de trabajo.
Para obtener más información, vea Instalación del SDK de .NET con Visual Studio.

Creación de la aplicación
Cree un proyecto de aplicación de consola de .NET denominado "HelloWorld".
1. Inicie Visual Studio 2019.
2. Seleccione Herramientas > Opciones > Entorno > Características de vista previa y después
Mostrar todas las plantillas de .NET Core en el nuevo proyecto (requiere reinicio) .

3. Cierre y vuelva a abrir Visual Studio.

4. En la página de inicio, elija Crear un proyecto nuevo .
5. En la página Crear un proyecto , escriba consola en el cuadro de búsqueda. Después, elija C# o Visual
Basic en la lista de lenguajes y luego elija Todas las plataformas en la lista de plataformas. Elija la
plantilla Aplicación de consola y, después, seleccione Siguiente .

TIP
Si no ve las plantillas de .NET, es probable que falte la carga de trabajo necesaria. En el mensaje ¿No encuentra lo
que busca? , elija el vínculo Instalar más herramientas y características . Se abre el Instalador de Visual
Studio. Asegúrese de que tiene instalada la carga de trabajo Desarrollo multiplataforma de .NET Core .

6. En el cuadro de diálogo Configurar el nuevo proyecto , escriba HelloWorld en el cuadro Nombre

 del proyecto . Luego, elija Crear .

7. En el cuadro de diálogo Información adicional , seleccione .NET 5.0 (actual) y después Crear .

La plantilla crea una aplicación "Hola mundo" sencilla. Llama al método Console.WriteLine(String) para mostrar
"Hola mundo" en la ventana de la consola.
El código de plantilla define una clase, Program , con un solo método, Main , que toma una matriz de String como
argumento:
 using System;

namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

Imports System

Module Program
Sub Main(args As String())
Console.WriteLine("Hello World!")
End Sub
End Module

Main es el punto de entrada de la aplicación, el método que se llama automáticamente mediante el tiempo de
ejecución cuando inicia la aplicación. Los argumentos de línea de comandos proporcionados cuando se inicia la
aplicación están disponibles en la matriz args.
Si no se muestra el idioma que quiere usar, cambie el selector de idioma en la parte superior de la página.

Ejecutar la aplicación
1. Presione Ctrl+F5 para ejecutar el programa sin depurar.
Se abre la ventana de la consola con el texto "Hello World" impreso en la pantalla.

2. Presione cualquier tecla para cerrar la ventana de consola.

Mejora de la aplicación
Mejore la aplicación para pedir su nombre al usuario y mostrarlo con la fecha y la hora.
1. En Program.cs o Program.vb, reemplace el contenido del método Main , que es la línea que llama a
Console.WriteLine , por el código siguiente:

Console.WriteLine("\nWhat is your name? ");

var name = Console.ReadLine();
var date = DateTime.Now;
Console.WriteLine($"\nHello, {name}, on {date:d} at {date:t}!");
Console.Write("\nPress any key to exit...");
Console.ReadKey(true);
 Console.WriteLine(vbCrLf + "What is your name? ")
Dim name = Console.ReadLine()
Dim currentDate = DateTime.Now
Console.WriteLine($"{vbCrLf}Hello, {name}, on {currentDate:d} at {currentDate:t}")
Console.Write(vbCrLf + "Press any key to exit... ")
Console.ReadKey(True)

Este código muestra un mensaje en la ventana de la consola y espera a que el usuario escriba una cadena
y, luego, presione Entrar. Almacena esta cadena en una variable denominada name . También recupera el
valor de la propiedad DateTime.Now, que contiene la hora local actual, y lo asigna a una variable
denominada date ( currentDate en Visual Basic). Asimismo, muestra estos valores en la ventana de la
consola. Por último, muestra un mensaje en la ventana de la consola y llama al método
Console.ReadKey(Boolean) para esperar a la entrada del usuario.
El símbolo \n ( vbCrLf en Visual Basic) representa un carácter de nueva línea.
El signo de dólar ( $ ) delante de una cadena permite colocar expresiones como nombres de variable
entre llaves en la cadena. El valor de la expresión se inserta en la cadena en lugar de la expresión. Esta
sintaxis se conoce como cadenas interpoladas.
2. Presione Ctrl+F5 para ejecutar el programa sin depurar.
3. Responda a la solicitud escribiendo un nombre y presionando la tecla Entrar.

4. Presione cualquier tecla para cerrar la ventana de consola.

Recursos adicionales
Versiones actuales y versiones de compatibilidad a largo plazo

Pasos siguientes
En este tutorial, ha creado una aplicación de consola de .NET. En el siguiente tutorial, depurará la aplicación.
Depuración de una aplicación de consola de .NET con Visual Studio
 Tutorial: Depuración de una aplicación de consola de
.NET con Visual Studio
18/12/2020 • 14 minutes to read • Edit Online

En este tutorial se presentan las herramientas de depuración que hay disponibles en Visual Studio.

Requisitos previos
Este tutorial funciona con la aplicación de consola que se crea en Creación de una aplicación de consola de .NET
con Visual Studio.

Uso de la configuración de compilación de depuración

Depuración y Versión son las configuraciones de compilación integradas de Visual Studio. Use la configuración de
compilación Depuración para depurar y la configuración de compilación Versión para la distribución final de la
versión.
En la configuración de depuración, el programa se compila sin optimizar y con toda la información de depuración
simbólica. La optimización complica la depuración, ya que la relación entre el código fuente y las instrucciones
generadas es más compleja. La configuración de versión del programa no contiene información de depuración
simbólica y está totalmente optimizada.
De forma predeterminada, Visual Studio usa la configuración de compilación Depuración, por lo que no es
necesario cambiarla antes de depurar.
1. Inicie Visual Studio.
2. Abra el proyecto que ha creado en Creación de una aplicación de consola de .NET con Visual Studio.
La configuración de compilación actual se muestra en la barra de herramientas. En la siguiente imagen de la
barra de herramientas se muestra que Visual Studio está configurado para compilar la versión de
depuración de la aplicación:

Establecer un punto de interrupción

Un punto de interrupción interrumpe temporalmente la ejecución de la aplicación antes de que se ejecute la línea
con el punto de interrupción.
1. Establezca un punto de interrupción en la línea que muestre el nombre, la fecha y la hora; para ello, haga
clic en el margen izquierdo de la ventana de código de esa línea. El margen izquierdo está a la izquierda de
los números de línea. Otras maneras de establecer un punto de interrupción consisten en colocar el cursor
en la línea de código y, después, presionar F9 o seleccionar Depurar > Alternar punto de interrupción
en la barra de menú.
En esta imagen vemos que, para indicar la línea en la que se establece el punto de interrupción,
Visual Studio lo resalta y muestra un punto rojo en el margen izquierdo.
2. Presione F5 para ejecutar el programa en modo de depuración. Otra manera de iniciar la depuración es
elegir Depuración > Iniciar depuración en el menú.
3. Cuando el sistema le pida un nombre, escriba una cadena en la ventana de consola y luego presione
Entrar.

4. La ejecución del programa se detiene cuando llega al punto de interrupción y antes de que se ejecute el
método Console.WriteLine . La ventana Variables locales muestra los valores de las variables definidas en
el método que se ejecuta actualmente.

Uso de la ventana Inmediato

La ventana Inmediato le permite interactuar con la aplicación que está depurando. Puede cambiar el valor de las
variables de forma interactiva para ver cómo afecta esto al programa.
1. Si la ventana Inmediato no está visible, muéstrela; para ello, elija Depurar > Ventanas > Inmediato .
2. Escriba name = "Gracie" en la ventana Inmediato y presione la tecla Entrar.
3. Escriba date = DateTime.Parse("2019-11-16T17:25:00Z").ToUniversalTime() en la ventana Inmediato y
presione la tecla Entrar.
La ventana Inmediato muestra el valor de la variable de cadena y las propiedades del valor DateTime.
Además, los valores de las variables se actualizan en la ventana Variables locales .

4. Presione F5 para que continúe la ejecución del programa. Otra manera de hacerlo es elegir Depuración >
Continuar en el menú.
Los valores mostrados en la ventana de la consola corresponden a los cambios realizados en la ventana
Inmediato .

5. Presione cualquier tecla para salir de la aplicación y detenga la depuración.

Establecimiento de un punto de interrupción condicional

El programa muestra la cadena que escribe el usuario. ¿Qué sucede si el usuario no escribe nada? Puede probarlo
con una característica de depuración muy útil denominada Punto de interrupción condicional.
1. Haga clic con el botón derecho en el punto rojo que representa al punto de interrupción. En el menú
contextual, seleccione Condiciones para abrir el cuadro de diálogo Configuración del punto de
interrupción . Active la casilla Condiciones si aún no está seleccionada.

2. En Expresión condicional , escriba el código siguiente en el campo que muestra el código de ejemplo que
comprueba si x es 5. Si no se muestra el idioma que quiere usar, cambie el selector de idioma en la parte
superior de la página.

String.IsNullOrEmpty(name)

String.IsNullOrEmpty(name)

Cada vez que se alcanza el punto de interrupción, el depurador llama al método

String.IsNullOrEmpty(name) y se interrumpe en esta línea solo si la llamada al método devuelve true .
En lugar de una expresión condicional, puede especificar un número de llamadas, que interrumpe la
ejecución del programa antes de que se ejecute una instrucción un número de veces especificado. Otra
opción consiste en especificar una condición de filtro, que interrumpe la ejecución del programa en función
de atributos tales como un identificador de subproceso, un nombre de proceso o un nombre de
subproceso.
3. Seleccione Cerrar para cerrar el cuadro de diálogo.
4. Inicie el programa con la depuración presionando F5.
5. En la ventana de consola, cuando se le pida que escriba su nombre, presione la tecla Entrar.
6. Como se ha cumplido la condición que especificó ( name es null o String.Empty), la ejecución del
programa se detiene cuando se alcanza el punto de interrupción y antes de que se ejecute el método
Console.WriteLine .

7. Seleccione la ventana Variables locales , que muestra los valores de las variables que son locales para el
método que se ejecuta actualmente. En este caso, Main es el método que se está ejecutando actualmente.
 Observe que el valor de la variable name es "" o String.Empty.
8. Confirme que el valor es una cadena vacía escribiendo la siguiente instrucción en la ventana Inmediato y
presionando Entrar. El resultado es true .

? name == String.Empty

? String.IsNullOrEmpty(name)

El signo de interrogación dirige la ventana Inmediato para evaluar una expresión.

9. Presione F5 para que continúe la ejecución del programa.

10. Presione cualquier tecla para cerrar la ventana de consola y detener la depuración.
11. Para borrar el punto de interrupción, haga clic en el punto en el margen izquierdo de la ventana de código.
Otras formas de borrar un punto de interrupción consisten en presionar F9 o elegir Depurar > Alternar
punto de interrupción mientras se selecciona la línea de código.

Ejecución paso a paso de un programa

Visual Studio también le permite recorrer línea a línea un programa y supervisar su ejecución. Normalmente,
establecería un punto de interrupción y seguiría el flujo del programa mediante una pequeña parte de su código
de programa. Como este programa es pequeño, puede ejecutar paso a paso el programa entero.
1. Elija Depurar > Depurar paso a paso por instrucciones . Otra manera de depurar una instrucción cada
vez es presionar F11.
Visual Studio resalta y muestra una flecha junto a la siguiente línea de ejecución.
C#
 Visual Basic

En este punto, la ventana Variables locales muestra que la matriz args está vacía, y name y date tienen
valores predeterminados. Además, Visual Studio ha abierto una ventana de consola en blanco.
2. Presione F11. Visual Studio ahora resalta la siguiente línea de ejecución. La ventana Variables locales no
cambia y la ventana de consola permanece en blanco.
C#

Visual Basic

3. Presione F11. Visual Studio resalta la instrucción que incluye la asignación de variables name . La ventana
Variables locales muestra que name es null , y la ventana de consola muestra la cadena "What is your
name?".
4. Para responder a la solicitud, escriba una cadena en la ventana de consola y presione Entrar. La consola no
responde y la cadena que especificó no se muestra en la ventana de la consola, pero el método
Console.ReadLine capturará en cambio la entrada.
5. Presione F11. Visual Studio resalta la instrucción que incluye la asignación de la variable date (
currentDate en Visual Basic). La ventana Variables locales muestra el valor devuelto por la llamada al
método Console.ReadLine. La ventana de la consola también muestra la cadena que escribió en la solicitud.
6. Presione F11. La ventana Variables locales muestra el valor de la variable date tras la asignación desde
la propiedad DateTime.Now. La ventana de consola permanece sin cambios.
7. Presione F11. Visual Studio llama al método Console.WriteLine(String, Object, Object). La ventana de la
consola muestra la cadena con formato.
8. Elija Depurar > Depurar paso a paso para salir . Otra manera de detener la ejecución paso a paso es
presionar Mayús+F11.
La ventana de la consola muestra un mensaje y espera a que presione una tecla.
9. Presione cualquier tecla para cerrar la ventana de consola y detener la depuración.

Uso de la configuración de compilación de versión

Una vez que ha probado la versión de depuración de la aplicación, también debe compilar y probar la versión de
lanzamiento. La versión de lanzamiento incorpora optimizaciones del compilador que en ocasiones afectan
negativamente al comportamiento de una aplicación. Por ejemplo, las optimizaciones del compilador que están
diseñadas para mejorar el rendimiento pueden crear condiciones de carrera en aplicaciones multiproceso.
Para compilar y probar la versión de lanzamiento de la aplicación de la consola, cambie la configuración de
compilación en la barra de herramientas de Depurar a Versión .

Cuando presiona F5 o elije Compilar solución en el menú Compilar , Visual Studio compila la versión de
lanzamiento de la aplicación. Puede probarla como hizo con la versión de depuración.

Pasos siguientes
En este tutorial, ha usado las herramientas de depuración de Visual Studio. En el siguiente tutorial, publicará una
versión de la aplicación que se puede implementar.
Publicación de una aplicación de consola de .NET con Visual Studio
 Tutorial: Publicación de una aplicación de consola de
.NET con Visual Studio
18/12/2020 • 6 minutes to read • Edit Online

En este tutorial se muestra cómo publicar una aplicación de consola para que otros usuarios puedan ejecutarla. La
publicación crea el conjunto de archivos que se necesitan para ejecutar la aplicación. Para implementar los
archivos, cópielos en el equipo de destino.

Requisitos previos
Este tutorial funciona con la aplicación de consola que se crea en Creación de una aplicación de consola de .NET
con Visual Studio.

Publicar la aplicación
1. Inicie Visual Studio.
2. Abra el proyecto HelloWorld que ha creado en Creación de una aplicación de consola de .NET con
Visual Studio.
3. Asegúrese de que Visual Studio usa la configuración de compilación de versión. Si es necesario, cambie la
configuración de compilación en la barra de herramientas de Depurar a Versión .

4. Haga clic con el botón derecho en el proyecto HelloWorld (no en la solución HelloWorld) y seleccione
Publicar en el menú.

5. En la pestaña Destino de la página Publicar , seleccione Carpeta y luego Siguiente .

6. En la pestaña Destino específico de la página Publicar , seleccione Carpeta y luego Siguiente .

7. En la pestaña Ubicación de la página Publicar , seleccione Finalizar .

8. En la pestaña Publicar de la ventana Publicar , seleccione Publicar .

Inspección de los archivos

De forma predeterminada, el proceso de publicación crea una implementación dependiente del marco, que es un
tipo de implementación donde la aplicación publicada se ejecuta en un equipo con el entorno de ejecución de .NET
instalado. Los usuarios pueden ejecutar la aplicación publicada haciendo doble clic en el archivo ejecutable o
emitiendo el comando dotnet HelloWorld.dll desde un símbolo del sistema.
En los pasos siguientes, examinará los archivos creados por el proceso de publicación.
1. En el Explorador de soluciones , elija Mostrar todos los archivos .
2. En la carpeta del proyecto, expanda bin/Release/net5.0/publish.
Como se muestra en la imagen, el resultado publicado incluye los siguientes archivos:
HelloWorld.deps.json
Este es el archivo de dependencias en tiempo de ejecución de la aplicación. Define los componentes y
las bibliotecas de .NET (incluida la biblioteca de vínculos dinámicos que contiene la aplicación)
necesarios para ejecutar la aplicación. Para obtener más información, consulte Archivos de
configuración en tiempo de ejecución.
HelloWorld.dll
Esta es la versión de implementación dependiente del marco de la aplicación. Para ejecutar esta
biblioteca de vínculos dinámicos, escriba dotnet HelloWorld.dll en un símbolo del sistema. Este
método de ejecución de la aplicación funciona en cualquier plataforma que tenga instalado el
entorno de ejecución de .NET.
HelloWorld.exe
Esta es la versión del ejecutable dependiente del marco de la aplicación. Para ejecutarlo, escriba
HelloWorld.exe en un símbolo del sistema. El archivo es específico del sistema operativo.

HelloWorld.pdb (opcional para la implementación)

Este es el archivo de símbolos de depuración. No necesita implementar este archivo junto con su
aplicación, aunque se debe guardar en caso de que necesite depurar la versión publicada de la
aplicación.
 HelloWorld.runtimeconfig.json
Este es el archivo de configuración en tiempo de ejecución de la aplicación. Identifica la versión de
.NET en la que se ha compilado la aplicación para ejecutarse. También puede agregarle opciones de
configuración. Para obtener más información, vea Opciones de configuración en tiempo de ejecución
de .NET Core.

Ejecutar la aplicación publicada

1. En el Explorador de soluciones , haga clic con el botón derecho en la carpeta Publicar y seleccione
Copiar ruta de acceso completa .
2. Abra un símbolo del sistema y vaya a la carpeta Publicar. Para ello, escriba cd y pegue la ruta de acceso
completa. Por ejemplo:

cd C:\Projects\HelloWorld\bin\Release\netcoreapp3.1\publish\

3. Ejecute la aplicación con el archivo ejecutable:

a. Escriba HelloWorld.exe y presione ENTRAR.
b. Escriba un nombre cuando se le pida y presione cualquier tecla para salir.
4. Ejecute la aplicación mediante el comando dotnet :
a. Escriba dotnet HelloWorld.dll y presione ENTRAR.
b. Escriba un nombre cuando se le pida y presione cualquier tecla para salir.

Recursos adicionales
implementación de aplicaciones .NET

Pasos siguientes
En este tutorial, ha publicado una aplicación de consola. En el siguiente tutorial, creará una biblioteca de clases.
Creación de una biblioteca de clases de .NET con Visual Studio
 Tutorial: Creación de una biblioteca de clases de
.NET con Visual Studio
18/12/2020 • 12 minutes to read • Edit Online

En este tutorial, creará una sencilla clases de utilidades que contiene un único método de control de cadenas.
Una biblioteca de clases define los tipos y los métodos que se llaman desde una aplicación. Si la biblioteca tiene
como destino .NET Standard 2.0, se puede llamar mediante cualquier implementación de .NET (incluido
.NET Framework) que admita .NET Standard 2.0. Si la biblioteca tiene como destino .NET 5, la puede llamar
cualquier aplicación que tenga como destino .NET 5. En este tutorial se muestra cómo seleccionar .NET 5 como
destino.
Al crear una biblioteca de clases, puede distribuirla como un paquete NuGet o un componente empaquetado con
la aplicación en la que se usa.

Prerrequisitos
Visual Studio 2019, versión 16.8 o posterior con la carga de trabajo Desarrollo multiplataforma de
.NET Core instalada. El SDK de .NET 5.0 se instala automáticamente al seleccionar esta carga de trabajo. En
este tutorial se asume que ha habilitado Mostrar todas las plantillas de .NET Core en el nuevo
proyecto , como se muestra en Tutorial: Creación de una aplicación de consola de .NET con Visual Studio.

Crear una solución

Empiece por crear una solución en blanco para colocar el proyecto de biblioteca de clases en ella. Una solución de
Visual Studio sirve como contenedor de uno o varios proyectos. Agregará otros proyectos relacionados a la
misma solución.
Para crear la solución en blanco:
1. Inicie Visual Studio.
2. En la ventana de inicio, elija Crear un proyecto nuevo .
3. En el cuadro de búsqueda de la página Crear un nuevo proyecto , escriba solución . Elija la plantilla
Solución en blanco y luego seleccione Siguiente .
4. En la página Configure el nuevo proyecto , escriba ClassLibrar yProjects en el cuadro Nombre del
proyecto . Luego, elija Crear .

Crear un proyecto de biblioteca de clases

1. Agregue un nuevo proyecto de biblioteca de clases de .NET denominado "StringLibrary" a la solución.
a. Haga clic con el botón derecho en la solución en el Explorador de soluciones y seleccione
Agregar > Nuevo proyecto .
b. En el cuadro de búsqueda de la página Agregar un nuevo proyecto , escriba biblioteca . En la
lista de lenguajes, elija C# o Visual Basic y, luego, en la lista de plataformas, elija Todas las
plataformas . Elija la plantilla Biblioteca de clases y luego Siguiente .
c. En la página Configurar el nuevo proyecto , escriba StringLibrar y en el cuadro Nombre del
proyecto y, después, seleccione Siguiente .
d. En la página Información adicional , seleccione .NET 5.0 (actual) y después Crear .
2. Asegúrese de que la biblioteca tiene como destino la versión correcta de .NET. Haga clic con el botón
derecho en el proyecto de biblioteca en el Explorador de soluciones y, luego, seleccione Propiedades .
En el cuadro de texto Plataforma de destino se muestra que el proyecto tiene como destino .NET 5.0.
3. Si usa Visual Basic, borre el texto del cuadro de texto Espacio de nombres raíz .
 En cada proyecto, Visual Basic crea automáticamente un espacio de nombres que corresponde al nombre
del proyecto. En este tutorial, definirá un espacio de nombres de nivel superior mediante la palabra clave
namespace en el archivo de código.

4. Reemplace el código de la ventana de código por Class1.cs o Class1.vb y guarde el archivo. Si no se

muestra el idioma que quiere usar, cambie el selector de idioma en la parte superior de la página.

using System;

namespace UtilityLibraries
{
public static class StringLibrary
{
public static bool StartsWithUpper(this string str)
{
if (string.IsNullOrWhiteSpace(str))
return false;

char ch = str[0];
return char.IsUpper(ch);
}
}
}

Imports System.Runtime.CompilerServices

Namespace UtilityLibraries
Public Module StringLibrary
<Extension>
Public Function StartsWithUpper(str As String) As Boolean
If String.IsNullOrWhiteSpace(str) Then
Return False
End If

Dim ch As Char = str(0)

Return Char.IsUpper(ch)
End Function
End Module
End Namespace

La biblioteca de clases, UtilityLibraries.StringLibrary , contiene un método denominado

StartsWithUpper . Este método devuelve un valor Boolean que indica si la instancia de cadena actual
comienza con un carácter en mayúscula. El estándar Unicode distingue caracteres en mayúsculas de
caracteres en minúsculas. El método Char.IsUpper(Char) devuelve true si un carácter está en mayúsculas.
 se implementa como un método de extensión, de modo que se pueda llamar como si
StartsWithUpper
fuera un miembro de la clase String.
5. En la barra de menú, seleccione Compilar > Compilar solución , o bien presione Ctrl+Mayús+B, para
comprobar que el proyecto se compila sin errores.

Incorporación de una aplicación de consola a la solución

Agregue una aplicación de consola que use la biblioteca de clases. La aplicación solicitará al usuario que escriba
una cadena y notificará si la cadena comienza con un carácter en mayúsculas.
1. Agregue una nueva aplicación de consola de .NET denominada "ShowCase" a la solución.
a. Haga clic con el botón derecho en la solución en el Explorador de soluciones y seleccione
Agregar > Nuevo proyecto .
b. En el cuadro de búsqueda de la página Agregar un nuevo proyecto , escriba consola . Elija C# o
Visual Basic en la lista de lenguajes y luego, Todas las plataformas en la lista de plataformas.
c. Elija la plantilla Aplicación de consola y, después, seleccione Siguiente .
d. En la página Configure el nuevo proyecto , escriba ShowCase en el cuadro Nombre del
proyecto . Después, haga clic en Siguiente .
e. En la página Información adicional , seleccione .NET 5.0 (actual) en el cuadro Plataforma de
destino . Luego, elija Crear .
2. En la ventana de código del archivo Program.cs o Program.vb, reemplace todo el código con el siguiente
código.
using System;
using UtilityLibraries;

class Program
{
static void Main(string[] args)
{
int row = 0;

do
{
if (row == 0 || row >= 25)
ResetConsole();

string input = Console.ReadLine();

if (string.IsNullOrEmpty(input)) break;
Console.WriteLine($"Input: {input} {"Begins with uppercase? ",30}: " +
$"{(input.StartsWithUpper() ? "Yes" : "No")}\n");
row += 3;
} while (true);
return;

// Declare a ResetConsole local method

void ResetConsole()
{
if (row > 0)
{
Console.WriteLine("Press any key to continue...");
Console.ReadKey();
}
Console.Clear();
Console.WriteLine("\nPress <Enter> only to exit; otherwise, enter a string and press
<Enter>:\n");
row = 3;
}
}
}
 Imports UtilityLibraries

Module Program
Dim row As Integer = 0

Sub Main()
Do
If row = 0 OrElse row >= 25 Then ResetConsole()

Dim input As String = Console.ReadLine()

If String.IsNullOrEmpty(input) Then Return

Console.WriteLine($"Input: {input} {"Begins with uppercase? ",30}: " +

$"{If(input.StartsWithUpper(), "Yes", "No")} {vbCrLf}")
row += 3
Loop While True
End Sub

Private Sub ResetConsole()

If row > 0 Then
Console.WriteLine("Press any key to continue...")
Console.ReadKey()
End If
Console.Clear()
Console.WriteLine("{0}Press <Enter> only to exit; otherwise, enter a string and press <Enter>:
{0}",
vbCrLf)
row = 3
End Sub
End Module

El código usa la variable row para mantener un recuento del número de filas de datos escritas en la
ventana de consola. Siempre que sea mayor o igual a 25, el código borra la ventana de consola y muestra
un mensaje al usuario.
El programa le pide al usuario que escriba una cadena. Indica si la cadena comienza con un carácter en
mayúsculas. Si el usuario presiona la tecla Entrar sin especificar una cadena, la aplicación finaliza y la
ventana de la consola se cierra.

Agregar una referencia de proyecto

En un principio, el nuevo proyecto de aplicación de consola no tiene acceso a la biblioteca de clases. Para que
pueda llamar a los métodos de la biblioteca de clases, cree una referencia de proyecto al proyecto de biblioteca
de clases.
1. En el Explorador de soluciones , haga clic con el botón derecho en el nodo Dependencias del proyecto
ShowCase y seleccione Agregar referencia de proyecto .
2. En el cuadro de diálogo Administrador de referencias , seleccione el proyecto StringLibrar y y después
Aceptar .

Ejecutar la aplicación
1. En el Explorador de soluciones , haga clic con el botón derecho en el proyecto Presentación y
seleccione Establecer como proyecto de inicio en el menú contextual.
2. Presione CTRL+F5 para compilar y ejecutar el programa sin depuración.

3. Para probar el programa, escriba cadenas y presione Entrar y, después, presione Entrar para salir.

Recursos adicionales
Desarrollo de bibliotecas con la CLI de .NET
Versiones de .NET Standard y las plataformas que admiten.

Pasos siguientes
En este tutorial, ha creado una prueba unitaria de una biblioteca de clases. En el siguiente tutorial, aprenderá a
hacer una prueba unitaria de la biblioteca de clases.
Prueba unitaria de una biblioteca de clases de .NET con Visual Studio
También puede omitir las pruebas unitarias automatizadas y aprender a compartir la biblioteca mediante la
creación de un paquete NuGet:
Crear y publicar un paquete con Visual Studio
También puede obtener más información sobre cómo publicar una aplicación de consola. Si publica la aplicación
de consola a partir de la solución que ha creado en este tutorial, la biblioteca de clases lo incluirá como un
archivo .dll.
Publicación de una aplicación de consola de .NET con Visual Studio
 Tutorial: Prueba de una biblioteca de clases de .NET
con .NET mediante Visual Studio
18/12/2020 • 17 minutes to read • Edit Online

En este tutorial se muestra cómo automatizar las pruebas unitarias mediante la adición de un proyecto de prueba a
una solución.

Requisitos previos
Este tutorial funciona con la solución que se crea en Creación de una biblioteca de clases de .NET con
Visual Studio.

Crear un proyecto de prueba unitaria

Las pruebas unitarias proporcionan pruebas de software automatizadas durante el desarrollo y la publicación.
MSTest es uno de los tres marcos de pruebas que puede elegir. Los otros son xUnit y nUnit.
1. Inicie Visual Studio.
2. Abra la solución ClassLibraryProjects que ha creado en Creación de una biblioteca de clases de .NET con
Visual Studio.
3. Agregue un nuevo proyecto de prueba unitaria denominado "StringLibraryTest" a la solución.
a. Haga clic con el botón derecho en la solución en el Explorador de soluciones y seleccione
Agregar > Nuevo proyecto .
b. En el cuadro de búsqueda de la página Agregar un nuevo proyecto , escriba mstest . En la lista de
lenguajes, elija C# o Visual Basic y, luego, en la lista de plataformas, elija Todas las plataformas .
c. Seleccione la plantilla Proyecto de prueba unitaria y luego Siguiente .
d. En la página Configurar el nuevo proyecto , escriba StringLibrar yTest en el cuadro Nombre del
proyecto . Después, haga clic en Siguiente .
e. En la página Información adicional , seleccione .NET 5.0 (actual) en el cuadro Plataforma de
destino . Luego, elija Crear .
4. Visual Studio crea el proyecto y abre el archivo de clase en la ventana de código con el siguiente código. Si
no se muestra el idioma que quiere usar, cambie el selector de idioma en la parte superior de la página.

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace StringLibraryTest
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
}
}
}
 Imports Microsoft.VisualStudio.TestTools.UnitTesting

Namespace StringLibraryTest
<TestClass>
Public Class UnitTest1
<TestMethod>
Sub TestSub()

End Sub
End Class
End Namespace

El código fuente creado por la plantilla de prueba unitaria hace lo siguiente:

Importa el espacio de nombres de Microsoft.VisualStudio.TestTools.UnitTesting, que contiene los tipos
utilizados para las pruebas unitarias.
Aplica el atributo TestClassAttribute a la clase UnitTest1 .
Aplica el atributo TestMethodAttribute para definir TestMethod1 en C# o TestSub en Visual Basic.
Cada método etiquetado con [TestMethod] en una clase de prueba etiquetada con [TestClass] se ejecuta
automáticamente cuando se ejecuta la prueba unitaria.

Agregar una referencia de proyecto

Para que el proyecto de prueba funcione con la clase StringLibrary , agregue una referencia del proyecto
StringLibrar yTest al proyecto StringLibrary .
1. En el Explorador de soluciones , haga clic con el botón derecho en el nodo Dependencias del proyecto
StringLibrar yTest y seleccione Agregar referencia de proyecto del menú contextual.
2. En el cuadro de diálogo Administrador de referencias , expanda el nodo Proyectos y active la casilla
junto a StringLibrar y . Al agregar una referencia al ensamblado StringLibrary , el compilador puede
encontrar métodos StringLibrar y al compilar el proyecto StringLibrar yTest .
3. Seleccione Aceptar .

Adición y ejecución de métodos de prueba unitaria

Cuando Visual Studio ejecuta una prueba unitaria, ejecuta cada método marcado con el atributo
TestMethodAttribute en una clase que está marcada con el atributo TestClassAttribute. Un método de prueba
finaliza cuando se encuentra el primer error, o cuando todas las pruebas contenidas en el método se han realizado
correctamente.
Las pruebas más comunes llaman a los miembros de la clase Assert. Muchos métodos de aserción incluyen al
menos dos parámetros, uno de los cuales es el resultado esperado de la prueba y el otro es el resultado real de la
prueba. Algunos de los métodos Assert a los que se llama con más frecuencia se muestran en la tabla siguiente:

M ÉTO DO S DE A SERC IÓ N F UN C IÓ N

Assert.AreEqual Comprueba que dos valores u objetos son iguales. La aserción

da error si los valores o los objetos no son iguales.

Assert.AreSame Comprueba que dos variables de objeto hacen referencia al

mismo objeto. La aserción da error si las variables hacen
referencia a objetos diferentes.
 M ÉTO DO S DE A SERC IÓ N F UN C IÓ N

Assert.IsFalse Comprueba si una condición es false . La aserción produce

un error si la condición es true .

Assert.IsNotNull Comprueba que un objeto no es null . La aserción da error

si el objeto es null .

También puede usar el método Assert.ThrowsException en un método de prueba para indicar el tipo de excepción
que se espera que produzca. La prueba dará error si no se inicia la excepción especificada.
Al probar el método StringLibrary.StartsWithUpper , quiere proporcionar un número de cadenas que comiencen
con un carácter en mayúsculas. Espera que el método devuelva true en estos casos, por lo que puede llamar al
método Assert.IsTrue. Del mismo modo, quiere proporcionar un número de cadenas que comiencen con algo que
no sea un carácter en mayúsculas. Espera que el método devuelva false en estos casos, por lo que puede llamar
al método Assert.IsFalse.
Dado que el método de biblioteca administra cadenas, quiere asegurarse también de que administra
correctamente una cadena vacía ( String.Empty ), una cadena válida que no tenga caracteres y cuyo Length sea 0, y
una cadena null que no se haya inicializado. Se puede llamar a StartsWithUpper directamente como un método
estático y pasar un argumento String único. También puede llamar a StartsWithUpper como método de extensión
en una variable de string asignada a null .
Definirá tres métodos, cada uno de los cuales llama a un método Assert para cada elemento de una matriz de
cadenas. Llamará a una sobrecarga de método que le permite especificar que se muestre un mensaje de error en
caso de error en la prueba. El mensaje identifica la cadena que causó el error.
Para crear los métodos de prueba:
1. En la ventana de código UnitTest1.cs o UnitTest1.vb, reemplace el código por el siguiente:
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using UtilityLibraries;

namespace StringLibraryTest
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestStartsWithUpper()
{
// Tests that we expect to return true.
string[] words = { "Alphabet", "Zebra", "ABC", "Αθήνα", "Москва" };
foreach (var word in words)
{
bool result = word.StartsWithUpper();
Assert.IsTrue(result,
String.Format("Expected for '{0}': true; Actual: {1}",
word, result));
}
}

[TestMethod]
public void TestDoesNotStartWithUpper()
{
// Tests that we expect to return false.
string[] words = { "alphabet", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",
"1234", ".", ";", " " };
foreach (var word in words)
{
bool result = word.StartsWithUpper();
Assert.IsFalse(result,
String.Format("Expected for '{0}': false; Actual: {1}",
word, result));
}
}

[TestMethod]
public void DirectCallWithNullOrEmpty()
{
// Tests that we expect to return false.
string[] words = { string.Empty, null };
foreach (var word in words)
{
bool result = StringLibrary.StartsWithUpper(word);
Assert.IsFalse(result,
String.Format("Expected for '{0}': false; Actual: {1}",
word == null ? "<null>" : word, result));
}
}
}
}
 Imports Microsoft.VisualStudio.TestTools.UnitTesting
Imports UtilityLibraries

Namespace StringLibraryTest
<TestClass>
Public Class UnitTest1
<TestMethod>
Public Sub TestStartsWithUpper()
' Tests that we expect to return true.
Dim words() As String = {"Alphabet", "Zebra", "ABC", "Αθήνα", "Москва"}
For Each word In words
Dim result As Boolean = word.StartsWithUpper()
Assert.IsTrue(result,
$"Expected for '{word}': true; Actual: {result}")
Next
End Sub

<TestMethod>
Public Sub TestDoesNotStartWithUpper()
' Tests that we expect to return false.
Dim words() As String = {"alphabet", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",
"1234", ".", ";", " "}
For Each word In words
Dim result As Boolean = word.StartsWithUpper()
Assert.IsFalse(result,
$"Expected for '{word}': false; Actual: {result}")
Next
End Sub

<TestMethod>
Public Sub DirectCallWithNullOrEmpty()
' Tests that we expect to return false.
Dim words() As String = {String.Empty, Nothing}
For Each word In words
Dim result As Boolean = StringLibrary.StartsWithUpper(word)
Assert.IsFalse(result,
$"Expected for '{If(word Is Nothing, "<null>", word)}': false; Actual: {result}")
Next
End Sub
End Class
End Namespace

La prueba de caracteres en mayúsculas en el método TestStartsWithUpper incluye la letra mayúscula griega

alfa (U + 0391) y la letra mayúscula cirílica EM (U + 041C). La prueba de caracteres en minúsculas en el
método TestDoesNotStartWithUpper incluye la letra griega minúscula alfa (U + 03B1) y la letra cirílica
minúscula Ghe (U + 0433).
2. En la barra de menús, seleccione Archivo > Guardar UnitTest1.cs como o Archivo > Guardar
UnitTest1.vb como . En el cuadro de diálogo Guardar archivo como , seleccione la flecha junto al botón
Guardar y seleccione Guardar con codificación .
3. En el cuadro de diálogo Confirmar guardar como , seleccione el botón Sí para guardar el archivo.
4. En el cuadro de diálogo Opciones avanzadas para guardar , seleccione Unicode (UTF-8 con firma) -
Página de códigos 65001 desde la lista desplegable Codificación y seleccione Aceptar .

Si obtiene un error al guardar el código fuente en un archivo con codificación UTF-8, Visual Studio puede
guardarlo como un archivo ASCII. Cuando eso suceda, el tiempo de ejecución no descodifica correctamente
los caracteres UTF-8 del rango ASCII, y los resultados de la prueba no serán correctos.
5. En la barra de menús, seleccione Prueba > Ejecutar todas las pruebas . Si no se abre la ventana
Explorador de pruebas , ábrala mediante Prueba > Explorador de pruebas . Las tres pruebas se
muestran en la sección Pruebas superadas y en la sección Resumen se informa del resultado de la serie
de pruebas.
Administración de errores de prueba
Si está realizando el desarrollo controlado por pruebas (TDD), escribirá las pruebas, y estas generarán un error
cuando las ejecute por primera vez. Después, agregará un código a la aplicación para que la prueba se realice
correctamente. En este tutorial, ha creado la prueba después de escribir el código de la aplicación que valida, por lo
que no ha podido comprobar si la prueba genera un error. Para asegurarse de que una prueba genera un error
cuando espera que lo haga, agregue un valor no válido a la entrada de prueba.
1. Modifique la matriz words en el método TestDoesNotStartWithUpper para incluir la cadena "Error". No
necesita guardar el archivo porque Visual Studio guarda automáticamente archivos abiertos cuando se crea
una solución para ejecutar pruebas.

string[] words = { "alphabet", "Error", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",

"1234", ".", ";", " " };

Dim words() As String = { "alphabet", "Error", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",

"1234", ".", ";", " " }

2. Ejecute la prueba seleccionando Prueba > Ejecutar todas las pruebas de la barra de menús. En la
ventana Explorador de pruebas se indica que dos pruebas se han realizado correctamente y que una ha
finalizado con errores.
3. Seleccione la prueba con errores, TestDoesNotStartWith .
En la ventana Explorador de pruebas se muestra el mensaje generado por la instrucción Assert: "Error de
Assert.IsFalse. Se esperaba para "Error": false; real: True". Debido al error, no se probaron todas las cadenas
de la matriz después de "Error".

4. Quite la cadena "Error" que agregó en el paso 1. Vuelva a ejecutar la prueba y se superarán las pruebas.

Prueba de la versión de la biblioteca

Ahora que se han superado todas las pruebas al ejecutar la versión de depuración de la biblioteca, ejecute las
pruebas una vez más con la versión de lanzamiento de la biblioteca. Varios factores, como las optimizaciones del
compilador, a veces pueden producir un comportamiento diferente entre las compilaciones de depuración y
versión.
Para probar la compilación de versión:
1. En la barra de herramientas de Visual Studio, cambie la configuración de compilación de Depurar a
Versión .

2. En el Explorador de soluciones , haga clic con el botón derecho en el proyecto StringLibrar y y

seleccione Compilar desde el menú contextual para volver a compilar la biblioteca.

3. Ejecute las pruebas unitarias mediante Ejecutar prueba > Todas las pruebas de la barra de menús. Las
pruebas se superan.

Depuración de pruebas
Si usa Visual Studio como IDE, puede emplear el mismo proceso que se muestra en Tutorial: Depuración de una
aplicación de consola de .NET con Visual Studio para depurar el código mediante el proyecto de prueba unitaria. En
lugar de iniciar el proyecto de aplicación ShowCase, haga clic con el botón derecho en el proyecto
StringLibrar yTests y seleccione Depurar pruebas en el menú contextual.
Visual Studio inicia el proyecto de prueba con el depurador asociado. La ejecución se detendrá en cualquier punto
de interrupción que haya agregado al proyecto de prueba o al código de la biblioteca subyacente.
Recursos adicionales
Conceptos básicos de las pruebas unitarias en Visual Studio
Pruebas unitarias en .NET

Pasos siguientes
En este tutorial, ha realizado una prueba unitaria de una biblioteca de clases. Puede poner la biblioteca a
disposición de otros usuarios si la publica en NuGet como un paquete. Para obtener información sobre cómo
hacerlo, realice este tutorial de NuGet:
Creación y publicación de un paquete NuGet con Visual Studio
Si publica una biblioteca como un paquete NuGet, otros usuarios pueden instalarla y usarla. Para obtener
información sobre cómo hacerlo, realice este tutorial de NuGet:
Instalación y uso de un paquete en Visual Studio
No es necesario distribuir una biblioteca como un paquete. Se puede agrupar con una aplicación de consola que la
use. Para aprender a publicar una aplicación de consola, vea el tutorial anterior de esta serie:
Publicación de una aplicación de consola de .NET con Visual Studio
 Tutorial: Creación de una aplicación de consola de
.NET con Visual Studio Code
18/12/2020 • 6 minutes to read • Edit Online

En este tutorial se muestra cómo crear y ejecutar una aplicación de consola de .NET mediante Visual Studio
Code y la CLI de .NET. Las tareas de proyecto, como crear, compilar y ejecutar un proyecto, se realizan
mediante la CLI de .NET. Puede seguir este tutorial con un editor de código diferente y ejecutar comandos en
un terminal si lo prefiere.

Requisitos previos
1. Visual Studio Code con la extensión de C# instalada. Para saber cómo instalar extensiones en
Visual Studio Code, vea el Marketplace de extensiones de VS Code.
2. SDK de .NET 5.0 o posterior

Creación de la aplicación
Cree un proyecto de aplicación de consola de .NET denominado "HelloWorld".
1. Inicie Visual Studio Code.
2. Seleccione Archivo > Abrir carpeta (Archivo > Abrir... en macOS) en el menú principal.
3. En el cuadro de diálogo Abrir carpeta , cree una carpeta de HelloWorld y haga clic en Seleccionar
carpeta (Abrir en macOS).
De forma predeterminada, el nombre de la carpeta se convierte en el nombre del proyecto y del
espacio de nombres. Más adelante en el tutorial, agregará código que supone que el espacio de
nombres del proyecto es HelloWorld .
4. Para abrir el Terminal en Visual Studio Code, seleccione Ver > Terminal en el menú principal.
Se abre el Terminal con el símbolo del sistema en la carpeta HelloWorld.
5. En el Terminal , escriba este comando:

dotnet new console

La plantilla crea una aplicación "Hola mundo" sencilla. Llama al método Console.WriteLine(String) para
mostrar "Hello World!" en la ventana de la consola.
El código de plantilla define una clase, Program , con un solo método, Main , que toma una matriz de String
como argumento:
 using System;

namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

Main es el punto de entrada de la aplicación, el método que se llama automáticamente mediante el tiempo
de ejecución cuando inicia la aplicación. Los argumentos de línea de comandos proporcionados cuando se
inicia la aplicación están disponibles en la matriz args.

Ejecutar la aplicación
Ejecute este comando en el Terminal :

dotnet run

El programa muestra "Hola mundo" y finaliza.

Mejora de la aplicación
Mejore la aplicación para pedir su nombre al usuario y mostrarlo con la fecha y la hora.
1. Haga clic en el archivo Program.cs para abrirlo.
La primera vez que se abre un archivo de C# en Visual Studio Code, se carga OmniSharp en el editor.
2. Seleccione Sí cuando Visual Studio Code le pida que agregue los recursos que faltan para compilar y
depurar la aplicación.

3. Reemplace el contenido del método Main en Program.cs, que es la línea que llama a
Console.WriteLine , por este código:

Console.WriteLine("\nWhat is your name? ");

var name = Console.ReadLine();
var date = DateTime.Now;
Console.WriteLine($"\nHello, {name}, on {date:d} at {date:t}!");
Console.Write("\nPress any key to exit...");
Console.ReadKey(true);

Este código muestra un mensaje en la ventana de la consola y espera a que el usuario escriba una
cadena y, luego, presione Entrar. Almacena esta cadena en una variable denominada name . También
recupera el valor de la propiedad DateTime.Now, que contiene la hora local actual, y lo asigna a una
variable denominada date . Asimismo, muestra estos valores en la ventana de la consola. Por último,
muestra un mensaje en la ventana de la consola y llama al método Console.ReadKey(Boolean) para
esperar a la entrada del usuario.
El símbolo \n representa un carácter de nueva línea.
El signo de dólar ( $ ) delante de una cadena permite colocar expresiones como nombres de variable
entre llaves en la cadena. El valor de la expresión se inserta en la cadena en lugar de la expresión. Esta
sintaxis se conoce como cadenas interpoladas.
4. Guarde los cambios.
 IMPORTANT
En Visual Studio Code, tiene que guardar los cambios explícitamente. A diferencia de Visual Studio, los cambios
de los archivos no se guardan automáticamente al compilar y ejecutar una aplicación.

5. Ejecute el programa otra vez:

dotnet run

6. Responda a la solicitud escribiendo un nombre y presionando la tecla Entrar.

7. Presione cualquier tecla para salir de la aplicación.

Recursos adicionales
Setting up Visual Studio Code (Configuración de Visual Studio Code)

Pasos siguientes
En este tutorial, ha creado una aplicación de consola de .NET. En el siguiente tutorial, depurará la aplicación.
Depuración de una aplicación de consola de .NET con Visual Studio Code
 Tutorial: Depuración de una aplicación de consola de
.NET con Visual Studio Code
18/12/2020 • 14 minutes to read • Edit Online

En este tutorial se presentan las herramientas de depuración disponibles en Visual Studio Code para trabajar con
aplicaciones de .NET.

Requisitos previos
Este tutorial funciona con la aplicación de consola que se crea en Creación de una aplicación de consola de .NET
con Visual Studio Code.

Uso de la configuración de compilación de depuración

Depuración y Versión son las configuraciones de compilación integradas de .NET Core. Use la configuración de
compilación Depuración para depurar y la configuración de compilación Versión para la distribución final de la
versión.
En la configuración de depuración, el programa se compila sin optimizar y con toda la información de depuración
simbólica. La optimización complica la depuración, ya que la relación entre el código fuente y las instrucciones
generadas es más compleja. La configuración de versión del programa no contiene información de depuración
simbólica y está totalmente optimizada.
De forma predeterminada, la configuración de lanzamiento de Visual Studio Code usa la configuración de
compilación Depuración, por lo que no es necesario cambiarla antes de realizar esta operación.
1. Inicie Visual Studio Code.
2. Abra la carpeta del proyecto que ha creado en Creación de una aplicación de consola de .NET con
Visual Studio Code.

Establecer un punto de interrupción

Un punto de interrupción interrumpe temporalmente la ejecución de la aplicación antes de que se ejecute la línea
con el punto de interrupción.
1. Abra el archivo Program.cs.
2. Establezca un punto de interrupción en la línea que muestre el nombre, la fecha y la hora; para ello, haga
clic en el margen izquierdo de la ventana de código. El margen izquierdo está a la izquierda de los números
de línea. Otras maneras de establecer un punto de interrupción consisten en presionar F9 o seleccionar
Ejecutar > Alternar punto de interrupción en el menú mientras se elige la línea de código.
Visual Studio Code marca la línea donde se establece el punto de interrupción con un punto rojo en el
margen izquierdo.
Configuración para la entrada de terminal
El punto de interrupción se encuentra después de una llamada al método Console.ReadLine . La Consola de
depuración no acepta la entrada de terminal para un programa en ejecución. Para controlar la entrada de
terminal durante la depuración, puede usar el terminal integrado (una de las ventanas de Visual Studio Code) o un
terminal externo. En este tutorial, usará el terminal integrado.
1. Abra .vscode/launch.json.
2. Cambie la opción console de internalConsole a integratedTerminal :

"console": "integratedTerminal",

3. Guarde los cambios.

Iniciar depuración
1. Abra la vista Depurar mediante el icono de depuración que hay en el menú de la izquierda.
2. Seleccione la flecha verde en la parte superior del panel, junto a .NET Core Launch (console) (Inicio de
.NET Core [consola]). Otras maneras de iniciar el programa en modo de depuración son presionar F5 o
elegir Ejecutar > Iniciar depuración en el menú.

3. Seleccione la pestaña Terminal para ver el mensaje "What is your name?" que muestra el programa antes
de esperar una respuesta.

4. Escriba una cadena en la ventana Terminal para responder a la pregunta del nombre y presione Entrar.
La ejecución del programa se detiene cuando llega al punto de interrupción y antes de que se ejecute el
 método Console.WriteLine . La sección Variables locales de la ventana Variables muestra los valores de
las variables definidas en el método que se ejecuta actualmente.

Uso de la consola de depuración

La ventana Consola de depuración permite interactuar con la aplicación que está depurando. Puede cambiar el
valor de las variables para ver cómo afecta esto a su programa.
1. Seleccione la pestaña Consola de depuración .
2. Escriba name = "Gracie" en el símbolo del sistema de la parte inferior de la ventana Consola de
depuración y presione la tecla Entrar.

3. Escriba date = DateTime.Parse("2019-11-16T17:25:00Z").ToUniversalTime() en la parte inferior de la ventana

Consola de depuración y presione la tecla Entrar.
 La ventana Variables muestra los nuevos valores de las variables name y date .
4. Para continuar con la ejecución del programa, seleccione el botón Continuar en la barra de herramientas.
Otra manera de continuar es presionar F5.

5. Seleccione de nuevo la pestaña Terminal .

Los valores mostrados en la ventana de la consola corresponden a los cambios realizados en Consola de
depuración .

6. Presione cualquier tecla para salir de la aplicación y detenga la depuración.

Establecimiento de un punto de interrupción condicional

El programa muestra la cadena que escribe el usuario. ¿Qué sucede si el usuario no escribe nada? Puede probarlo
con una característica de depuración muy útil denominada Punto de interrupción condicional.
1. Haga clic con el botón derecho (o presione Ctrl y haga clic en macOS) sobre el punto rojo que representa
al punto de interrupción. En el menú contextual, seleccione Editar punto de interrupción y se abrirá un
cuadro de diálogo donde podrá escribir una expresión condicional.

2. Seleccione Expression en el menú desplegable, escriba esta expresión condicional y presione Entrar.

String.IsNullOrEmpty(name)
 Cada vez que se alcanza el punto de interrupción, el depurador llama al método
String.IsNullOrEmpty(name) y se interrumpe en esta línea solo si la llamada al método devuelve true .
En lugar de una expresión condicional, puede especificar un número de llamadas, que interrumpe la
ejecución del programa antes de que se ejecute una instrucción un número de veces especificado. Otra
opción consiste en especificar una condición de filtro, que interrumpe la ejecución del programa en función
de atributos tales como un identificador de subproceso, un nombre de proceso o un nombre de
subproceso.
3. Inicie el programa con la depuración presionando F5.
4. En la ventana Terminal, cuando se le pida que escriba su nombre, presione la tecla Entrar .
Como se ha cumplido la condición que especificó ( name es null o String.Empty), la ejecución del
programa se detiene cuando se alcanza el punto de interrupción y antes de que se ejecute el método
Console.WriteLine .

La ventana Variables muestra que el valor de la variable name es "" o String.Empty.

5. Confirme que el valor es una cadena vacía; para ello, escriba esta instrucción en la ventana Consola de
depuración y presionando Entrar. El resultado es true .

name == String.Empty
6. Seleccione el botón Continuar en la barra de herramientas para continuar la ejecución del programa.
7. Seleccione la pestaña Terminal y presione cualquier tecla para salir del programa y detener la depuración.
8. Para borrar el punto de interrupción, haga clic en el punto en el margen izquierdo de la ventana de código.
Otras formas de borrar un punto de interrupción consisten en presionar F9 o elegir Ejecutar > Alternar
punto de interrupción en el menú mientras se selecciona la línea de código.
9. Si recibe una advertencia que indica que se perderá la condición del punto de interrupción, seleccione
Quitar punto de interrupción .

Ejecución paso a paso de un programa

Visual Studio Code también permite recorrer línea a línea un programa y supervisar su ejecución. Normalmente,
establecería un punto de interrupción y seguiría el flujo del programa mediante una pequeña parte de su código
de programa. Como este programa es pequeño, puede ejecutar paso a paso el programa entero.
1. Establezca un punto de interrupción en la llave de apertura del método Main .
2. Presiona F5 para iniciar la depuración.
Visual Studio Code resalta la línea del punto de interrupción.
En este punto, la ventana Variables muestra que la matriz args está vacía, y name y date tienen valores
predeterminados.
3. Seleccione Ejecutar > Paso a paso por instrucciones o presione F11.

Visual Studio Code resalta la línea siguiente.

4. Seleccione Ejecutar > Paso a paso por instrucciones o presione F11.
Visual Studio Code ejecuta Console.WriteLine para el mensaje de nombre y resalta la siguiente línea de
 ejecución. La línea siguiente es Console.ReadLine para name . La ventana Variables no cambia y la pestaña
Terminal muestra el mensaje "What is your name?" .
5. Seleccione Ejecutar > Paso a paso por instrucciones o presione F11.
Visual Studio resalta la asignación de la variable name . La ventana Variables muestra que name todavía es
null .

6. Para responder al mensaje, escriba una cadena en la ventana Terminal y presione Entrar.
Es posible que la pestaña Terminal no muestre la cadena mientras la está escribiendo, pero el método
Console.ReadLine capturará la entrada.
7. Seleccione Ejecutar > Paso a paso por instrucciones o presione F11.
Visual Studio Code resalta la asignación de la variable date . La ventana Variables muestra el valor
devuelto por la llamada al método Console.ReadLine. En la pestaña Terminal se muestra la cadena que
escribió en el símbolo del sistema.
8. Seleccione Ejecutar > Paso a paso por instrucciones o presione F11.
La ventana Variables muestra el valor de la variable date tras la asignación desde la propiedad
DateTime.Now.
9. Seleccione Ejecutar > Paso a paso por instrucciones o presione F11.
Visual Studio Code llama al método Console.WriteLine(String, Object, Object). La ventana de la consola
muestra la cadena con formato.
10. Seleccione Ejecutar > Paso a paso para salir o presione Mayús+F11.

11. Seleccione la pestaña Terminal .

El terminal muestra "Presione cualquier tecla para salir..."
12. Presione cualquier tecla para salir de la aplicación.

Uso de la configuración de compilación de versión

Una vez que ha probado la versión de depuración de la aplicación, también debe compilar y probar la versión de
lanzamiento. La versión de lanzamiento incorpora optimizaciones del compilador que pueden afectar al
comportamiento de una aplicación. Por ejemplo, las optimizaciones del compilador que están diseñadas para
mejorar el rendimiento pueden crear condiciones de carrera en aplicaciones multiproceso.
Para compilar y probar la versión de lanzamiento de la aplicación de consola, abra el Terminal y ejecute este
comando:

dotnet run --configuration Release

Recursos adicionales
Debugging in Visual Studio Code (Depuración en Visual Studio Code)

Pasos siguientes
En este tutorial, ha usado las herramientas de depuración de Visual Studio Code. En el siguiente tutorial, publicará
una versión de la aplicación que se puede implementar.
Publicación de una aplicación de consola de .NET con Visual Studio Code
 Tutorial: Publicación de una aplicación de consola de
.NET con Visual Studio Code
18/12/2020 • 6 minutes to read • Edit Online

En este tutorial se muestra cómo publicar una aplicación de consola para que otros usuarios puedan ejecutarla. La
publicación crea el conjunto de archivos que se necesitan para ejecutar una aplicación. Para implementar los
archivos, cópielos en el equipo de destino.
La CLI de .NET se usa para publicar la aplicación, por lo que puede seguir este tutorial con un editor de código que
no sea Visual Studio Code si lo prefiere.

Requisitos previos
Este tutorial funciona con la aplicación de consola que se crea en Creación de una aplicación de consola de .NET
con Visual Studio Code.

Publicar la aplicación
1. Inicie Visual Studio Code.
2. Abra la carpeta de proyecto HelloWorld que ha creado en Creación de una aplicación de consola de .NET
con Visual Studio Code.
3. Elija Ver > Terminal en el menú principal.
Se abrirá el terminal en la carpeta HelloWorld.
4. Ejecute el siguiente comando:

dotnet publish --configuration Release

La configuración de compilación predeterminada es Depuración, por lo que este comando especifica la

versión de la configuración de compilación Versión. La salida de la configuración de compilación Versión
tiene muy poca información de depuración simbólica y está totalmente optimizada.
La salida del comando es similar al ejemplo siguiente:

Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET

Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
All projects are up-to-date for restore.
HelloWorld -> C:\Projects\HelloWorld\bin\Release\netcoreapp3.1\HelloWorld.dll
HelloWorld -> C:\Projects\HelloWorld\bin\Release\netcoreapp3.1\publish\

Inspección de los archivos

De forma predeterminada, el proceso de publicación crea una implementación dependiente del marco, que es un
tipo de implementación donde la aplicación publicada se ejecuta en un equipo que tenga instalado el entorno de
ejecución de .NET. Para ejecutar la aplicación publicada, puede usar el archivo ejecutable o ejecutar el comando
dotnet HelloWorld.dll desde un símbolo del sistema.
En los pasos siguientes, examinará los archivos creados por el proceso de publicación.
1. Seleccione Explorador en la barra de navegación izquierda.
2. Expanda bin/Release/net5.0/publish.

Como se muestra en la imagen, el resultado publicado incluye los siguientes archivos:

HelloWorld.deps.json
Este es el archivo de dependencias en tiempo de ejecución de la aplicación. Define los componentes y
las bibliotecas de .NET (incluida la biblioteca de vínculos dinámicos que contiene la aplicación)
necesarios para ejecutar la aplicación. Para obtener más información, consulte Archivos de
configuración en tiempo de ejecución.
HelloWorld.dll
Esta es la versión de implementación dependiente del marco de la aplicación. Para ejecutar esta
biblioteca de vínculos dinámicos, escriba dotnet HelloWorld.dll en un símbolo del sistema. Este
método de ejecución de la aplicación funciona en cualquier plataforma que tenga instalado el
entorno de ejecución de .NET.
 HelloWorld.exe (HelloWorld en Linux, no creada en macOS).
Esta es la versión del ejecutable dependiente del marco de la aplicación. El archivo es específico del
sistema operativo.
HelloWorld.pdb (opcional para la implementación)
Este es el archivo de símbolos de depuración. No necesita implementar este archivo junto con su
aplicación, aunque se debe guardar en caso de que necesite depurar la versión publicada de la
aplicación.
HelloWorld.runtimeconfig.json
Este es el archivo de configuración en tiempo de ejecución de la aplicación. Identifica la versión de
.NET en la que se ha compilado la aplicación para ejecutarse. También puede agregarle opciones de
configuración. Para obtener más información, vea Opciones de configuración en tiempo de ejecución
de .NET Core.

Ejecutar la aplicación publicada

1. En el Explorador , haga clic con el botón derecho en la carpeta publish (o presione Ctrl y haga clic en
macOS) y seleccione Abrir en terminal .

2. En Windows o Linux, ejecute la aplicación con el archivo ejecutable.

a. En Windows, escriba .\HelloWorld.exe y presione Entrar.
b. En Linux, escriba ./HelloWorld y presione Entrar.
c. Escriba un nombre cuando se le pida y presione cualquier tecla para salir.
3. En cualquier plataforma, ejecute la aplicación con el comando dotnet :
 a. Escriba dotnet HelloWorld.dll y presione ENTRAR.
b. Escriba un nombre cuando se le pida y presione cualquier tecla para salir.

Recursos adicionales
implementación de aplicaciones .NET

Pasos siguientes
En este tutorial, ha publicado una aplicación de consola. En el siguiente tutorial, creará una biblioteca de clases.
Creación de una biblioteca de clases de .NET con Visual Studio Code
 Tutorial: Creación de una biblioteca de clases de
.NET con Visual Studio Code
18/12/2020 • 9 minutes to read • Edit Online

En este tutorial, creará una sencilla biblioteca de utilidades que contiene un único método de control de cadenas.
Una biblioteca de clases define los tipos y los métodos que se llaman desde una aplicación. Si la biblioteca tiene
como destino .NET Standard 2.0, se puede llamar mediante cualquier implementación de .NET (incluido
.NET Framework) que admita .NET Standard 2.0. Si la biblioteca tiene como destino .NET 5, la puede llamar
cualquier aplicación que tenga como destino .NET 5. En este tutorial se muestra cómo seleccionar .NET 5 como
destino.
Al crear una biblioteca de clases, puede distribuirla como un componente de terceros o como un componente
empaquetado con una o varias aplicaciones.

Requisitos previos
1. Visual Studio Code con la extensión de C# instalada. Para saber cómo instalar extensiones en
Visual Studio Code, vea el Marketplace de extensiones de VS Code.
2. SDK de .NET 5.0 o posterior

Crear una solución

Empiece por crear una solución en blanco para colocar el proyecto de biblioteca de clases en ella. Una solución
sirve como contenedor de uno o varios proyectos. Agregará otros proyectos relacionados a la misma solución.
1. Inicie Visual Studio Code.
2. Seleccione Archivo > Abrir carpeta (Abrir... en macOS) en el menú principal.
3. En el cuadro de diálogo Abrir carpeta , cree una carpeta ClassLibraryProjects y haga clic en Seleccionar
carpeta (Abrir en macOS).
4. Para abrir el Terminal en Visual Studio Code, seleccione Ver > Terminal en el menú principal.
Se abre el terminal con el símbolo del sistema en la carpeta ClassLibraryProjects.
5. En el Terminal , escriba este comando:

dotnet new sln

La salida del terminal se parece al ejemplo siguiente:

The template "Solution File" was created successfully.

Crear un proyecto de biblioteca de clases

Agregue un nuevo proyecto de biblioteca de clases de .NET denominado "StringLibrary" a la solución.
1. En el terminal, ejecute el siguiente comando para crear un proyecto de biblioteca:
 dotnet new classlib -o StringLibrary

El comando -o o --output especifica la ubicación para colocar la salida generada.

La salida del terminal se parece al ejemplo siguiente:

The template "Class library" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on StringLibrary\StringLibrary.csproj...
Determining projects to restore...
Restored C:\Projects\ClassLibraryProjects\StringLibrary\StringLibrary.csproj (in 328 ms).
Restore succeeded.

2. Ejecute el siguiente comando para agregar el proyecto de biblioteca a la solución:

dotnet sln add StringLibrary/StringLibrary.csproj

La salida del terminal se parece al ejemplo siguiente:

Project `StringLibrary\StringLibrary.csproj` added to the solution.

3. Asegúrese de que la biblioteca tiene como destino .NET 5. En Explorer , abra el archivo
StringLibrary/StringLibrary.csproj.
En el elemento TargetFramework se muestra que el proyecto tiene como destino .NET 5.0.

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>

</Project>

4. Abra Class1.cs y reemplace el código por el siguiente.

using System;

namespace UtilityLibraries
{
public static class StringLibrary
{
public static bool StartsWithUpper(this string str)
{
if (string.IsNullOrWhiteSpace(str))
return false;

char ch = str[0];
return char.IsUpper(ch);
}
}
}

La biblioteca de clases, UtilityLibraries.StringLibrary , contiene un método denominado StartsWithUpper

. Este método devuelve un valor Boolean que indica si la instancia de cadena actual comienza con un
carácter en mayúscula. El estándar Unicode distingue caracteres en mayúsculas de caracteres en
 minúsculas. El método Char.IsUpper(Char) devuelve true si un carácter está en mayúsculas.
5. Guarde el archivo.
6. Ejecute el siguiente comando para compilar la solución y comprobar que el proyecto se compila sin errores.

dotnet build

La salida del terminal se parece al ejemplo siguiente:

Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET

Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
All projects are up-to-date for restore.
StringLibrary -> C:\Projects\ClassLibraryProjects\StringLibrary\bin\Debug\net5.0\StringLibrary.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:02.78

Incorporación de una aplicación de consola a la solución

Agregue una aplicación de consola que use la biblioteca de clases. La aplicación solicitará al usuario que escriba
una cadena y notificará si la cadena comienza con un carácter en mayúsculas.
1. En el terminal, ejecute el siguiente comando para crear un proyecto de consola de aplicación:

dotnet new console -o ShowCase

La salida del terminal se parece al ejemplo siguiente:

The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on ShowCase\ShowCase.csproj...
Determining projects to restore...
Restored C:\Projects\ClassLibraryProjects\ShowCase\ShowCase.csproj (in 210 ms).
Restore succeeded.

2. Ejecute el siguiente comando para agregar el proyecto de aplicación de consola a la solución:

dotnet sln add ShowCase/ShowCase.csproj

La salida del terminal se parece al ejemplo siguiente:

Project `ShowCase\ShowCase.csproj` added to the solution.

3. Abra ShowCase/Program.cs y reemplace todo el código por el siguiente.

 using System;
using UtilityLibraries;

class Program
{
static void Main(string[] args)
{
int row = 0;

do
{
if (row == 0 || row >= 25)
ResetConsole();

string input = Console.ReadLine();

if (string.IsNullOrEmpty(input)) break;
Console.WriteLine($"Input: {input} {"Begins with uppercase? ",30}: " +
$"{(input.StartsWithUpper() ? "Yes" : "No")}\n");
row += 3;
} while (true);
return;

// Declare a ResetConsole local method

void ResetConsole()
{
if (row > 0)
{
Console.WriteLine("Press any key to continue...");
Console.ReadKey();
}
Console.Clear();
Console.WriteLine("\nPress <Enter> only to exit; otherwise, enter a string and press
<Enter>:\n");
row = 3;
}
}
}

El código usa la variable row para mantener un recuento del número de filas de datos escritas en la
ventana de consola. Siempre que sea mayor o igual a 25, el código borra la ventana de consola y muestra
un mensaje al usuario.
El programa le pide al usuario que escriba una cadena. Indica si la cadena comienza con un carácter en
mayúsculas. Si el usuario presiona la tecla Entrar sin especificar una cadena, la aplicación finaliza y la
ventana de la consola se cierra.
4. Guarde los cambios.

Agregar una referencia de proyecto

En un principio, el nuevo proyecto de aplicación de consola no tiene acceso a la biblioteca de clases. Para que
pueda llamar a los métodos de la biblioteca de clases, cree una referencia de proyecto al proyecto de biblioteca de
clases.
1. Ejecute el siguiente comando:

dotnet add ShowCase/ShowCase.csproj reference StringLibrary/StringLibrary.csproj

La salida del terminal se parece al ejemplo siguiente:

 Reference `..\StringLibrary\StringLibrary.csproj` added to the project.

Ejecutar la aplicación
1. Ejecute el siguiente comando en el terminal:

dotnet run --project ShowCase/ShowCase.csproj

2. Para probar el programa, escriba cadenas y presione Entrar y, después, presione Entrar para salir.
La salida del terminal se parece al ejemplo siguiente:

Press <Enter> only to exit; otherwise, enter a string and press <Enter>:

A string that starts with an uppercase letter

Input: A string that starts with an uppercase letter
Begins with uppercase? : Yes

a string that starts with a lowercase letter

Input: a string that starts with a lowercase letter
Begins with uppercase? : No

Recursos adicionales
Desarrollo de bibliotecas con la CLI de .NET
Versiones de .NET Standard y las plataformas que admiten.

Pasos siguientes
En este tutorial, ha creado una solución, ha agregado un proyecto de biblioteca y ha agregado un proyecto de
aplicación de consola que usa la biblioteca. En el siguiente tutorial, agregará un proyecto de prueba unitaria a la
solución.
Prueba de una biblioteca de clases de .NET con .NET mediante Visual Studio Code
 Tutorial: Prueba de una biblioteca de clases de .NET
con Visual Studio Code
18/12/2020 • 13 minutes to read • Edit Online

En este tutorial se muestra cómo automatizar las pruebas unitarias mediante la adición de un proyecto de prueba a
una solución.

Requisitos previos
Este tutorial funciona con la solución que se crea en Creación de una biblioteca de clases de .NET con
Visual Studio Code.

Crear un proyecto de prueba unitaria

Las pruebas unitarias proporcionan pruebas de software automatizadas durante el desarrollo y la publicación. El
marco de trabajo de pruebas que se usa en este tutorial es MSTest. MSTest es uno de los tres marcos de pruebas
que puede elegir. Los otros son xUnit y nUnit.
1. Inicie Visual Studio Code.
2. Abra la solución ClassLibraryProjects que ha creado en Creación de una biblioteca de clases de .NET con
Visual Studio Code.
3. Cree un proyecto de prueba unitaria denominado "StringLibraryTest".

dotnet new mstest -o StringLibraryTest

La plantilla de proyecto crea un archivo UnitTest1.cs con el código siguiente:

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace StringLibraryTest
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
}
}
}

El código fuente creado por la plantilla de prueba unitaria hace lo siguiente:

Importa el espacio de nombres de Microsoft.VisualStudio.TestTools.UnitTesting, que contiene los tipos
utilizados para las pruebas unitarias.
Aplica el atributo TestClassAttribute a la clase UnitTest1 .
Aplica el atributo TestMethodAttribute para definir TestMethod1 .
Cada método etiquetado con [TestMethod] en una clase de prueba etiquetada con [TestClass] se ejecuta
automáticamente cuando se ejecuta la prueba unitaria.
4. Agregue el proyecto de prueba a la solución:

dotnet sln add StringLibraryTest/StringLibraryTest.csproj

Agregar una referencia de proyecto

Para que el proyecto de prueba funcione con la clase StringLibrary , agregue una referencia del proyecto
StringLibraryTest al proyecto StringLibrary .

1. Ejecute el siguiente comando:

dotnet add StringLibraryTest/StringLibraryTest.csproj reference StringLibrary/StringLibrary.csproj

Adición y ejecución de métodos de prueba unitaria

Cuando Visual Studio ejecuta una prueba unitaria, ejecuta cada método marcado con el atributo
TestMethodAttribute en una clase que está marcada con el atributo TestClassAttribute. Un método de prueba
finaliza cuando se encuentra el primer error, o cuando todas las pruebas contenidas en el método se han realizado
correctamente.
Las pruebas más comunes llaman a los miembros de la clase Assert. Muchos métodos de aserción incluyen al
menos dos parámetros, uno de los cuales es el resultado esperado de la prueba y el otro es el resultado real de la
prueba. Algunos de los métodos Assert a los que se llama con más frecuencia se muestran en la tabla siguiente:

M ÉTO DO S DE A SERC IÓ N F UN C IÓ N

Assert.AreEqual Comprueba que dos valores u objetos son iguales. La aserción

da error si los valores o los objetos no son iguales.

Assert.AreSame Comprueba que dos variables de objeto hacen referencia al

mismo objeto. La aserción da error si las variables hacen
referencia a objetos diferentes.

Assert.IsFalse Comprueba si una condición es false . La aserción produce

un error si la condición es true .

Assert.IsNotNull Comprueba que un objeto no es null . La aserción da error

si el objeto es null .

También puede usar el método Assert.ThrowsException en un método de prueba para indicar el tipo de excepción
que se espera que produzca. La prueba dará error si no se inicia la excepción especificada.
Al probar el método StringLibrary.StartsWithUpper , quiere proporcionar un número de cadenas que comiencen
con un carácter en mayúsculas. Espera que el método devuelva true en estos casos, por lo que puede llamar al
método Assert.IsTrue. Del mismo modo, quiere proporcionar un número de cadenas que comiencen con algo que
no sea un carácter en mayúsculas. Espera que el método devuelva false en estos casos, por lo que puede llamar
al método Assert.IsFalse.
Dado que el método de biblioteca controla cadenas, también se recomienda asegurarse de que controla
correctamente una cadena vacía ( String.Empty ) y una cadena null . Una cadena vacía es aquella que no tiene
ningún carácter y cuyo valor de Length es 0. Una cadena null es aquella que no se ha inicializado. Se puede
llamar a StartsWithUpper directamente como un método estático y pasar un argumento String único. También
puede llamar a StartsWithUpper como método de extensión en una variable de string asignada a null .
Definirá tres métodos, cada uno de los cuales llama a un método Assert para cada elemento de una matriz de
cadenas. Llamará a una sobrecarga de método que le permite especificar que se muestre un mensaje de error en
caso de error en la prueba. El mensaje identifica la cadena que causó el error.
Para crear los métodos de prueba:
1. Abra StringLibraryTest/UnitTest1.cs y reemplace todo el código por el siguiente.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using UtilityLibraries;

namespace StringLibraryTest
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestStartsWithUpper()
{
// Tests that we expect to return true.
string[] words = { "Alphabet", "Zebra", "ABC", "Αθήνα", "Москва" };
foreach (var word in words)
{
bool result = word.StartsWithUpper();
Assert.IsTrue(result,
String.Format("Expected for '{0}': true; Actual: {1}",
word, result));
}
}

[TestMethod]
public void TestDoesNotStartWithUpper()
{
// Tests that we expect to return false.
string[] words = { "alphabet", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",
"1234", ".", ";", " " };
foreach (var word in words)
{
bool result = word.StartsWithUpper();
Assert.IsFalse(result,
String.Format("Expected for '{0}': false; Actual: {1}",
word, result));
}
}

[TestMethod]
public void DirectCallWithNullOrEmpty()
{
// Tests that we expect to return false.
string[] words = { string.Empty, null };
foreach (var word in words)
{
bool result = StringLibrary.StartsWithUpper(word);
Assert.IsFalse(result,
String.Format("Expected for '{0}': false; Actual: {1}",
word == null ? "<null>" : word, result));
}
}
}
}

La prueba de caracteres en mayúsculas en el método TestStartsWithUpper incluye la letra mayúscula griega

alfa (U + 0391) y la letra mayúscula cirílica EM (U + 041C). La prueba de caracteres en minúsculas en el
método TestDoesNotStartWithUpper incluye la letra griega minúscula alfa (U + 03B1) y la letra cirílica
 minúscula Ghe (U + 0433).
2. Guarde los cambios.
3. Ejecute las pruebas:

dotnet test StringLibraryTest/StringLibraryTest.csproj

en la salida del terminal se indica que se han superado todas las pruebas.

Starting test execution, please wait...

A total of 1 test files matched the specified pattern.

Passed! - Failed: 0, Passed: 3, Skipped: 0, Total: 3, Duration: 3 ms -

StringLibraryTest.dll (net5.0)

Administración de errores de prueba

Si está realizando el desarrollo controlado por pruebas (TDD), escribirá las pruebas, y estas generarán un error
cuando las ejecute por primera vez. Después, agregará un código a la aplicación para que la prueba se realice
correctamente. En este tutorial, ha creado la prueba después de escribir el código de la aplicación que valida, por lo
que no ha podido comprobar si la prueba genera un error. Para asegurarse de que una prueba genera un error
cuando espera que lo haga, agregue un valor no válido a la entrada de prueba.
1. Modifique la matriz words en el método TestDoesNotStartWithUpper para incluir la cadena "Error".

string[] words = { "alphabet", "Error", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",

"1234", ".", ";", " " };

2. Ejecute las pruebas:

dotnet test StringLibraryTest/StringLibraryTest.csproj

en la salida del terminal se indica que una de las pruebas no se supera y se proporciona un mensaje de
error al respecto: "Error de Assert.IsFalse. Se esperaba para "Error": false; real: True". Debido al error, no se
probaron todas las cadenas de la matriz después de "Error".

Starting test execution, please wait...

A total of 1 test files matched the specified pattern.
Failed TestDoesNotStartWithUpper [28 ms]
Error Message:
Assert.IsFalse failed. Expected for 'Error': false; Actual: True
Stack Trace:
at StringLibraryTest.UnitTest1.TestDoesNotStartWithUpper() in
C:\ClassLibraryProjects\StringLibraryTest\UnitTest1.cs:line 33

Failed! - Failed: 1, Passed: 2, Skipped: 0, Total: 3, Duration: 31 ms -

StringLibraryTest.dll (net5.0)

3. Quite la cadena "Error" que agregó en el paso 1. Vuelva a ejecutar la prueba y se superarán las pruebas.

Prueba de la versión de la biblioteca

Ahora que se han superado todas las pruebas al ejecutar la versión de depuración de la biblioteca, ejecute las
pruebas una vez más con la versión de lanzamiento de la biblioteca. Varios factores, como las optimizaciones del
compilador, a veces pueden producir un comportamiento diferente entre las compilaciones de depuración y
versión.
1. Ejecute las pruebas con la configuración de compilación Versión:

dotnet test StringLibraryTest/StringLibraryTest.csproj --configuration Release

Las pruebas se superan.

Depuración de pruebas
Si usa Visual Studio Code como IDE, puede utilizar el mismo proceso que se muestra en Tutorial: Depuración de
una aplicación de consola de .NET con Visual Studio Code para depurar código mediante el proyecto de prueba
unitaria. En lugar de iniciar el proyecto de aplicación Showcase, abra StringLibraryTest/UnitTest1.cs y seleccione
Ejecutar todas las pruebas entre las líneas 7 y 8. Si no puede encontrarlo, presione Ctrl+Mayús+P para abrir
la paleta de comandos y escriba Recargar ventana .
Visual Studio Code inicia el proyecto de prueba con el depurador asociado. La ejecución se detendrá en cualquier
punto de interrupción que haya agregado al proyecto de prueba o al código de la biblioteca subyacente.

Recursos adicionales
Pruebas unitarias en .NET

Pasos siguientes
En este tutorial, ha realizado una prueba unitaria de una biblioteca de clases. Puede poner la biblioteca a
disposición de otros usuarios si la publica en NuGet como un paquete. Para obtener información sobre cómo
hacerlo, realice este tutorial de NuGet:
Creación y publicación de un paquete con la CLI de dotnet
Si publica una biblioteca como un paquete NuGet, otros usuarios pueden instalarla y usarla. Para obtener
información sobre cómo hacerlo, realice este tutorial de NuGet:
Instalar y usar un paquete con la CLI de dotnet
No es necesario distribuir una biblioteca como un paquete. Se puede agrupar con una aplicación de consola que la
use. Para aprender a publicar una aplicación de consola, vea el tutorial anterior de esta serie:
Publicación de una aplicación de consola de .NET con Visual Studio Code
 Tutorial: Creación de una aplicación de consola de
.NET con Visual Studio para Mac
18/12/2020 • 6 minutes to read • Edit Online

En este tutorial se muestra cómo crear y ejecutar una aplicación de consola de .NET en Visual Studio para Mac.

NOTE
Sus comentarios son muy importantes. Hay dos maneras de proporcionar comentarios al equipo de desarrollo de Visual
Studio para Mac:
En Visual Studio para Mac, seleccione Ayuda > Notificar un problema en el menú o Notificar un problema desde
la pantalla de bienvenida, que abre una ventana para presentar un informe de errores. Puede realizar un seguimiento
de sus comentarios en el portal de la Comunidad de desarrolladores.
Para hacer una sugerencia, seleccione Ayuda > Apor tar una sugerencia en el menú o Apor tar una sugerencia
desde la pantalla de bienvenida, que le lleva a la página web de la Comunidad de desarrolladores de Visual Studio para
Mac.

Requisitos previos
Visual Studio para Mac, versión 8.8 o posterior Seleccione la opción para instalar .NET Core. La instalación
de Xamarin es opcional para el desarrollo con .NET. Para obtener más información, vea los siguientes
recursos:
Tutorial: Instalación de Visual Studio para Mac.
Versiones de macOS compatibles.
Versiones de .NET compatibles con Visual Studio para Mac.

Creación de la aplicación
1. Inicie Visual Studio para Mac:
2. Seleccione Nuevo en la ventana de inicio.

3. En el cuadro de diálogo Nuevo proyecto , seleccione Aplicación en el nodo Web and Console (Web y
consola). Seleccione la plantilla Aplicación de consola y haga clic en Siguiente .
4. En la lista desplegable Plataforma de destino del cuadro de diálogo para Configure your new
Console Application (Configurar una nueva aplicación de consola), seleccione .NET 5.0 y elija
Siguiente .
5. Escriba "HelloWorld" en Nombre del proyecto y seleccione Crear .

La plantilla crea una aplicación "Hola mundo" sencilla. Llama al método Console.WriteLine(String) para mostrar
"Hola mundo" en la ventana de terminal.
El código de plantilla define una clase, Program , con un único método, Main , que toma una matriz de String
como argumento:
 using System;

namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

Main es el punto de entrada de la aplicación, el método que se llama automáticamente mediante el tiempo de
ejecución cuando inicia la aplicación. Los argumentos de línea de comandos proporcionados cuando se inicia la
aplicación están disponibles en la matriz args .

Ejecutar la aplicación
1. Presione ⌘↵ (opción+command+entrar) para ejecutar la aplicación sin depuración.
2. Cierre la ventana de Terminal .

Mejora de la aplicación
Mejore la aplicación para pedir su nombre al usuario y mostrarlo con la fecha y la hora.
1. En Program.cs, reemplace el contenido del método Main , que es la línea que llama a Console.WriteLine ,
por el código siguiente:

Console.WriteLine("\nWhat is your name? ");

var name = Console.ReadLine();
var date = DateTime.Now;
Console.WriteLine($"\nHello, {name}, on {date:d} at {date:t}!");
Console.Write("\nPress any key to exit...");
Console.ReadKey(true);

Este código muestra un mensaje en la ventana de la consola y espera a que el usuario escriba una cadena
y, luego, presione Entrar. Almacena esta cadena en una variable denominada name . También recupera el
valor de la propiedad DateTime.Now, que contiene la hora local actual, y lo asigna a una variable
denominada date . Asimismo, muestra estos valores en la ventana de la consola. Por último, muestra un
mensaje en la ventana de la consola y llama al método Console.ReadKey(Boolean) para esperar a la
entrada del usuario.
El símbolo \n representa un carácter de nueva línea.
El signo de dólar ( $ ) delante de una cadena permite colocar expresiones como nombres de variable entre
llaves en la cadena. El valor de la expresión se inserta en la cadena en lugar de la expresión. Esta sintaxis se
conoce como cadenas interpoladas.
2. Presione ⌘↵ (opción+command+entrar) para ejecutar la aplicación.

3. Responda a la solicitud escribiendo un nombre y presionando la tecla entrar.

4. Cierre el terminal.

Pasos siguientes
En este tutorial, ha creado una aplicación de consola de .NET. En el siguiente tutorial, depurará la aplicación.
Depuración de una aplicación de consola de .NET con Visual Studio para Mac
 Tutorial: Depuración de una aplicación de consola de
.NET con Visual Studio para Mac
18/12/2020 • 13 minutes to read • Edit Online

En este tutorial se presentan las herramientas de depuración que hay disponibles en Visual Studio para Mac.

Requisitos previos
Este tutorial funciona con la aplicación de consola que se crea en Creación de una aplicación de consola de .NET
con Visual Studio para Mac.

Uso de la configuración de compilación de depuración

Depuración y Versión son las configuraciones de compilación integradas de Visual Studio. Use la configuración de
compilación Depuración para depurar y la configuración de compilación Versión para la distribución final de la
versión.
En la configuración de depuración, el programa se compila sin optimizar y con toda la información de depuración
simbólica. La optimización complica la depuración, ya que la relación entre el código fuente y las instrucciones
generadas es más compleja. La configuración de versión del programa no contiene información de depuración
simbólica y está totalmente optimizada.
De forma predeterminada, Visual Studio para Mac usa la configuración de compilación Depuración, por lo que no
es necesario cambiarla antes de depurar.
1. Inicie Visual Studio para Mac:
2. Abra el proyecto que ha creado en Creación de una aplicación de consola de .NET con Visual Studio para
Mac.
La configuración de compilación actual se muestra en la barra de herramientas. En la siguiente imagen de la
barra de herramientas se muestra que Visual Studio está configurado para compilar la versión de
depuración de la aplicación:

Establecer un punto de interrupción

Un punto de interrupción interrumpe temporalmente la ejecución de la aplicación antes de que se ejecute la línea
con el punto de interrupción.
1. Establezca un punto de interrupción en la línea que muestra el nombre, la fecha y la hora. Para ello, coloque
el cursor en la línea de código y presione ⌘\ (command+\). Otra manera de establecer un punto de
interrupción es seleccionar Ejecutar > Alternar punto de interrupción en el menú.
Para indicar la línea en la que se establece el punto de interrupción, Visual Studio lo resalta y muestra un
punto rojo en el margen izquierdo.
2. Presione ⌘↵ (command+entrar) para iniciar el programa en modo de depuración. Otra manera de iniciar
la depuración es elegir Ejecutar > Iniciar depuración en el menú.
3. Cuando el sistema le pida un nombre, escriba una cadena en la ventana de terminar y luego presione
Entrar.

4. La ejecución del programa se detiene cuando llega al punto de interrupción y antes de que se ejecute el
método Console.WriteLine .

Uso de la ventana Inmediato

La ventana Inmediato le permite interactuar con la aplicación que está depurando. Puede cambiar el valor de las
variables de forma interactiva para ver cómo afecta esto al programa.
1. Si la ventana Inmediato no está visible, muéstrela; para ello, elija Ver > Paneles de depuración >
Inmediato .
2. Escriba name = "Gracie" en la ventana Inmediato y presione Entrar.
3. Escriba date = date.AddDays(1) en la ventana Inmediato y presione Entrar.
La ventana Inmediato muestra el nuevo valor de la variable de cadena y las propiedades del valor
DateTime.
 La ventana Variables locales muestra los valores de las variables definidas en el método que se ejecuta
actualmente. Los valores de las variables que acaba de cambiar se actualizan en la ventana Variables
locales .

4. Presione ⌘↵ (command+entrar) para continuar con la depuración.

Los valores mostrados en el terminar corresponden a los cambios realizados en la ventana Inmediato .
Si no ve el terminal, seleccione Terminal - HelloWorld en la barra de navegación inferior.

5. Presione cualquier tecla para salir de la aplicación.

6. Cierre ventana de terminal.

Establecimiento de un punto de interrupción condicional

El programa muestra la cadena que escribe el usuario. ¿Qué sucede si el usuario no escribe nada? Puede probarlo
con una característica de depuración muy útil denominada Punto de interrupción condicional.
1. Haga clic pulsando control en el punto rojo que representa al punto de interrupción. En el menú
contextual, seleccione Editar punto de interrupción .
2. En el cuadro de diálogo Editar punto de interrupción , escriba el código siguiente en el campo Y se
cumpla la siguiente condición y seleccione Aplicar .

String.IsNullOrEmpty(name)
 Cada vez que se alcanza el punto de interrupción, el depurador llama al método
String.IsNullOrEmpty(name) y se interrumpe en esta línea solo si la llamada al método devuelve true .
En lugar de una expresión condicional, puede especificar un número de llamadas, que interrumpe la
ejecución del programa antes de que una instrucción se ejecute un número especificado de veces.
3. Presione ⌘↵ (command+entrar) para iniciar la depuración.
4. En la ventana de terminal, presione entrar cuando se le pida que escriba su nombre.
Como se ha cumplido la condición que especificó ( name es null o String.Empty), la ejecución del
programa se detiene cuando se alcanza el punto de interrupción.
5. Seleccione la ventana Variables locales , que muestra los valores de las variables que son locales para el
método que se ejecuta actualmente. En este caso, Main es el método que se está ejecutando actualmente.
Observe que el valor de la variable name es "" ; esto es, String.Empty.
6. También puede ver que el valor es una cadena vacía escribiendo el nombre de la variable name en la
ventana Inmediato y presionando entrar.
 7. Presione ⌘↵ (command+entrar) para continuar con la depuración.
8. En la ventana de terminal, presione cualquier tecla para salir del programa.
9. Cierre la ventana de terminal.
10. Para borrar el punto de interrupción, haga clic en el punto rojo en el margen izquierdo de la ventana de
código. Otra manera de hacerlo es elegir Ejecutar > Alternar punto de interrupción con la línea de
código seleccionada.

Ejecución paso a paso de un programa

Visual Studio también le permite recorrer línea a línea un programa y supervisar su ejecución. Normalmente,
establecería un punto de interrupción y seguiría el flujo del programa mediante una pequeña parte de su código
de programa. Como este programa es pequeño, puede ejecutar paso a paso el programa entero.
1. Establezca un punto de interrupción en la llave que marca el inicio del método Main (presione
command+\).

2. Presione ⌘↵ (command+entrar) para iniciar la depuración.

Visual Studio se detiene en la línea con el punto de interrupción.
3. Presione ⇧⌘I (mayús+command+l) o seleccione Ejecutar > Depurar paso a paso por instrucciones
para avanzar una línea.
Visual Studio resalta y muestra una flecha junto a la siguiente línea de ejecución.
 En este punto, la ventana Variables locales muestra que la matriz args está vacía, y name y date tienen
valores predeterminados. Además, Visual Studio ha abierto una ventana de consola en blanco.
4. Presione ⇧⌘I (mayús+command+I).
Visual Studio resalta la instrucción que incluye la asignación de variables name . La ventana Variables
locales muestra que name es null , y terminal muestra la cadena "What is your name?" (¿Cómo te
llamas?).
5. Para responder a la solicitud, escriba una cadena en la ventana de consola y presione entrar.
6. Presione ⇧⌘I (mayús+command+I).
Visual Studio resalta la instrucción que incluye la asignación de variables date . La ventana Variables
locales muestra el valor devuelto por la llamada al método Console.ReadLine. En el terminal se muestra la
cadena que escribió en el símbolo del sistema.
7. Presione ⇧⌘I (mayús+command+I).
La ventana Variables locales muestra el valor de la variable date tras la asignación desde la propiedad
DateTime.Now. El terminal no se modifica.
8. Presione ⇧⌘I (mayús+command+I).
Visual Studio llama al método Console.WriteLine(String, Object, Object). El terminal muestra la cadena con
formato.
9. Presione ⇧⌘U (mayús+command+U) o seleccione Ejecutar > Paso a paso para salir .
El terminal muestra un mensaje y espera a que presione una tecla.
10. Presione cualquier tecla para salir de la aplicación.

Uso de la configuración de compilación de versión

Una vez que ha probado la versión de depuración de la aplicación, también debe compilar y probar la versión de
lanzamiento. La versión de lanzamiento incorpora optimizaciones del compilador que afectan negativamente al
comportamiento de una aplicación. Por ejemplo, las optimizaciones del compilador que están diseñadas para
mejorar el rendimiento pueden crear condiciones de carrera en aplicaciones multiproceso.
Para compilar y probar la configuración de versión de la aplicación de consola, realice los pasos siguientes:
1. Cambie la configuración de compilación en la barra de herramientas de Depurar a Versión .
2. Presione ⌘↵ (opción+command+entrar) para ejecutar sin depurar.

Pasos siguientes
En este tutorial, ha usado las herramientas de depuración de Visual Studio. En el siguiente tutorial, publicará una
versión de la aplicación que se puede implementar.
Publicación de una aplicación de consola de .NET con Visual Studio para Mac
 Tutorial: Publicación de una aplicación de consola de
.NET con Visual Studio para Mac
18/12/2020 • 4 minutes to read • Edit Online

En este tutorial se muestra cómo publicar una aplicación de consola para que otros usuarios puedan ejecutarla. La
publicación crea el conjunto de archivos que se necesitan para ejecutar la aplicación. Para implementar los
archivos, cópielos en el equipo de destino.

Requisitos previos
Este tutorial funciona con la aplicación de consola que se crea en Creación de una aplicación de consola de .NET
con Visual Studio para Mac.

Publicar la aplicación
1. Inicie Visual Studio para Mac:
2. Abra el proyecto HelloWorld que creó en Creación de una aplicación de consola de .NET con Visual Studio
para Mac.
3. Asegúrese de que Visual Studio esté compilando la versión de lanzamiento de la aplicación. Si es necesario,
cambie la configuración de compilación en la barra de herramientas de Depurar a Versión .

4. En el menú principal, elija Compilación > Publicar en carpeta... .

5. En el cuadro de diálogo Publicar en carpeta , seleccione Publicar .

 Se abre la carpeta de publicación, que muestra los archivos que se crearon.

6. Seleccione el icono de engranaje y elija Copy "publish" as Pathname (Copiar "publicar" como nombre de
ruta) en el menú contextual.
Inspección de los archivos
El proceso de publicación crea una implementación dependiente del marco, que es un tipo de implementación
donde la aplicación publicada se ejecuta en cualquier máquina que tenga instalado el entorno de ejecución de .NET.
Los usuarios pueden ejecutar la aplicación publicada mediante la ejecución del comando dotnet HelloWorld.dll
desde un símbolo del sistema.
Como se muestra en la imagen anterior, la salida publicada incluye los siguientes archivos:
HelloWorld.deps.json
Este es el archivo de dependencias en tiempo de ejecución de la aplicación. Define los componentes y las
bibliotecas de .NET (incluida la biblioteca de vínculos dinámicos que contiene la aplicación) necesarios para
ejecutar la aplicación. Para obtener más información, consulte Archivos de configuración en tiempo de
ejecución.
HelloWorld.dll
Esta es la versión de implementación dependiente del marco de la aplicación. Para ejecutar esta biblioteca
de vínculos dinámicos, escriba dotnet HelloWorld.dll en un símbolo del sistema. Este método de ejecución
de la aplicación funciona en cualquier plataforma que tenga instalado el entorno de ejecución de .NET.
HelloWorld.pdb (opcional para la implementación)
Este es el archivo de símbolos de depuración. No necesita implementar este archivo junto con su aplicación,
aunque se debe guardar en caso de que necesite depurar la versión publicada de la aplicación.
HelloWorld.runtimeconfig.json
Este es el archivo de configuración en tiempo de ejecución de la aplicación. Identifica la versión de .NET en la
que se ha compilado la aplicación para ejecutarse. También puede agregarle opciones de configuración. Para
obtener más información, vea Opciones de configuración en tiempo de ejecución de .NET Core.

Ejecutar la aplicación publicada

1. Abra un terminal y vaya a la carpeta publish. Para ello, escriba cd y, luego, pegue la ruta de acceso que
copió anteriormente. Por ejemplo:

cd ~/Projects/HelloWorld/HelloWorld/bin/Release/net5.0/publish/

2. Ejecute la aplicación mediante el comando dotnet :

a. Escriba dotnet HelloWorld.dll y presione Entrar.
b. Escriba un nombre cuando se le pida y presione cualquier tecla para salir.

Recursos adicionales
implementación de aplicaciones .NET

Pasos siguientes
En este tutorial, ha publicado una aplicación de consola. En el siguiente tutorial, creará una biblioteca de clases.
Creación de una biblioteca .NET mediante Visual Studio para Mac
 Tutorial: Creación de una biblioteca de clases de
.NET con Visual Studio para Mac
18/12/2020 • 9 minutes to read • Edit Online

En este tutorial, creará una biblioteca de clases que contiene un único método de control de cadenas.
Una biblioteca de clases define los tipos y los métodos que se llaman desde una aplicación. Si la biblioteca tiene
como destino .NET Standard 2.0, se puede llamar mediante cualquier implementación de .NET (incluido
.NET Framework) que admita .NET Standard 2.0. Si la biblioteca tiene como destino .NET 5, la puede llamar
cualquier aplicación que tenga como destino .NET 5. En este tutorial se muestra cómo seleccionar .NET 5 como
destino.

NOTE
Sus comentarios son muy importantes. Hay dos maneras de proporcionar comentarios al equipo de desarrollo de Visual
Studio para Mac:
En Visual Studio para Mac, seleccione Ayuda > Notificar un problema en el menú o Notificar un problema desde
la pantalla de bienvenida, que abre una ventana para presentar un informe de errores. Puede realizar un seguimiento de
sus comentarios en el portal de la Comunidad de desarrolladores.
Para hacer una sugerencia, seleccione Ayuda > Apor tar una sugerencia en el menú o Apor tar una sugerencia
desde la pantalla de bienvenida, que le lleva a la página web de la Comunidad de desarrolladores de Visual Studio para
Mac.

Requisitos previos
Instale Visual Studio para Mac, versión 8.8 o posterior. Seleccione la opción para instalar .NET Core. La
instalación de Xamarin es opcional para el desarrollo con .NET. Para obtener más información, vea los
siguientes recursos:
Tutorial: Instalación de Visual Studio para Mac.
Versiones de macOS compatibles.
Versiones de .NET compatibles con Visual Studio para Mac.

Creación de una solución con un proyecto de biblioteca de clases

Una solución de Visual Studio sirve como contenedor de uno o varios proyectos. Creación de una solución y un
proyecto de biblioteca de clases en la solución. Agregará otros proyectos relacionados a la misma solución más
adelante.
1. Inicie Visual Studio para Mac:
2. En la ventana de inicio, seleccione Nuevo proyecto .
3. En el cuadro de diálogo Elija una plantilla para el nuevo proyecto , seleccione Web and Console
(Web y consola) > Biblioteca > Biblioteca de clases y, luego, elija Siguiente .
4. En el cuadro de diálogo Configure your new Class Librar y (Configurar una nueva biblioteca de clases),
elija .NET 5.0 y, luego, Siguiente .
5. Asigne al proyecto el nombre "StringLibrary" y a la solución "ClassLibraryProjects". Deje activada la opción
Crear un directorio de proyecto dentro del directorio de la solución . Seleccione Crear .

6. En el menú principal, seleccione Ver > Solución y elija el icono de acoplamiento para mantener el panel
abierto.
 7. En el panel Solución , expanda el nodo StringLibrary para mostrar el archivo de clase proporcionado por
la plantilla Class1.cs. Haga clic presionando control en el archivo, seleccione Cambiar nombre en el
menú contextual y denomínelo StringLibrary.cs. Abra el archivo y reemplace el contenido por el código
siguiente:

using System;

namespace UtilityLibraries
{
public static class StringLibrary
{
public static bool StartsWithUpper(this string str)
{
if (string.IsNullOrWhiteSpace(str))
return false;

char ch = str[0];
return char.IsUpper(ch);
}
}
}

8. Presione ⌘S (command+S) para guardar el archivo.

9. Seleccione Errores en el margen inferior de la ventana de IDE para abrir el panel Errores . Seleccione el
botón Salida de la compilación .

10. Seleccione Compilar > Compilar todo en el menú.

La solución se compila. El panel de salida de la compilación muestra que la compilación es correcta.

Incorporación de una aplicación de consola a la solución

Agregue una aplicación de consola que use la biblioteca de clases. La aplicación solicitará al usuario que escriba
una cadena y notificará si la cadena comienza con un carácter en mayúsculas.
1. En el panel Solución , haga clic pulsando control en la solución ClassLibraryProjects . Agregue un nuevo
proyecto de aplicación de consola ; para ello, seleccione la plantilla de las plantillas de Web and
 Console (Web y consola) > Aplicación y seleccione Siguiente .
2. Seleccione .NET 5.0 como Marco de destino y, a continuación, elija Siguiente .
3. Asigne al proyecto el nombre ShowCase . Seleccione Crear para crear el proyecto en la solución.

4. Abra el archivo Program.cs. Reemplace el código por el siguiente código:

 using System;
using UtilityLibraries;

class Program
{
static void Main(string[] args)
{
int row = 0;

do
{
if (row == 0 || row >= 25)
ResetConsole();

string input = Console.ReadLine();

if (string.IsNullOrEmpty(input)) break;
Console.WriteLine($"Input: {input} {"Begins with uppercase? ",30}: " +
$"{(input.StartsWithUpper() ? "Yes" : "No")}\n");
row += 3;
} while (true);
return;

// Declare a ResetConsole local method

void ResetConsole()
{
if (row > 0)
{
Console.WriteLine("Press any key to continue...");
Console.ReadKey();
}
Console.Clear();
Console.WriteLine("\nPress <Enter> only to exit; otherwise, enter a string and press
<Enter>:\n");
row = 3;
}
}
}

El programa le pide al usuario que escriba una cadena. Indica si la cadena comienza con un carácter en
mayúsculas. Si el usuario presiona la tecla Entrar sin especificar una cadena, la aplicación finaliza y la
ventana de la consola se cierra.
El código usa la variable row para mantener un recuento del número de filas de datos escritas en la
ventana de consola. Siempre que sea mayor o igual a 25, el código borra la ventana de consola y muestra
un mensaje al usuario.

Agregar una referencia de proyecto

En un principio, el nuevo proyecto de aplicación de consola no tiene acceso a la biblioteca de clases. Para que
pueda llamar a los métodos de la biblioteca de clases, cree una referencia de proyecto al proyecto de biblioteca de
clases.
1. En el panel Soluciones , haga clic presionando control en el nodo Dependencias del nuevo proyecto
ShowCase . En el menú contextual, seleccione Agregar referencia .
2. En el cuadro de diálogo Referencias , seleccione StringLibrar y y Aceptar .

Ejecutar la aplicación
1. Haga clic y presione la tecla Ctrl en el proyecto ShowCase y seleccione Ejecutar el proyecto en el
menú contextual.
2. Para probar el programa, escriba cadenas y presione Entrar y, después, presione Entrar para salir.

Recursos adicionales
Desarrollo de bibliotecas con la CLI de .NET
Notas de la versión de Visual Studio 2019 para Mac
Versiones de .NET Standard y las plataformas que admiten.

Pasos siguientes
En este tutorial, ha creado una solución, ha agregado un proyecto de biblioteca y ha agregado un proyecto de
aplicación de consola que usa la biblioteca. En el siguiente tutorial, agregará un proyecto de prueba unitaria a la
solución.
Prueba de una biblioteca de clases de .NET con Visual Studio para Mac
 Prueba de una biblioteca de clases de .NET con
Visual Studio
18/12/2020 • 15 minutes to read • Edit Online

En este tutorial se muestra cómo automatizar las pruebas unitarias mediante la adición de un proyecto de prueba a
una solución.

Requisitos previos
Este tutorial funciona con la solución que se crea en Creación de una biblioteca de clases de .NET con
Visual Studio para Mac.

Crear un proyecto de prueba unitaria

Las pruebas unitarias proporcionan pruebas de software automatizadas durante el desarrollo y la publicación.
MSTest es uno de los tres marcos de pruebas que puede elegir. Los otros son xUnit y nUnit.
1. Inicie Visual Studio para Mac:
2. Abra la solución ClassLibraryProjects que ha creado en Creación de una biblioteca de clases de .NET con
Visual Studio para Mac.
3. En el panel Solución , presione Ctrl, haga clic en la solución ClassLibraryProjects y seleccione Agregar >
Nuevo proyecto .
4. En el cuadro de diálogo Nuevo proyecto , seleccione Pruebas en el nodo Web and Console (Web y
consola). Seleccione el proyecto MSTest y, luego, Siguiente .
5. Seleccione .NET 5.0 como Marco de destino y, a continuación, elija Siguiente .
6. Asigne al nuevo proyecto el nombre "StringLibraryTest" y seleccione Crear .

Visual Studio crea un archivo de clase con el código siguiente:

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace StringLibraryTest
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
}
}
}

El código fuente creado por la plantilla de prueba unitaria hace lo siguiente:

Importa el espacio de nombres de Microsoft.VisualStudio.TestTools.UnitTesting, que contiene los tipos
utilizados para las pruebas unitarias.
Aplica el atributo TestClassAttribute a la clase UnitTest1 .
Aplica el atributo TestMethodAttribute a TestMethod1 .
Cada método etiquetado con [TestMethod] en una clase de prueba etiquetada con [TestClass] se ejecuta
automáticamente cuando se ejecuta la prueba unitaria.

Agregar una referencia de proyecto

Para que el proyecto de prueba funcione con la clase StringLibrary , agregue una referencia al proyecto
StringLibrary .
1. En el panel Solución , presione Ctrl y haga clic en Dependencias en StringLibrar yTest . Seleccione
Agregar referencia en el menú contextual.
2. En el cuadro de diálogo Referencias , seleccione el proyecto StringLibrar y . Seleccione Aceptar .

Adición y ejecución de métodos de prueba unitaria

Cuando Visual Studio ejecuta una prueba unitaria, ejecuta cada método marcado con el atributo
TestMethodAttribute en una clase que está marcada con el atributo TestClassAttribute. Un método de prueba
finaliza cuando se encuentra el primer error, o cuando todas las pruebas contenidas en el método se han realizado
correctamente.
Las pruebas más comunes llaman a los miembros de la clase Assert. Muchos métodos de aserción incluyen al
menos dos parámetros, uno de los cuales es el resultado esperado de la prueba y el otro es el resultado real de la
prueba. Algunos de los métodos Assert a los que se llama con más frecuencia se muestran en la tabla siguiente:

M ÉTO DO S DE A SERC IÓ N F UN C IÓ N

Assert.AreEqual Comprueba que dos valores u objetos son iguales. La aserción

da error si los valores o los objetos no son iguales.

Assert.AreSame Comprueba que dos variables de objeto hacen referencia al

mismo objeto. La aserción da error si las variables hacen
referencia a objetos diferentes.

Assert.IsFalse Comprueba si una condición es false . La aserción produce

un error si la condición es true .

Assert.IsNotNull Comprueba que un objeto no es null . La aserción da error

si el objeto es null .

También puede usar el método Assert.ThrowsException en un método de prueba para indicar el tipo de excepción
que se espera que produzca. La prueba dará error si no se inicia la excepción especificada.
Al probar el método StringLibrary.StartsWithUpper , quiere proporcionar un número de cadenas que comiencen
con un carácter en mayúsculas. Espera que el método devuelva true en estos casos, por lo que puede llamar al
método Assert.IsTrue. Del mismo modo, quiere proporcionar un número de cadenas que comiencen con algo que
no sea un carácter en mayúsculas. Espera que el método devuelva false en estos casos, por lo que puede llamar
al método Assert.IsFalse.
Dado que el método de biblioteca administra cadenas, quiere asegurarse también de que administra
correctamente una cadena vacía ( String.Empty ), una cadena válida que no tenga caracteres y cuyo Length sea 0, y
una cadena null que no se haya inicializado. Se puede llamar a StartsWithUpper directamente como un método
estático y pasar un argumento String único. También puede llamar a StartsWithUpper como método de extensión
en una variable de string asignada a null .
Definirá tres métodos, cada uno de los cuales llama a un método Assert para cada elemento de una matriz de
cadenas. Llamará a una sobrecarga de método que le permite especificar que se muestre un mensaje de error en
caso de error en la prueba. El mensaje identifica la cadena que causó el error.
Para crear los métodos de prueba:
1. Abra el archivo UnitTest1.cs y reemplace el código por el siguiente:
 using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using UtilityLibraries;

namespace StringLibraryTest
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestStartsWithUpper()
{
// Tests that we expect to return true.
string[] words = { "Alphabet", "Zebra", "ABC", "Αθήνα", "Москва" };
foreach (var word in words)
{
bool result = word.StartsWithUpper();
Assert.IsTrue(result,
String.Format("Expected for '{0}': true; Actual: {1}",
word, result));
}
}

[TestMethod]
public void TestDoesNotStartWithUpper()
{
// Tests that we expect to return false.
string[] words = { "alphabet", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",
"1234", ".", ";", " " };
foreach (var word in words)
{
bool result = word.StartsWithUpper();
Assert.IsFalse(result,
String.Format("Expected for '{0}': false; Actual: {1}",
word, result));
}
}

[TestMethod]
public void DirectCallWithNullOrEmpty()
{
// Tests that we expect to return false.
string[] words = { string.Empty, null };
foreach (var word in words)
{
bool result = StringLibrary.StartsWithUpper(word);
Assert.IsFalse(result,
String.Format("Expected for '{0}': false; Actual: {1}",
word == null ? "<null>" : word, result));
}
}
}
}

La prueba de caracteres en mayúsculas en el método TestStartsWithUpper incluye la letra mayúscula griega

alfa (U + 0391) y la letra mayúscula cirílica EM (U + 041C). La prueba de caracteres en minúsculas en el
método TestDoesNotStartWithUpper incluye la letra griega minúscula alfa (U + 03B1) y la letra cirílica
minúscula Ghe (U + 0433).
2. En la barra de menús, seleccione Archivo > Guardar como . En el cuadro de diálogo, asegúrese de que
Codificación esté establecida en Unicode (UTF-8) .
3. Cuando se le pregunte si quiere reemplazar el archivo existente, seleccione Reemplazar .
Si obtiene un error al guardar el código fuente en un archivo con codificación UTF-8, Visual Studio puede
guardarlo como un archivo ASCII. Cuando eso suceda, el tiempo de ejecución no descodifica correctamente
los caracteres UTF-8 del rango ASCII, y los resultados de la prueba no serán correctos.
4. Abra el panel Pruebas unitarias en el lado derecho de la pantalla. En el menú, seleccione Ver > Pruebas .
5. Haga clic en el icono Acoplar para mantener abierto el panel.

6. Haga clic en el botón Ejecutar todas .

Todas las pruebas se superan.

Administración de errores de prueba

Si está realizando el desarrollo controlado por pruebas (TDD), escribirá las pruebas, y estas generarán un error
cuando las ejecute por primera vez. Después, agregará un código a la aplicación para que la prueba se realice
correctamente. En este tutorial, ha creado la prueba después de escribir el código de la aplicación que valida, por lo
que no ha podido comprobar si la prueba genera un error. Para asegurarse de que una prueba genera un error
cuando espera que lo haga, agregue un valor no válido a la entrada de prueba.
1. Modifique la matriz words en el método TestDoesNotStartWithUpper para incluir la cadena "Error". No
necesita guardar el archivo porque Visual Studio guarda automáticamente archivos abiertos cuando se crea
una solución para ejecutar pruebas.

string[] words = { "alphabet", "Error", "zebra", "abc", "αυτοκινητοβιομηχανία", "государство",

"1234", ".", ";", " " };

2. Vuelva a ejecutar las pruebas.

Esta vez, en la ventana Explorador de pruebas se indica que dos pruebas se han realizado correctamente
y que una ha finalizado con errores.

3. Presione Ctrl y haga clic en la prueba con errores, TestDoesNotStartWithUpper , y seleccione Mostrar el
panel de resultados en el menú contextual.
El panel Resultados muestra el mensaje generado por la aserción: "Error de Assert.IsFalse. Se esperaba
para "Error": false; real: True". Debido al error, no se probaron todas las cadenas de la matriz después de
"Error".
4. Quite la cadena "Error" que agregó en el paso 1. Vuelva a ejecutar la prueba y se superarán las pruebas.

Prueba de la versión de la biblioteca

Ahora que se han superado todas las pruebas al ejecutar la versión de depuración de la biblioteca, ejecute las
pruebas una vez más con la versión de lanzamiento de la biblioteca. Varios factores, como las optimizaciones del
compilador, a veces pueden producir un comportamiento diferente entre las compilaciones de depuración y
versión.
Para probar la compilación de versión:
1. En la barra de herramientas de Visual Studio, cambie la configuración de compilación de Depurar a
Versión .

2. En el panel Solución , presione Ctrl y haga clic en el proyecto StringLibrar y y seleccione Compilación
en el menú contextual para volver a compilar la biblioteca.
3. Ejecute de nuevo las pruebas unitarias.
Las pruebas se superan.

Depuración de pruebas
Si usa Visual Studio para Mac como IDE, puede emplear el mismo proceso que se muestra en Tutorial: Depuración
de una aplicación de consola de .NET con Visual Studio para Mac para depurar el código mediante el proyecto de
prueba unitaria. En lugar de iniciar el proyecto de aplicación ShowCase, presione Ctrl y haga clic en el proyecto
StringLibrar yTests y seleccione Iniciar depuración del proyecto en el menú contextual.
Visual Studio inicia el proyecto de prueba con el depurador asociado. La ejecución se detendrá en cualquier punto
de interrupción que haya agregado al proyecto de prueba o al código de la biblioteca subyacente.

Recursos adicionales
Pruebas unitarias en .NET

Pasos siguientes
En este tutorial, ha realizado una prueba unitaria de una biblioteca de clases. Puede poner la biblioteca a
disposición de otros usuarios si la publica en NuGet como un paquete. Para obtener información sobre cómo
hacerlo, realice este tutorial de NuGet:
Crear y publicar un paquete (CLI de dotnet)
Si publica una biblioteca como un paquete NuGet, otros usuarios pueden instalarla y usarla. Para obtener
información sobre cómo hacerlo, realice este tutorial de NuGet:
Instalación y uso de un paquete en Visual Studio para Mac
No es necesario distribuir una biblioteca como un paquete. Se puede agrupar con una aplicación de consola que la
use. Para aprender a publicar una aplicación de consola, vea el tutorial anterior de esta serie:
Publicación de una aplicación de consola de .NET con Visual Studio para Mac
 Explore estos tutoriales para obtener información
sobre las herramientas de .NET y el SDK de .NET.
18/12/2020 • 2 minutes to read • Edit Online

En los tutoriales siguientes se muestra cómo desarrollar bibliotecas y aplicaciones de consola para .NET Core y
.NET 5, y versiones posteriores. Para otros tipos de aplicaciones, consulte Tutoriales de introducción a .NET.

Usar Visual Studio

Creación de una aplicación de consola
Depuración de una aplicación
Publicación de una aplicación
Creación de una biblioteca de clases
Prueba unitaria de una biblioteca de clases
Instalación y uso de un paquete
Creación y publicación de un paquete
Creación de una aplicación de consola en F#

Usar Visual Studio Code

Elija estos tutoriales si quiere usar Visual Studio Code u otro editor de código. Todos usan la CLI para tareas de
desarrollo de .NET Core, por lo que, salvo el relativo a la depuración, se pueden utilizar con cualquier editor de
código.
Creación de una aplicación de consola
Depuración de una aplicación
Publicación de una aplicación
Creación de una biblioteca de clases
Prueba unitaria de una biblioteca de clases
Instalación y uso de un paquete
Creación y publicación de un paquete
Creación de una aplicación de consola en F#

Uso de Visual Studio para Mac

Creación de una aplicación de consola
Depuración de una aplicación
Publicación de una aplicación
Creación de una biblioteca de clases
Prueba unitaria de una biblioteca de clases
Instalación y uso de un paquete
Creación de una aplicación de consola en F#

Temas avanzados
Procedimiento para crear bibliotecas
Prueba unitaria de una aplicación con xUnit
Prueba unitaria en C#, VB y F# con NUnit, xUnit o MSTest
Prueba unitaria dinámica con Visual Studio
Creación de plantillas para la CLI
Creación y uso de herramientas para la CLI
Creación de una aplicación con complementos
 Cambios importantes en .NET 5.0
18/12/2020 • 7 minutes to read • Edit Online

Si va a migrar una aplicación a .NET 5.0, es posible que le afecten los cambios importantes que se enumeran aquí.
Los cambios se agrupan por área tecnológica, como ASP.NET Core o criptografía.

ASP.NET Core
Las aplicaciones ASP.NET Core deserializan los números entrecomillados
API de AzureAD.UI y AzureADB2C.UI obsoletas
Los métodos de serialización BinaryFormatter obsoletos están obsoletos
El recurso en el enrutamiento de punto de conexión es HttpContext
los paquetes de integración de Azure con Microsoft como prefijo se han quitado
"Blazor: compatibilidad con exploradores actualizada"
"Blazor: espacio en blanco insignificante recortado por el compilador"
"Blazor: los tipos JSObjectReference y JSInProcessObjectReference son internos"
"Blazor: plataforma de destino de paquetes NuGet cambiada"
"Blazor: migración de la característica ProtectedBrowserStorage a una plataforma compartida"
"Blazor: los campos públicos RenderTreeFrame de solo lectura ahora son propiedades"
"Blazor: lógica de validación actualizada para los recursos web estáticos"
Las API de criptografía no se admiten en el explorador
"Extensiones: cambios de referencia de paquete"
Los tipos BadHttpRequestException de Kestrel e IIS están obsoletos
instancias de HttpClient creadas por códigos de estado enteros del registro de IHttpClientFactory
"HttpSys: deshabilitación predeterminada de la renegociación del certificado de cliente"
"IIS: mantenimiento de las cadenas de consulta de middleware de UrlRewrite"
"Kestrel: cambios de configuración detectados de forma predeterminada"
"Kestrel: versiones del protocolo TLS admitidas de forma predeterminada cambiadas"
"Kestrel: deshabilitación de HTTP/2 sobre TLS en versiones de Windows incompatibles"
"Kestrel: transporte de libuv marcado como obsoleto"
Propiedades obsoletas en ConsoleLoggerOptions
se han eliminado la clase ResourceManagerWithCultureStringLocalizer y el miembro de interfaz WithCulture
API Pubternal quitadas
Se ha quitado el constructor obsoleto en el middleware de localización de solicitudes
"Middleware: página de errores de la base de datos marcada como obsoleta"
El middleware del controlador de excepciones produce una excepción original
Llamada a una nueva sobrecarga de Validate por parte de ObjectModelValidator
Se ha quitado la codificación de nombre de cookie
Se han actualizado las versiones del paquete NuGet IdentityModel
"SignalR: se ha cambiado el tipo de opciones del protocolo de concentrador de MessagePack"
"SignalR: protocolo de concentrador MessagePack trasladado"
los métodos UseSignalR y UseConnections se han quitado
tipo de contenido CSV cambiado a compatible con los estándares
Análisis de código
Advertencia CA1416
Advertencia CA1417
Advertencia CA1831
Advertencia CA2013
Advertencia CA2014
Advertencia CA2015
Advertencia CA2200
Advertencia CA2247

Bibliotecas de Core .NET

Cambios de API relacionados con ensamblados para la publicación de un solo archivo
Los métodos de serialización BinaryFormatter obsoletos están obsoletos
Las API de seguridad de acceso del código están obsoletas
CreateCounterSetInstance throws InvalidOperationException
El valor predeterminado de ActivityIdFormat es W3C
Environment.OSVersion devuelve la versión correcta
El valor de FrameworkDescription es .NET, no .NET Core
Las API de GAC están obsoletas
Comprobaciones IsSupported intrínsecas de hardware
IntPtr y UIntPtr implementan IFormattable
LastIndexOf controla cadenas de búsqueda vacías
Rutas de acceso de URI con caracteres que no son ASCII en UNIX
Obsolescencias de API con identificadores de diagnóstico no predeterminados
Propiedades obsoletas en ConsoleLoggerOptions
Complejidad de LINQ OrderBy.First
Atributos de OSPlatform que se han cambiado de nombre o se han quitado
Retirada del paquete Microsoft.DotNet.PlatformAbstractions
PrincipalPermissionAttribute está obsoleto
Cambios de nombre de parámetro respecto a las versiones preliminares
Cambios de nombre de parámetro en ensamblados de referencia
Las API de comunicación remota están obsoletas
Se ha invertido el orden de la lista de Activity.Tags
Los métodos de comparación SSE y SSE2 controlan NaN
Thread.Abort obsoleto
Reconocimiento de URI de rutas UNC en UNIX
Las rutas de acceso al código UTF-7 están obsoletas
Cambio de comportamiento de Vector2.Lerp y Vector4.Lerp
Vector<T> inicia la excepción NotSupportedException

Criptografía
Las API de criptografía no se admiten en el explorador
Cryptography.Oid es de solo inicialización
Conjuntos de cifrado TLS predeterminados en Linux
Las sobrecargas de Create() en abstracciones criptográficas están obsoletas
 Valor FeedbackSize predeterminado cambiado

Entity Framework Core

Cambios importantes en EF Core 5.0

Globalización
Uso de bibliotecas de ICU en Windows
StringInfo y TextElementEnumerator son compatibles con UAX29
Categoría Unicode modificada para caracteres del alfabeto latino 1

Interop
Se elimina la compatibilidad con WinRT
Excepción al convertir un contenedor RCW en InterfaceIsIInspectable
Exclusión del sondeo del sufijo A/W en plataformas que no son de Windows

MSBuild
Archivos Directory.Packages.props importados de forma predeterminada
Símbolo de preprocesador de NETCOREAPP3_1 no definido
Cambio de comportamiento de PublishDepsFilePath
Cambio de TargetFramework de netcoreapp a net

Redes
La administración de rutas de acceso de cookies se ajusta a RFC 6265
LocalEndPoint se actualiza después de llamar a SendToAsync
MulticastOption.Group no acepta NULL
Las secuencias permiten operaciones Begin sucesivas
WinHttpHandler quitado del entorno de ejecución de .NET

Seguridad
Las API de seguridad de acceso del código están obsoletas
PrincipalPermissionAttribute está obsoleto
Las rutas de acceso al código UTF-7 están obsoletas

Serialización
BinaryFormatter.Deserialize vuelve a encapsular excepciones
JsonSerializer.Deserialize requiere una cadena de un solo carácter
Las aplicaciones ASP.NET Core deserializan los números entrecomillados
JsonSerializer.Serialize inicia la excepción ArgumentNullException
Constructores no públicos sin parámetros que no se usan para la deserialización
Se respetan las opciones al serializar pares clave-valor

Windows Forms
OutputType se establece en WinExe
 DataGridView no restablece las fuentes personalizadas
Los métodos inician la excepción ArgumentException
Los métodos inician la excepción ArgumentNullException
Las propiedades inician la excepción ArgumentOutOfRangeException
TextFormatFlags.ModifyString está obsoleto
Excepción InvalidOperationException por parte de las API de DataGridView
Uso de Microsoft.NET.Sdk por parte de las aplicaciones de WinForms
Controles de la barra de estado quitados

WPF
OutputType se establece en WinExe
Uso de Microsoft.NET.Sdk por parte de las aplicaciones de WPF
 Novedades de .NET Core 3.1
18/12/2020 • 6 minutes to read • Edit Online

En este artículo se describen las novedades de .NET Core 3.1. Esta versión contiene ligeras mejoras de .NET Core
3.0, y se centra en pequeñas correcciones, pero importantes. La característica más importante sobre .NET Core 3.1
es que es una versión de soporte técnico a largo plazo (LTS).
Si usa Visual Studio 2019, tendrá que actualizar a Visual Studio 2019, versión 16.4 o posterior para trabajar con
proyectos de .NET Core 3.1. Para obtener información sobre las novedades de la versión 16.4 de Visual Studio, vea
Novedades de la versión 16.4 de Visual Studio 2019.
Visual Studio para Mac también admite e incluye .NET Core 3.1 en Visual Studio para Mac 8.4.
Para más información sobre la versión, consulte el anuncio de .NET Core 3.1.
Descargue .NET Core 3.1 y empiece a trabajar en Windows, macOS o Linux.

Compatibilidad a largo plazo

.NET Core 3.1 es una versión LTS con soporte técnico de Microsoft durante los próximos tres años. Se recomienda
encarecidamente mover las aplicaciones a .NET Core 3.1. El ciclo de vida actual de otras versiones principales es el
siguiente:

REL EA SE N OTA

.NET Core 3.0 Fin del ciclo de vida el 3 de marzo de 2020.

.NET Core 2.2 Fin del ciclo de vida el 23 de diciembre de 2019.

.NET Core 2.1 Fin del ciclo de vida el 21 de agosto de 2021.

Para más información, consulte la directiva de soporte técnico de .NET Core.

appHost y certificación de macOS

Solo para macOS
A partir del SDK de .NET Core 3.1 para macOS, la configuración de appHost está deshabilitada de forma
predeterminada. Para obtener más información, vea Certificación de macOS Catalina y el impacto en las descargas
y proyectos de .NET Core.
Cuando la configuración de appHost está habilitada, .NET Core genera un ejecutable Mach-O nativo al compilar o
publicar. La aplicación se ejecuta en el contexto de appHost cuando se ejecuta desde el código fuente con el
comando dotnet run o mediante el inicio directo del ejecutable Mach-O.
Sin appHost, la única manera en la que un usuario puede iniciar una aplicación dependiente del marco es con el
comando dotnet <filename.dll> . Siempre se crea un instancia de appHost al publicar la aplicación de manera
independiente.
Puede configurar appHost en el nivel de proyecto, o bien cambiar la instancia de appHost de un comando dotnet
específico con el parámetro -p:UseAppHost :
Archivo del proyecto
 <PropertyGroup>
<UseAppHost>true</UseAppHost>
</PropertyGroup>

Parámetro de línea de comandos

dotnet run -p:UseAppHost=true

Para obtener más información sobre la configuración de UseAppHost , vea Propiedades de MSBuild para
Microsoft.NET.Sdk.

Windows Forms
Solo Windows

WARNING
Hay cambios importantes en Windows Forms.

Se incluyeron controles heredados en Windows Forms que llevan un tiempo sin estar disponibles en el cuadro de
herramientas del diseñador de Visual Studio. Estos controles se volvieron a reemplazar por otros nuevos en .NET
Framework 2.0 y se han quitado del SDK de escritorio para .NET Core 3.1.

C O N T RO L EL IM IN A DO REEM P L A Z O REC O M EN DA DO A P I A SO C IA DA S EL IM IN A DA S

DataGrid DataGridView DataGridCell

DataGridRow
DataGridTableCollection
DataGridColumnCollection
DataGridTableStyle
DataGridColumnStyle
DataGridLineStyle
DataGridParentRowsLabel
DataGridParentRowsLabelStyle
DataGridBoolColumn
DataGridTextBox
GridColumnStylesCollection
GridTableStylesCollection
HitTestType

ToolBar ToolStrip ToolBarAppearance

ToolBarButton ToolStripButton ToolBarButtonClickEventArgs

ToolBarButtonClickEventHandler
ToolBarButtonStyle
ToolBarTextAlign

ContextMenu ContextMenuStrip

Menu ToolStripDropDown MenuItemCollection

ToolStripDropDownMenu

MainMenu MenuStrip
 C O N T RO L EL IM IN A DO REEM P L A Z O REC O M EN DA DO A P I A SO C IA DA S EL IM IN A DA S

MenuItem ToolStripMenuItem

Se recomienda actualizar las aplicaciones a .NET Core 3.1 y pasar a los controles de reemplazo. Reemplazar los
controles es un proceso sencillo; se trata básicamente de "buscar y reemplazar" el tipo.

C++/CLI
Solo Windows
Se ha agregado compatibilidad con la creación de proyectos de C++/CLI (lo que también se conoce como "C++
administrado"). Los archivos binarios generados a partir de estos proyectos son compatibles con .NET Core 3.0 y
versiones posteriores.
Para agregar compatibilidad con C++/CLI a Visual Studio 2019 versión 16.4, instale la carga de trabajo Desarrollo
para el escritorio con C++. Esta carga de trabajo agrega dos plantillas a Visual Studio:
Biblioteca de clases de CLR (.NET Core)
Proyecto vacío de CLR (.NET Core)

Pasos siguientes
Revise los cambios importantes entre .NET Core 3.0 y 3.1.
Revise los cambios importantes de .NET Core 3.1 para aplicaciones de Windows Forms.
 Cambios importantes en .NET Core 3.1
18/12/2020 • 15 minutes to read • Edit Online

Si va a migrar a la versión 3.1 de .NET Core y ASP.NET Core, es posible que los cambios importantes de este
artículo afecten a la aplicación.

ASP.NET Core
HTTP: los cambios de SameSite del explorador afectan a la autenticación
HTTP: Los cambios de SameSite en los exploradores afectan a la autenticación.
Algunos exploradores, como Chrome y Firefox, han realizado cambios importantes en sus implementaciones de
SameSite para las cookies. Los cambios afectan a escenarios de autenticación remota, como OpenID Connect y
WS-Federation, que deben no participar mediante el envío de SameSite=None . Sin embargo, SameSite=None se
interrumpe en iOS 12 y en algunas versiones anteriores de otros exploradores. La aplicación debe detectar estas
versiones y omitir SameSite .
Para obtener información sobre esta incidencia, vea dotnet/aspnetcore#14996.
Versión introducida
3.1, versión preliminar 1
Comportamiento anterior
SameSite es una extensión de proyecto de norma de 2016 para cookies HTTP. Su objetivo era mitigar la
falsificación de solicitud entre sitios (CSRF). Originalmente se diseñó como una característica en la que los
servidores participaban si agregaban los nuevos parámetros. ASP.NET Core 2.0 agregó compatibilidad inicial con
SameSite .

Comportamiento nuevo
Google ha propuesto un nuevo proyecto de norma que no es compatible con versiones anteriores. La norma
cambia el modo predeterminado a Lax y agrega una nueva entrada None para no participar. Lax basta para la
mayoría de las cookies de aplicación, aunque interrumpe escenarios entre sitios como el inicio de sesión de
OpenID Connect y WS-Federation. La mayoría de los inicios de sesión de OAuth no se ven afectados debido a las
diferencias respecto al flujo de la solicitud. El nuevo parámetro None origina problemas de compatibilidad con los
clientes que han implementado el proyecto de norma anterior (por ejemplo, iOS 12). Chrome 80 va a incluir los
cambios. Vea Actualizaciones de SameSite para conocer la escala de tiempo de lanzamiento del producto Chrome.
ASP.NET Core 3.1 se ha actualizado para implementar el nuevo comportamiento de SameSite . La actualización
vuelve a definir el comportamiento de SameSiteMode.None para emitir SameSite=None y agrega un nuevo valor
SameSiteMode.Unspecified para omitir el atributo SameSite . Todas las API de cookies ahora tienen como valor
predeterminado Unspecified , aunque algunos componentes que usan cookies establecen valores más específicos
en sus escenarios, como la correlación de OpenID Connect y las cookies nonce.
Para obtener información sobre otros cambios recientes en esta área, vea HTTP: Cambio a Ninguno de algunos
valores predeterminados de cookie de SameSite. En ASP.NET Core 3.0, la mayoría de los valores predeterminados
se han cambiado de SameSiteMode.Lax a SameSiteMode.None, aunque se sigue usando la norma anterior.
Motivo del cambio
Cambios en el explorador y la especificación, como se ha explicado en el texto anterior.
Acción recomendada
Las aplicaciones que interactúan con sitios remotos, por ejemplo mediante inicio de sesión de terceros, necesitan:
 Probar esos escenarios en varios exploradores.
Aplicar la mitigación de detección de exploradores de la directiva de cookies tratada en Compatibilidad con
exploradores anteriores.
Para obtener instrucciones para las pruebas y la detección de exploradores, vea la sección siguiente.
P r o c e d i m i e n t o p a r a d e t e r m i n a r l a a fe c t a c i ó n

Pruebe la aplicación web con una versión cliente que pueda participar en el nuevo comportamiento. Chrome,
Firefox y Microsoft Edge Chromium tienen nuevas marcas de características de participación que se pueden usar
para las pruebas. Compruebe que la aplicación es compatible con versiones cliente anteriores después de haber
aplicado las revisiones, especialmente en el caso de Safari. Para obtener más información, vea Compatibilidad con
exploradores anteriores.
Ch r om e

Chrome 78 y versiones posteriores generan resultados de prueba engañosos. Esas versiones tienen aplicada una
mitigación temporal y permiten las cookies con menos de dos minutos de antigüedad. Con las marcas de prueba
adecuadas habilitadas, Chrome 76 y 77 generan resultados más precisos. Para probar el nuevo comportamiento,
cambie chrome://flags/#same-site-by-default-cookies a habilitado. Se ha notificado que en Chrome 75 y versiones
anteriores se produce un error con el nuevo valor None . Para obtener más información, vea Compatibilidad con
exploradores anteriores.
Google no tiene disponibles versiones anteriores de Chrome. Sin embargo, puede descargar versiones anteriores
de Chromium, lo que basta para las pruebas. Siga las instrucciones de Descargar Chromium.
Chromium 76 Win64
Chromium 74 Win64
Sa fa r i

Safari 12 ha implementado estrictamente el proyecto anterior, con lo que se produce un error si se detecta el nuevo
valor None en las cookies. Esto se debe evitar con el código de detección de exploradores mostrado en
Compatibilidad con exploradores anteriores. Asegúrese de probar Safari 12 y 13, así como los inicios de sesión de
estilo sistema operativo basados en WebKit mediante la Biblioteca de autenticación de Microsoft (MSAL), la
Biblioteca de autenticación de Active Directory (ADAL) o cualquier biblioteca que esté usando. El problema
depende de la versión del sistema operativo subyacente. Se sabe que OSX Mojave 10.14 e iOS 12 tienen
problemas de compatibilidad con el nuevo comportamiento. La actualización a OSX Catalina 10.15 o iOS 13
corrige el problema. Safari no tiene actualmente una marca de participación para probar el comportamiento de la
nueva especificación.
F i r e fo x

La compatibilidad de Firefox con la nueva norma se puede probar en la versión 68 y posteriores mediante la
participación en la página about:config con la marca de características network.cookie.sameSite.laxByDefault . No
se han comunicado problemas de compatibilidad en versiones anteriores de Firefox.
M i c r o so ft Ed g e

Aunque Microsoft Edge admite la antigua norma SameSite , a partir de la versión 44 no tiene ningún problema de
compatibilidad con la nueva.
M i c r o so ft Ed g e C h r o m i u m

La marca de características es edge://flags/#same-site-by-default-cookies . No se ha observado ningún problema

de compatibilidad al realizar pruebas con Microsoft Edge Chromium 78.
El e c t r o n

Las versiones de Electron incluyen versiones anteriores de Chromium. Por ejemplo, la versión de Electron usada
por Microsoft Teams es Chromium 66, que exhibe el comportamiento anterior. Realice sus propias pruebas de
compatibilidad con la versión de Electron que use el producto. Para obtener más información, vea Compatibilidad
con exploradores anteriores.
Co m pat i bi l i dad c o n expl o r ado r es an t er i o r es

La norma SameSite de 2016 obligaba a tratar los valores desconocidos como valores SameSite=Strict . Por tanto,
los exploradores anteriores que admiten la norma original se pueden interrumpir al detectar una propiedad
SameSite con un valor de None . Las aplicaciones web deben implementar la detección de exploradores si
pretenden admitir estos exploradores antiguos. ASP.NET Core no implementa la detección de exploradores
automáticamente porque los valores de encabezado de solicitud User-Agent son muy inestables y cambian
semanalmente. En su lugar, un punto de extensión de la directiva de cookies permite agregar lógica específica de
User-Agent .

En Startup.cs, agregue el siguiente código:

private void CheckSameSite(HttpContext httpContext, CookieOptions options)

{
if (options.SameSite == SameSiteMode.None)
{
var userAgent = httpContext.Request.Headers["User-Agent"].ToString();
// TODO: Use your User Agent library of choice here.
if (/* UserAgent doesn't support new behavior */)
{
options.SameSite = SameSiteMode.Unspecified;
}
}
}

public void ConfigureServices(IServiceCollection services)

{
services.Configure<CookiePolicyOptions>(options =>
{
options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
options.OnAppendCookie = cookieContext =>
CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
options.OnDeleteCookie = cookieContext =>
CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
});
}

public void Configure(IApplicationBuilder app)

{
// Before UseAuthentication or anything else that writes cookies.
app.UseCookiePolicy();

app.UseAuthentication();
// code omitted for brevity
}

M o d i fi c a d o r e s d e n o p a r t i c i p a c i ó n

El modificador de compatibilidad Microsoft.AspNetCore.SuppressSameSiteNone permite no participar temporalmente

en el nuevo comportamiento de cookies de ASP.NET Core. Agregue el siguiente JSON a un archivo
runtimeconfig.template.json del proyecto:

{
"configProperties": {
"Microsoft.AspNetCore.SuppressSameSiteNone": "true"
}
}

O t r a s v e r si o n e s

Próximamente habrá revisiones de SameSite relacionadas para:

ASP.NET Core 2.1, 2.2 y 3.0
Microsoft.Owin 4.1
System.Web (para .NET Framework 4.7.2 y posterior)

Categoría
ASP.NET
API afectadas
Microsoft.AspNetCore.Builder.CookiePolicyOptions.MinimumSameSitePolicy
Microsoft.AspNetCore.Http.CookieBuilder.SameSite
Microsoft.AspNetCore.Http.CookieOptions.SameSite
Microsoft.AspNetCore.Http.SameSiteMode
Microsoft.Net.Http.Headers.SameSiteMode
Microsoft.Net.Http.Headers.SetCookieHeaderValue.SameSite

Windows Forms
Controles eliminados
El evento CellFormatting no se produce si se muestra información en pantalla
Controles eliminados
A partir de .NET Core 3.1, algunos controles de Windows Forms ya no están disponibles.
Descripción del cambio
A partir de .NET Core 3.1, varios controles de Windows Forms ya no están disponibles. Los controles de reemplazo,
con un mejor diseño y soporte técnico, se introdujeron en .NET Framework 2.0. Los controles en desuso se
eliminaron previamente de los cuadros de herramientas del diseñador, pero todavía estaban disponibles para su
uso.
Los siguientes tipos ya no están disponibles:
ContextMenu
DataGrid
DataGrid.HitTestType
DataGridBoolColumn
DataGridCell
DataGridColumnStyle
DataGridLineStyle
DataGridParentRowsLabelStyle
DataGridPreferredColumnWidthTypeConverter
DataGridTableStyle
DataGridTextBox
DataGridTextBoxColumn
GridColumnStylesCollection
GridTablesFactory
GridTableStylesCollection
IDataGridEditingService
IMenuEditorService
MainMenu
Menu
Menu.MenuItemCollection
MenuItem
ToolBar
ToolBarAppearance
ToolBarButton
 ToolBar.ToolBarButtonCollection
ToolBarButtonClickEventArgs
ToolBarButtonStyle
ToolBarTextAlign
Versión introducida
3.1
Acción recomendada
Cada control eliminado tiene un control de reemplazo recomendado. Consulte la tabla siguiente:

A P I A SO C IA DA S Q UE SE H A N
C O N T RO L EL IM IN A DO ( A P I) REEM P L A Z O REC O M EN DA DO EL IM IN A DO

ContextMenu ContextMenuStrip

DataGrid DataGridView DataGridCell, DataGridRow,

DataGridTableCollection,
DataGridColumnCollection,
DataGridTableStyle,
DataGridColumnStyle,
DataGridLineStyle,
DataGridParentRowsLabel,
DataGridParentRowsLabelStyle,
DataGridBoolColumn, DataGridTextBox,
GridColumnStylesCollection,
GridTableStylesCollection, HitTestType

MainMenu MenuStrip

Menú ToolStripDropDown, MenuItemCollection

ToolStripDropDownMenu

MenuItem ToolStripMenuItem

ToolBar ToolStrip ToolBarAppearance

ToolBarButton ToolStripButton ToolBarButtonClickEventArgs,

ToolBarButtonClickEventHandler,
ToolBarButtonStyle, ToolBarTextAlign

Categoría
Windows Forms
API afectadas
System.Windows.Forms.ContextMenu
System.Windows.Forms.GridColumnStylesCollection
System.Windows.Forms.GridTablesFactory
System.Windows.Forms.GridTableStylesCollection
System.Windows.Forms.IDataGridEditingService
System.Windows.Forms.MainMenu
System.Windows.Forms.Menu
System.Windows.Forms.Menu.MenuItemCollection
System.Windows.Forms.MenuItem
System.Windows.Forms.ToolBar
 System.Windows.Forms.ToolBar.ToolBarButtonCollection
System.Windows.Forms.ToolBarAppearance
System.Windows.Forms.ToolBarButton
System.Windows.Forms.ToolBarButtonClickEventArgs
System.Windows.Forms.ToolBarButtonStyle
System.Windows.Forms.ToolBarTextAlign
System.Windows.Forms.DataGrid
System.Windows.Forms.DataGrid.HitTestType
System.Windows.Forms.DataGridBoolColumn
System.Windows.Forms.DataGridCell
System.Windows.Forms.DataGridColumnStyle
System.Windows.Forms.DataGridLineStyle
System.Windows.Forms.DataGridParentRowsLabelStyle
System.Windows.Forms.DataGridPreferredColumnWidthTypeConverter
System.Windows.Forms.DataGridTableStyle
System.Windows.Forms.DataGridTextBox
System.Windows.Forms.DataGridTextBoxColumn
System.Windows.Forms.Design.IMenuEditorService
**
El evento CellFormatting no se produce si se muestra información en pantalla.
Ahora, DataGridView muestra información en pantalla del texto y los errores de una celda cuando se mantiene el
mouse sobre ella y cuando se selecciona mediante el teclado. Si se muestra información en pantalla, no se produce
el evento DataGridView.CellFormatting.
Descripción del cambio
Antes de .NET Core 3.1, un elemento DataGridView con la propiedad ShowCellToolTips establecida en true
mostraba información en pantalla del texto y los errores de una celda cuando se mantenía el mouse sobre ella. La
información en pantalla no se mostraba si la celda se seleccionaba mediante el teclado (por ejemplo, mediante la
tecla Tab, teclas de método abreviado o las teclas de dirección). Si el usuario editaba una celda y, luego, mientras el
elemento DataGridView aún estaba en modo de edición, mantenía el mouse sobre una celda que no tenía
establecida la propiedad ToolTipText, se producía un evento CellFormatting para dar formato al texto de la celda
para su presentación en ella.
Para cumplir los estándares de accesibilidad, a partir de .NET Core 3.1, un elemento DataGridView que tenga la
propiedad ShowCellToolTips establecida en true muestra información en pantalla del texto y los errores de una
celda no solo cuando se mantiene el mouse sobre la celda, sino también cuando se selecciona mediante el teclado.
Como consecuencia de este cambio, el evento CellFormattingno se produce cuando se mantiene el mouse sobre
las celdas que no tienen establecida la propiedad ToolTipText mientras DataGridView está en modo de edición. El
evento no se produce porque el contenido de la celda se muestra como información en pantalla en lugar de
mostrarse en la celda.
Versión introducida
3.1
Acción recomendada
Refactorice cualquier código que dependa del evento CellFormatting mientras DataGridView está en modo de
edición.
Categoría
Windows Forms
API afectadas
None
**
 Novedades de .NET Core 3.0
18/12/2020 • 46 minutes to read • Edit Online

En este artículo se describen las novedades de .NET Core 3.0. Una de las mejoras más importantes es la
compatibilidad con las aplicaciones de Escritorio de Windows (solo Windows). Mediante el componente Escritorio
de Windows del SDK de .NET Core 3.0, puede portar sus aplicaciones de Windows Forms y
Windows Presentation Foundation (WPF). Para ser más precisos, el componente Escritorio de Windows solo se
admite e incluye en Windows. Para obtener más información, vea la sección Escritorio de Windows más adelante en
este artículo.
.NET Core 3.0 agrega compatibilidad con C# 8.0. Se recomienda encarecidamente usar Visual Studio 2019, versión
16.3 o una versión posterior, Visual Studio para Mac 8.3 o una versión posterior, o Visual Studio Code con la última
extensión de C# .
Descargue .NET Core 3.0 y empiece a trabajar ya en Windows, macOS o Linux.
Para obtener más información acerca de la versión, consulte el anuncio de .NET Core 3.0.
Microsoft considera .NET Core RC1 como listo para producción y es totalmente compatible. Si usa una versión
preliminar, debe pasar a la versión RTM para obtener soporte técnico continuo.

Mejoras del lenguaje C# 8.0

C# 8.0 también forma parte de esta versión, que incluye la característica de tipos de referencia que aceptan valores
NULL, flujos asincrónicos y más patrones. Para obtener más información sobre las características de C# 8.0, vea
Novedades de C# 8.0.
Tutoriales relacionados con las características del lenguaje de C# 8.0:
Tutorial: Expresar la intención del diseño con mayor claridad con tipos de referencia que aceptan valores NULL y
que no aceptan valores NULL
Tutorial: Generación y uso de secuencias asincrónicas con C# 8.0 y .NET Core 3.0
Tutorial: Uso de la coincidencia de patrones para compilar algoritmos basados en tipos y basados en datos
Se han agregado mejoras del lenguaje para admitir las siguientes características de API que se detallan a
continuación:
Rangos e índices
Flujos asincrónicos

.NET Standard 2.1

.NET Core 3.0 implementa .NET Standard 2.1 . Pero la plantilla predeterminada dotnet new classlib genera un
proyecto que sigue destinado a .NET Standard 2.0 . Para destinarlo a .NET Standard 2.1 , edite el archivo de
proyecto y cambie la propiedad TargetFramework a netstandard2.1 :
 <Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
</PropertyGroup>

</Project>

Si usa Visual Studio, necesita Visual Studio 2019, ya que Visual Studio 2017 no admite .NET Standard 2.1 ni
.NET Core 3.0 .

Compilación e implementación
Archivos ejecutables predeterminados
.NET Core compila ahora archivos ejecutables dependientes del marco de forma predeterminada. Este
comportamiento es nuevo en las aplicaciones que usan una versión de .NET Core instalada globalmente.
Anteriormente, solo las implementaciones independientes generarían un archivo ejecutable.
Durante dotnet build o dotnet publish , se crea un archivo ejecutable (conocido como appHost ) que coincide
con el entorno y la plataforma del SDK que se usa. Estos ejecutables funcionan de la misma forma que los
ejecutables nativos:
Haga doble clic en el archivo ejecutable.
También puede iniciar la aplicación desde un símbolo del sistema directamente, como myapp.exe en Windows y
./myapp en Linux y macOS.

appHost y certificación de macOS

Solo para macOS
A partir del SDK de .NET Core 3.0 para macOS certificado, el valor para generar un archivo ejecutable
predeterminado (conocido como appHost) está deshabilitado de forma predeterminada. Para obtener más
información, vea Certificación de macOS Catalina y el impacto en las descargas y proyectos de .NET Core.
Cuando la configuración de appHost está habilitada, .NET Core genera un ejecutable Mach-O nativo al compilar o
publicar. La aplicación se ejecuta en el contexto de appHost cuando se ejecuta desde el código fuente con el
comando dotnet run o mediante el inicio directo del ejecutable Mach-O.
Sin appHost, la única manera en la que un usuario puede iniciar una aplicación dependiente del marco es con el
comando dotnet <filename.dll> . Siempre se crea un instancia de appHost al publicar la aplicación de manera
independiente.
Puede configurar appHost en el nivel de proyecto, o bien cambiar la instancia de appHost de un comando dotnet
específico con el parámetro -p:UseAppHost :
Archivo del proyecto

<PropertyGroup>
<UseAppHost>true</UseAppHost>
</PropertyGroup>

Parámetro de línea de comandos

dotnet run -p:UseAppHost=true

Para obtener más información sobre la configuración de UseAppHost , vea Propiedades de MSBuild para
Microsoft.NET.Sdk.
Archivos ejecutables de único archivo
El comando dotnet publish admite empaquetar la aplicación en un ejecutable de archivo único específico de la
plataforma. El archivo ejecutable es autoextraíble y contiene todas las dependencias (incluidas las nativas)
necesarias para ejecutar la aplicación. Cuando la aplicación se ejecuta por primera vez, se extrae en un directorio
que se basa en el nombre de la aplicación y el identificador de compilación. El inicio es más rápido cuando se
vuelve a ejecutar la aplicación. La aplicación no necesita extraerse por segunda vez a menos que se haya utilizado
una nueva versión.
Para publicar un ejecutable de archivo único, establezca PublishSingleFile en el proyecto o en la línea de
comandos con el comando dotnet publish :

<PropertyGroup>
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
<PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

o bien

dotnet publish -r win10-x64 -p:PublishSingleFile=true

Para obtener más información sobre la publicación de archivos únicos, vea el documento de diseño del programa
de instalación de conjunto de archivos únicos.
Vinculación de ensamblados
El SDL de .NET Core 3.0 cuenta con una herramienta que puede reducir el tamaño de las aplicaciones mediante el
análisis de IL y el recorte de los ensamblados no usados.
Las aplicaciones independientes incluyen todo lo necesario para ejecutar el código, sin necesidad de instalar .NET
en el equipo host. Sin embargo, muchas veces, la aplicación solo requiere un pequeño subconjunto de marco para
que funcione, y otras bibliotecas que no se utilizan podrían quitarse.
.NET Core incluye ahora un valor que usará la herramienta Enlazador de IL para examinar el nivel de integridad de
la aplicación. Esta herramienta detecta el código que es necesario y, después, recorta las bibliotecas no utilizadas.
Esta herramienta puede reducir significativamente el tamaño de implementación de algunas aplicaciones.
Para habilitar esta herramienta, agregue el valor <PublishTrimmed> en el proyecto y publique una aplicación
independiente:

<PropertyGroup>
<PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

dotnet publish -r <rid> -c Release

Por ejemplo, la nueva y básica plantilla de proyecto de consola "Hola mundo" que se incluye, cuando se publica,
tiene un tamaño aproximado de 70 MB. Mediante el uso de <PublishTrimmed> , ese tamaño se reduce a unos 30 MB.
Es importante tener en cuenta que las aplicaciones o marcos (incluidos ASP.NET Core y WPF) que usan la reflexión
o las características dinámicas relacionadas, se interrumpirán a menudo cuando se recorten. Esta interrupción se
produce porque el enlazador no conoce este comportamiento dinámico y no puede determinar qué tipos de marco
son necesarios para la reflexión. La herramienta Enlazador de IL puede configurarse para tener en cuenta este
escenario.
Por encima de todo lo demás, no olvide probar la aplicación después del recorte.
Para más información sobre la herramienta Enlazador de IL, vea la documentación o visite el repositorio
mono/linker.
Compilación en niveles
La compilación en niveles (TC) está activada de forma predeterminada con .NET Core 3.0. Esta característica permite
que el runtime use el compilador Just-In-Time (JIT) de forma más flexible para lograr un mejor rendimiento.
La principal ventaja de la compilación en niveles es que ofrece dos maneras de aplicar JIT a los métodos: con un
nivel de menor calidad, pero más rápido, o un nivel de mayor calidad, pero más lento. La calidad se refiere al grado
de optimización del método. La compilación en niveles contribuye a mejorar el rendimiento de una aplicación a
medida que pasa por distintas fases de ejecución, desde el inicio hasta el estado estable. Cuando la compilación en
niveles está deshabilitada, todos los métodos se compilan de una manera única que prima el rendimiento de
estado estable sobre el rendimiento de inicio.
Cuando la compilación en niveles está habilitada, se aplica el comportamiento siguiente a la compilación de
métodos al iniciar una aplicación:
Si el método tiene código compilado mediante Ahead-Of-Time, o ReadyToRun, se usa el código generado
previamente.
De lo contrario, el método se compila mediante JIT. Normalmente, estos métodos son genéricos con respecto a
los tipos de valor.
JIT rápido produce código de menor calidad (o menos optimizado) más rápidamente. En .NET Core 3.0,
JIT rápido está habilitado de forma predeterminada para los métodos que no contienen ningún bucle y
tiene preferencia durante el inicio.
JIT de optimización completa produce código de mayor calidad (o más optimizado) más lentamente. En el
caso de los métodos en los que no se use la compilación mediante JIT rápida (por ejemplo, si el método
tiene el atributo MethodImplOptions.AggressiveOptimization), se utilizará la compilación mediante JIT
totalmente optimizada.
En el caso de los métodos a los que se llama con frecuencia, el compilador Just-in-Time al final crea código
totalmente optimizado en segundo plano. Luego, el código optimizado reemplaza el código compilado
previamente de ese método.
El código generado con compilación mediante JIT rápida puede ejecutarse más lentamente, asignar más memoria o
usar más espacio de pila. Si hay problemas, puede deshabilitar JIT rápido con esta propiedad de MSBuild en el
archivo de proyecto:

<PropertyGroup>
<TieredCompilationQuickJit>false</TieredCompilationQuickJit>
</PropertyGroup>

Para deshabilitar completamente la compilación en niveles, use esta propiedad de MSBuild en el archivo de
proyecto:

<PropertyGroup>
<TieredCompilation>false</TieredCompilation>
</PropertyGroup>

TIP
Si cambia esta configuración en el archivo de proyecto, es posible que deba realizar una compilación limpia para que se refleje
la nueva configuración (elimine los directorios obj y bin y vuelva a compilar).
Para obtener más información sobre la configuración de la compilación en tiempo de ejecución, vea Opciones de
configuración del entorno de ejecución para compilación.
Imágenes ReadyToRun
Puede mejorar el tiempo de inicio de la aplicación .NET Core mediante la compilación de los ensamblados de
aplicación como el formato ReadyToRun (R2R). R2R es una forma de compilación Ahead Of Time (AOT).
Los binarios de R2R mejoran el rendimiento de inicio reduciendo la cantidad de trabajo que el compilador Just-In-
Time (JIT) debe llevar a cabo cuando se carga la aplicación. Los binarios contienen código nativo similar en
comparación con lo que generaría el compilador JIT. Sin embargo, los binarios de R2R son más grandes porque
contienen tanto el código de lenguaje intermedio (IL), que sigue siendo necesario para algunos escenarios, como la
versión nativa del mismo código. R2R solo está disponible cuando publica una aplicación independiente que tenga
como destino entornos de tiempo de ejecución específicos (RID), como Linux x64 o Windows x64.
Para compilar el proyecto como ReadyToRun, haga lo siguiente:
1. Agregue el valor <PublishReadyToRun> al proyecto:

<PropertyGroup>
<PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>

2. Publique una aplicación independiente. Por ejemplo, este comando crea una aplicación independiente para
la versión de 64 bits de Windows:

dotnet publish -c Release -r win-x64 --self-contained

Restricciones multiplataforma y de arquitectura

Actualmente, el compilador ReadyToRun no admite la compatibilidad cruzada. Debe compilar en un destino dado.
Por ejemplo, si desea imágenes R2R para Windows x64, deberá ejecutar el comando de publicación en ese entorno.
Excepciones de la compatibilidad cruzada:
Windows x64 se puede usar para compilar imágenes de Windows ARM32, ARM64 y x86.
Windows x86 se puede usar para compilar imágenes de Windows ARM32.
Linux x64 se puede usar para compilar imágenes de Linux ARM32 y ARM64.
Para obtener más información, consulte Ready to Run.

Runtime y SDK
Puesta al día del runtime de versiones principales
.NET Core 3.0 presenta una característica opcional que permite poner la aplicación al día con la versión principal
más reciente de .NET Core. Además, se agregó una nueva configuración para controlar cómo se aplica la puesta al
día a la aplicación. Esto se puede configurar de las maneras siguientes:
Propiedad de archivo del proyecto: RollForward
Propiedad de archivo de configuración en tiempo de ejecución: rollForward
Variable de entorno: DOTNET_ROLL_FORWARD
Argumento de línea de comandos: --roll-forward
Debe especificarse uno de los valores siguientes. Si se omite la configuración, Minor es el valor predeterminado.
LatestPatch
Se pone al día con la última versión de revisión. Se deshabilita la puesta al día de versiones secundarias.
 Minor
Se pone al día con la versión secundaria mínima superior, si no se encuentra la versión secundaria solicitada. Si
se encuentra la versión secundaria solicitada, se utiliza la directiva LatestPatch .
Major
Se pone al día con la versión secundaria mínima superior, y la versión secundaria mínima, si no se encuentra la
versión secundaria solicitada. Si se encuentra la versión principal solicitada, se utiliza la directiva Minor .
LatestMinor
Se pone al día con la última versión secundaria, aunque la versión secundaria solicitada esté presente. Se
destina a escenarios de hospedaje de componentes.
LatestMajor
Se pone al día con la última versión principal y la última versión secundaria, aunque la versión principal
solicitada esté presente. Se destina a escenarios de hospedaje de componentes.
Disable
No se pone al día. Solo se enlaza a la versión especificada. No se recomienda esta directiva para uso general, ya
que deshabilita la capacidad de puesta al día con las revisiones más recientes. Este valor solo se recomienda a
efectos de pruebas.
Además del valor Disable , todos los valores usarán la última versión de revisión disponible.
De forma predeterminada, si la versión solicitada (como se especifica en .runtimeconfig.json para la aplicación) es
una versión de lanzamiento, solo se tienen en cuenta las versiones de lanzamiento para la puesta al día. Se omiten
las versiones preliminares. Si no hay ninguna versión de lanzamiento que coincida, se tienen en cuenta las
versiones preliminares. Este comportamiento se puede cambiar estableciendo
DOTNET_ROLL_FORWARD_TO_PRERELEASE=1 , en cuyo caso siempre se tienen en cuenta todas las versiones.

Compilación de dependencias de copias

El comando dotnet build copia ahora las dependencias de NuGet para la aplicación de la caché de NuGet a la
carpeta de salida de compilación. Anteriormente, las dependencias solo se copiaban como parte de dotnet publish
.
Hay algunas operaciones, como la publicación de páginas Razor y la vinculación, que aún es necesario publicar.
Herramientas locales
.NET Core 3.0 presenta herramientas locales. Las herramientas locales son similares a las herramientas globales
pero están asociadas a una ubicación concreta en el disco. Las herramientas locales no están disponibles
globalmente y se distribuyen como paquetes NuGet.

WARNING
Si ha probado herramientas locales en la versión preliminar 1 de .NET Core 3.0, tales como la ejecución de
dotnet tool restore o de dotnet tool install , elimine la carpeta de caché de herramientas locales. En caso contrario,
las herramientas locales no funcionan en las versiones más recientes. Esta carpeta se encuentra en:
En macOS, Linux: rm -r $HOME/.dotnet/toolResolverCache

En Windows: rmdir /s %USERPROFILE%\.dotnet\toolResolverCache

Las herramientas locales se basan en un nombre de archivo de manifiesto dotnet-tools.json del directorio actual.
Este archivo de manifiesto define las herramientas que estarán disponibles en esa carpeta y a continuación. Puede
distribuir el archivo de manifiesto con su código para asegurarse de que todo aquel que trabaje con su código
pueda restaurar y utilizar las mismas herramientas.
Para las herramientas locales y globales, se requiere una versión compatible del entorno de ejecución. Actualmente,
muchas herramientas de NuGet.org tienen como destino el entorno de ejecución de .NET Core 2.1. Para instalar
estas herramientas local o globalmente, aún tendría que instalar NET Core 2.1 Runtime.
Opciones nuevas de global.json
El archivo global.json tiene opciones nuevas que proporcionan más flexibilidad cuando se intenta definir qué
versión de la SDK de .NET Core se usa. Las opciones nuevas son:
allowPrerelease : Indica si la resolución del SDK debe tener en cuenta las versiones preliminares a la hora de
seleccionar la versión del SDK que se va a usar.
rollForward : indica la directiva de puesta al día que se va a usar al seleccionar una versión del SDK, ya sea
como reserva si falta una versión específica del SDK o como una directiva para usar una versión superior.
Para más información sobre los cambios, incluidos los valores predeterminados, los valores admitidos y reglas de
coincidencia nuevas, consulte la información general de global.json.
Tamaños del montón de recolección de elementos no utilizados más pequeños
Se ha reducido el tamaño predeterminado del montón del recolector de elementos no utilizados, lo que se traduce
en que .NET Core usa menos memoria. Este cambio se adapta mejor al presupuesto de asignación de generación 0
con tamaños de caché de procesador moderno.
Compatibilidad con Large Pages de recolección de elementos no utilizados
Large Pages (también conocida como Huge Pages en Linux) es una característica en la que el sistema operativo es
capaz de establecer regiones de memoria más grandes que el tamaño de página nativo (a menudo, 4 K) para
mejorar el rendimiento de la aplicación que solicita estas páginas grandes.
Ahora, el recolector de elementos no utilizados puede configurarse con el valor GCLargePages como
característica opcional para elegir la asignación de páginas grandes en Windows.

Escritorio de Windows y COM

Windows Installer del SDK de .NET Core
El instalador MSI para Windows ha cambiado a partir de .NET Core 3.0. Los instaladores del SDK actualizarán ahora
las versiones de la banda de características del SDK. Las bandas de características se definen en los grupos de
centenas de la sección revisión del número de versión. Por ejemplo, 3.0.101 y 3.0.201 son versiones de dos
bandas de características distintas mientras que 3.0.101 y 3.0.199 están en la misma banda de características. Y,
cuando se instale el SDK 3.0.101 de .NET Core, se quitará el SDK 3.0.100 de .NET Core de la máquina si existe.
Cuando se instale el SDK 3.0.200 de .NET Core en la misma máquina, no se quitará el SDK 3.0.101 de .NET Core.
Para obtener más información sobre las versiones, vea el artículo de introducción a la creación de versiones de
.NET Core.
Escritorio de Windows
.NET Core 3.0 admite aplicaciones de escritorio de Windows con Windows Presentation Foundation (WPF) y
Windows Forms. Estos marcos también admiten el uso de controles modernos y los estilos de Fluent de la
biblioteca de XAML de la interfaz de usuario de Windows (WinUI) a través de islas XAML.
El componente Escritorio de Windows forma parte del SDK de Windows .NET Core 3.0.
Puede crear una aplicación de Windows Forms o WPF con los siguientes comandos dotnet :

dotnet new wpf

dotnet new winforms

Visual Studio 2019 agrega plantillas de nuevo proyecto para WPF y Windows Forms de .NET Core 3.0.
Para obtener más información sobre cómo migrar una aplicación existente de .NET Framework, vea los artículos
sobre cómo portar proyectos de WPF y cómo portar proyectos de Windows Forms.
PPP alto de WinForms
En .NET Core, las aplicaciones de Windows Forms pueden establecer el modo de valores altos de PPP con
Application.SetHighDpiMode(HighDpiMode). El método SetHighDpiMode establece el modo de valores altos de PPP
correspondiente a menos que la opción se haya establecido por otros medios como App.Manifest o P/Invoke antes
de Application.Run .
Los posibles valores de highDpiMode , expresados por la enumeración System.Windows.Forms.HighDpiMode son:
DpiUnaware
SystemAware
PerMonitor
PerMonitorV2
DpiUnawareGdiScaled

Para más información sobre los modos de valores altos de PPP, consulte el artículo sobre desarrollo de aplicaciones
de escritorio con valores altos de PPP en Windows.
Creación de componentes COM
En Windows, ahora puede crear componentes COM administrados invocables. Esta capacidad es fundamental para
usar .NET Core con modelos de complemento COM, así como para ofrecer paridad con .NET Framework.
A diferencia de .NET Framework, donde se utilizó mscoree.dll como servidor COM, .NET Core agregará un archivo
dll de inicio nativo al directorio bin al compilar el componente COM.
Para ver un ejemplo de cómo crear un componente COM y usarlo, consulte la demostración de COM.
Interoperabilidad nativa de Windows
Windows ofrece una API nativa enriquecida en forma de API de C sin formato, COM y WinRT. Mientras que
.NET Core admite P/Invoke , .NET Core 3.0 agrega la capacidad de API COM CoCreate y API WinRT Activate .
Para obtener un ejemplo de código, vea la demostración de Excel.
Implementación de MSIX
MSIX es un nuevo formato de paquete de aplicación de Windows. Se puede usar para implementar aplicaciones de
escritorio de .NET Core 3.0 en Windows 10.
El proyecto de paquete de aplicación de Windows, disponible en Visual Studio 2019, le permite crear paquetes de
MSIX con aplicaciones de .NET Core independientes.
El archivo del proyecto de .NET Core debe especificar los tiempos de ejecución admitidos en la propiedad
<RuntimeIdentifiers> :

<RuntimeIdentifiers>win-x86;win-x64</RuntimeIdentifiers>

Mejoras de Linux
SerialPort para Linux
.Net Core 3.0 proporciona compatibilidad básica para System.IO.Ports.SerialPort en Linux.
Anteriormente, .NET Core solo admitía el uso de SerialPort en Windows.
Para obtener más información sobre la compatibilidad limitada para el puerto de serie en Linux, vea Problema
#33146 de GitHub.
Docker y límites de memoria de cgroup
La ejecución de .NET Core 3.0 en Linux con Docker funciona mejor con límites de memoria de cgroup. La ejecución
de un contenedor de Docker con límites de memoria, como con docker run -m , cambia el comportamiento de
.NET Core.
Tamaño predeterminado del montón del recolector de elementos no utilizados (GC): máximo de 20 MB o 75 %
del límite de memoria en el contenedor.
Puede establecerse el tamaño explícito como número absoluto o porcentaje del límite de cgroup.
El tamaño mínimo del segmento reservado por el montón de GC es de 16 MB. Con este tamaño se reduce el
número de montones que se crean en las máquinas.
Compatibilidad de GPIO con Raspberry Pi
Se han publicado dos paquetes en NuGet que puede usar para la programación de GPIO:
System.Device.Gpio
Iot.Device.Bindings
Los paquetes GPIO incluyen interfaces API para dispositivos GPIO, SPI, I2C y PWM. El paquete de enlaces de IoT
incluye enlaces de dispositivos. Para obtener más información, vea el repositorio de GitHub de los dispositivos.
Compatibilidad con ARM64 para Linux
.NET Core 3.0 agrega compatibilidad con ARM64 para Linux. El principal caso de uso de ARM64 son escenarios de
IoT. Para obtener más información, vea el artículo sobre el estado de ARM64 de .NET Core.
Hay imágenes de docker para .NET Core en ARM64 disponibles para Alpine, Debian y Ubuntu.

NOTE
Windows aún no ofrece soporte técnico para ARM64 .

Seguridad
TLS 1.3 y OpenSSL 1.1.1 en Linux
.NET Core aprovecha ahora la ventaja de la compatibilidad con TLS 1.3 en OpenSSL 1.1.1, cuando está disponible
en un entorno determinado. Con TLS 1.3:
Se han mejorado los tiempos de conexión con menores recorridos de ida y vuelta necesarios entre el cliente y
servidor.
Se ha mejorado la seguridad gracias a la eliminación de varios algoritmos criptográficos obsoletos y no seguros.
Cuando está disponible, .NET Core 3.0 utiliza OpenSSL 1.1.1 , OpenSSL 1.1.0 o OpenSSL 1.0.2 en un sistema
Linux. Si OpenSSL 1.1.1 está disponible, los tipos System.Net.Security.SslStream y System.Net.Http.HttpClient,
utilizarán TLS 1.3 (suponiendo que el cliente y el servidor admitan TLS 1.3 ).

IMPORTANT
Windows y macOS aún no admiten TLS 1.3 .

El siguiente ejemplo de C# 8.0 muestra .NET Core 3.0 en Ubuntu 18.10 al conectarse a https://www.cloudflare.com:
 using System;
using System.Net.Security;
using System.Net.Sockets;
using System.Threading.Tasks;

namespace whats_new
{
public static class TLS
{
public static async Task ConnectCloudFlare()
{
var targetHost = "www.cloudflare.com";

using TcpClient tcpClient = new TcpClient();

await tcpClient.ConnectAsync(targetHost, 443);

using SslStream sslStream = new SslStream(tcpClient.GetStream());

await sslStream.AuthenticateAsClientAsync(targetHost);
await Console.Out.WriteLineAsync($"Connected to {targetHost} with {sslStream.SslProtocol}");
}
}
}

Cifrados de criptografía
.NET Core 3.0 agrega compatibilidad con los cifrados AES-GCM y AES-CCM , que se implementan con
System.Security.Cryptography.AesGcm y System.Security.Cryptography.AesCcm respectivamente. Estos dos
algoritmos son algoritmos AEAD (Authenticated Encryption with Associated Data).
El código siguiente muestra cómo utilizar cifrado AesGcm para cifrar y descifrar datos aleatorios.
 using System;
using System.Linq;
using System.Security.Cryptography;

namespace whats_new
{
public static class Cipher
{
public static void Run()
{
// key should be: pre-known, derived, or transported via another channel, such as RSA encryption
byte[] key = new byte[16];
RandomNumberGenerator.Fill(key);

byte[] nonce = new byte[12];

RandomNumberGenerator.Fill(nonce);

// normally this would be your data

byte[] dataToEncrypt = new byte[1234];
byte[] associatedData = new byte[333];
RandomNumberGenerator.Fill(dataToEncrypt);
RandomNumberGenerator.Fill(associatedData);

// these will be filled during the encryption

byte[] tag = new byte[16];
byte[] ciphertext = new byte[dataToEncrypt.Length];

using (AesGcm aesGcm = new AesGcm(key))

{
aesGcm.Encrypt(nonce, dataToEncrypt, ciphertext, tag, associatedData);
}

// tag, nonce, ciphertext, associatedData should be sent to the other part

byte[] decryptedData = new byte[ciphertext.Length];

using (AesGcm aesGcm = new AesGcm(key))

{
aesGcm.Decrypt(nonce, ciphertext, tag, decryptedData, associatedData);
}

// do something with the data

// this should always print that data is the same
Console.WriteLine($"AES-GCM: Decrypted data is {(dataToEncrypt.SequenceEqual(decryptedData) ? "the
same as" : "different than")} original data.");
}
}
}

Importación y exportación de claves criptográfica

.NET Core 3.0 admite la importación y exportación de claves asimétricas públicas y privadas en formatos estándar.
No es necesario utilizar un certificado X.509.
Todos los tipos de clave, como RSA, DSA, ECDsa y ECDiffieHellman, admiten los siguientes formatos:
Clave pública
SubjectPublicKeyInfo X.509
Clave privada
PrivateKeyInfo PKCS#8
EncryptedPrivateKeyInfo PKCS#8
Las claves RSA también admiten:
 Clave pública
RSAPublicKey PKCS#1
Clave privada
RSAPrivateKey PKCS#1
Los métodos de exportación generan datos binarios con codificación DER y los métodos de importación esperan lo
mismo. Si una clave se almacena en el formato PEM de texto descriptivo, el llamador debe descodificar en base64
el contenido antes de llamar a un método de importación.

using System;
using System.Security.Cryptography;

namespace whats_new
{
public static class RSATest
{
public static void Run(string keyFile)
{
using var rsa = RSA.Create();

byte[] keyBytes = System.IO.File.ReadAllBytes(keyFile);

rsa.ImportRSAPrivateKey(keyBytes, out int bytesRead);

Console.WriteLine($"Read {bytesRead} bytes, {keyBytes.Length - bytesRead} extra byte(s) in file.");

RSAParameters rsaParameters = rsa.ExportParameters(true);
Console.WriteLine(BitConverter.ToString(rsaParameters.D));
}
}
}

Los archivos PKCS#8 se pueden inspeccionar con System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo y los

archivos PFX/PKCS#12 se pueden inspeccionar con System.Security.Cryptography.Pkcs.Pkcs12Info. Los archivos
PFX/PKCS#12 se pueden manipular con System.Security.Cryptography.Pkcs.Pkcs12Builder.

Cambios de API en .NET Core 3.0

Rangos e índices
El nuevo tipo System.Index se puede utilizar para la indización. Puede crear uno desde un índice int que cuente
desde el principio o con un operador ^ de prefijo (C#) que cuente desde el final:

Index i1 = 3; // number 3 from beginning

Index i2 = ^4; // number 4 from end
int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
Console.WriteLine($"{a[i1]}, {a[i2]}"); // "3, 6"

Existe también el tipo System.Range, que consta de dos valores Index , uno para el inicio y otro para el final, y se
puede escribir con una expresión de intervalo x..y (C#). Luego puede crear un índice con un Range , lo que
genera un segmento:

var slice = a[i1..i2]; // { 3, 4, 5 }

Para obtener más información, vea el tutorial sobre intervalos e índices.

Flujos asincrónicos
El tipo IAsyncEnumerable<T> es una nueva versión asincrónica de IEnumerable<T>. El lenguaje permite ejecutar la
instrucción await foreach en IAsyncEnumerable<T> para consumir sus elementos, y usar la instrucción
yield return en ellos para generar los elementos.
En el ejemplo siguiente se muestra la producción y el consumo de flujos asincrónicos. La instrucción foreach es
asincrónica y usa yield return para generar un flujo asincrónico para los llamadores. Este patrón (que usa
yield return ) es el modelo recomendado para generar flujos asincrónicos.

async IAsyncEnumerable<int> GetBigResultsAsync()

{
await foreach (var result in GetResultsAsync())
{
if (result > 20) yield return result;
}
}

Además de poder ejecutar await foreach , también puede crear iteradores asincrónicos, por ejemplo, uno que
devuelva un enumerador IAsyncEnumerable/IAsyncEnumerator en el que pueda ejecutar await y yield . Para los
objetos que deban eliminarse, puede usar IAsyncDisposable , que implementan varios tipos BCL, como Stream y
Timer .

Para obtener más información, vea el tutorial sobre flujos asincrónicos.

Punto flotante de IEEE
Las API de punto flotante se actualizan para cumplir con la revisión IEEE 754-2008. El objetivo de estos cambios es
exponer todas operaciones requeridas y asegurarse de que cumplen con la especificación IEEE. Para obtener más
información sobre las mejoras de punto flotante, vea la entrada de blog sobre mejoras de formato y análisis de
punto flotante en .NET Core 3.0.
Entre las correcciones de análisis y formato se incluyen:
Analice y redondee entradas de cualquier longitud correctamente.
Analice y formatee el cero negativo correctamente.
Análisis correcto de Infinity y NaN al hacer una comprobación que no distingue mayúsculas de minúsculas y
permitir un + anterior opcional cuando corresponda.
Entre las nuevas API System.Math se incluyen:
BitIncrement(Double) y BitDecrement(Double)
Corresponde a las operaciones IEEE nextUp y nextDown . Devuelven el número de punto flotante más
pequeño que compara mayor o menor que la entrada (respectivamente). Por ejemplo,
Math.BitIncrement(0.0) devolvería double.Epsilon .

MaxMagnitude(Double, Double) y MinMagnitude(Double, Double)

Corresponde a las operaciones IEEE maxNumMag y minNumMag , que devuelven el valor que es mayor o menor
en magnitud de las dos entradas (respectivamente). Por ejemplo, Math.MaxMagnitude(2.0, -3.0) devolvería
-3.0 .

ILogB(Double)
Corresponde a la operación IEEE logB que devuelve un valor entero, devuelve el logaritmo en base 2
integral del parámetro de entrada. Este método es efectivamente el mismo que floor(log2(x)) , pero con
errores de redondeo mínimo.
ScaleB(Double, Int32)
Corresponde a la operación IEEE scaleB que toma un valor integral, devuelve eficazmente x * pow(2, n) ,
pero se realiza con errores de redondeo mínimo.
Log2(Double)
 Corresponde a la operación IEEE log2 . Devuelve el logaritmo de base 2. Minimiza el error de redondeo.
FusedMultiplyAdd(Double, Double, Double)
Corresponde a la operación IEEE fma . Realiza una multiplicación y suma fusionadas. Es decir, realiza
(x * y) + z como operación única, de forma que se minimiza el error de redondeo. Un ejemplo es
FusedMultiplyAdd(1e308, 2.0, -1e308) , que devuelve 1e308 . La operación (1e308 * 2.0) - 1e308 regular
devuelve double.PositiveInfinity .
CopySign(Double, Double)
Corresponde a la operación IEEE copySign . Devuelve el valor de x , pero con el signo de y .
Elementos intrínsecos dependientes de la plataforma .NET
Se han agregado API que permiten el acceso a determinadas instrucciones CPU orientadas al rendimiento, como
los conjuntos de instrucciones de manipulación de bits o SIMD . Estas instrucciones pueden ayudar a
conseguir importantes mejoras de rendimiento en ciertos escenarios, como el procesamiento de datos con
eficiencia en paralelo.
En su caso, las bibliotecas de .NET han comenzado a utilizar estas instrucciones para mejorar el rendimiento.
Para obtener más información, consulte el artículo sobre elementos intrínsecos dependientes de la plataforma .NET.
API de versión mejoradas de .NET Core
A partir de .NET Core 3.0, las API de versión incluidas con .NET Core ahora devuelven la información que se espera.
Por ejemplo:

System.Console.WriteLine($"Environment.Version: {System.Environment.Version}");

// Old result
// Environment.Version: 4.0.30319.42000
//
// New result
// Environment.Version: 3.0.0

System.Console.WriteLine($"RuntimeInformation.FrameworkDescription:
{System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");

// Old result
// RuntimeInformation.FrameworkDescription: .NET Core 4.6.27415.71
//
// New result (notice the value includes any preview release information)
// RuntimeInformation.FrameworkDescription: .NET Core 3.0.0-preview4-27615-11

WARNING
Cambio importante. Se trata técnicamente de un cambio importante, porque ha cambiado el esquema de control de
versiones.

Compatibilidad con JSON integrada con rápido rendimiento

Los usuarios de .NET se han basado en gran medida en Newtonsoft.Json y otras bibliotecas populares de JSON,
que siguen siendo buenas opciones. Newtonsoft.Json usa cadenas de .NET como tipo de datos base, que, en
esencia, es UTF-16.
La nueva compatibilidad integrada con JSON es de alto rendimiento, baja asignación y funciona con texto JSON
codificado UTF-8. Para obtener más información sobre el espacio de nombres System.Text.Json y los tipos, vea los
artículos siguientes:
 Serialización JSON en .NET: información general
En Procedimiento para serializar y deserializar JSON en .NET
Migración desde Newtonsoft.json a System.Text.Json
Compatibilidad con HTTP/2
El tipo System.Net.Http.HttpClient es compatible con el protocolo HTTP/2. Si se habilita HTTP/2, la versión del
protocolo HTTP se negocia a través de TLS/ALPN y HTTP/2 solo se usa si el servidor opta por usarlo.
El protocolo predeterminado sigue siendo HTTP/1.1, pero se puede habilitar HTTP/2 de dos maneras diferentes. En
primer lugar, puede establecer el mensaje de solicitud HTTP para usar HTTP/2:

var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };

// HTTP/1.1 request
using (var response = await client.GetAsync("/"))
Console.WriteLine(response.Content);

// HTTP/2 request
using (var request = new HttpRequestMessage(HttpMethod.Get, "/") { Version = new Version(2, 0) })
using (var response = await client.SendAsync(request))
Console.WriteLine(response.Content);

En segundo lugar, puede cambiar HttpClient para usar HTTP/2 de forma predeterminada:

var client = new HttpClient()

{
BaseAddress = new Uri("https://localhost:5001"),
DefaultRequestVersion = new Version(2, 0)
};

// HTTP/2 is default
using (var response = await client.GetAsync("/"))
Console.WriteLine(response.Content);

Muchas veces cuando está desarrollando una aplicación, desea utilizar una conexión no cifrada. Si sabe que el
punto de conexión de destino utilizará HTTP/2, puede activar las conexiones no cifradas para HTTP/2. Puede
activarlas estableciendo la variable de entorno DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT
en 1 o habilitándolas en el contexto de la aplicación:

AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);

Pasos siguientes
Revise los cambios importantes entre .NET Core 2.2 y 3.0.
Revise los cambios importantes de .NET Core 3.0 para aplicaciones de Windows Forms.
 Cambios importantes en .NET Core 3.0
18/12/2020 • 147 minutes to read • Edit Online

Si va a migrar a la versión 3.0 de .NET Core, ASP.NET Core o EF Core, es posible que los cambios importantes de este artículo afecten a la aplicación.

ASP.NET Core
Se han quitado las API Antiforgery, CORS, Diagnostics, MVC y Routing obsoletas
API "Pubternal" quitadas
Autenticación: Google+ en desuso
Autenticación: se ha quitado la propiedad HttpContext.Authentication
Autenticación: se han reemplazado los tipos Newtonsoft.Json
Autenticación: se ha cambiado la firma ExchangeCodeAsync de OAuthHandler
Autorización: la sobrecarga de AddAuthorization se ha movido a otro ensamblado
Autorización: se ha quitado IAllowAnonymous de AuthorizationFilterContext.Filters
Autorización: las implementaciones de IAuthorizationPolicyProvider requieren un método nuevo
Almacenamiento en caché: se ha quitado la propiedad CompactOnMemoryPressure
Almacenamiento en caché: Microsoft.Extensions.Caching.SqlServer usa el paquete nuevo SqlClient
Almacenamiento en caché: los tipos "pubternal" de ResponseCaching se han cambiado a internal
Protección de datos: uso de nuevas API de Azure Storage por parte de DataProtection.Blobs
Hospedaje: se ha quitado AspNetCoreModule V1 del conjunto de hospedaje de Windows
Hospedaje: el host genérico restringe la inserción del constructor de Startup
Hospedaje: redireccionamiento de HTTPS habilitado para aplicaciones fuera de proceso de IIS
Hospedaje: se han reemplazado los tipos IHostingEnvironment e IApplicationLifetime
Hospedaje: se ha quitado ObjectPoolProvider de las dependencias de WebHostBuilder
HTTP: se ha quitado la extensibilidad de DefaultHttpContext
HTTP: los campos HeaderNames se han cambiado a static readonly
HTTP: cambios en la infraestructura del cuerpo de respuesta
HTTP: se han cambiado algunos valores predeterminados de cookie de SameSite
HTTP: se ha deshabilitado la E/S sincrónica de forma predeterminada
Identidad: se ha quitado la sobrecarga del método AddDefaultUI
Identidad: cambio de versión de arranque de IU
Identidad: SignInAsync produce una excepción para la identidad no autenticada
Identidad: el constructor SignInManager acepta un nuevo parámetro
Identidad: la interfaz de usuario usa la característica de recursos web estáticos
Kestrel: se han quitado los adaptadores de conexión
Kestrel: se ha quitado un ensamblado HTTPS vacío
Kestrel: se han movido los encabezados de finalizador de solicitud a una nueva recopilación
Kestrel: cambios en la capa de abstracción de transporte
Localización: API marcadas como obsoletas
Registro: la clase DebugLogger se ha convertido en interna
MVC: se ha quitado el sufijo Async de acción de controlador
MVC: JsonResult se ha trasladado a Microsoft.AspNetCore.Mvc.Core
MVC: herramienta de precompilación en desuso
MVC: los tipos se han cambiado a internal
MVC: se han quitado las correcciones de compatibilidad (shim) con la API web
Razor: API RazorTemplateEngine eliminada
Razor: la compilación en tiempo de ejecución se ha movido a un paquete
Estado de sesión: se han quitado las API obsoletas
Marco compartido: eliminación de ensamblados de Microsoft.AspNetCore.App
Marco compartido: se ha eliminado Microsoft.AspNetCore.All
SignalR: se ha reemplazado HandshakeProtocol.SuccessHandshakeData
SignalR: se han quitado métodos de HubConnection
SignalR: se han cambiado los constructores de HubConnectionContext
SignalR: se ha cambiado el nombre del paquete de cliente de JavaScript
SignalR: API obsoletas
SPA: SpaServices y NodeServices se han marcado como obsoletos
SPA: cambio predeterminado de reserva de registrador de consola de SpaServices y NodeServices
Marco de destino: no se admite .NET Framework
Se han quitado las API Antiforgery, CORS, Diagnostics, MVC y Routing obsoletas
Se han quitado los miembros obsoletos y los modificadores de compatibilidad en ASP.NET Core 2.2.
Versión introducida
3.0
Motivo del cambio
Mejora de la superficie de API a lo largo del tiempo.
Acción recomendada
Aunque el destino es .NET Core 2,2, siga la guía de los mensajes de compilación obsoletos para adoptar nuevas API en su lugar.
Categoría
ASP.NET Core
API afectadas
Los tipos y miembros siguientes se marcaron como obsoletos para ASP.NET Core 2.1 y 2.2:
Tipos
Microsoft.AspNetCore.Diagnostics.Views.WelcomePage
Microsoft.AspNetCore.DiagnosticsViewPage.Views.AttributeValue
Microsoft.AspNetCore.DiagnosticsViewPage.Views.BaseView
Microsoft.AspNetCore.DiagnosticsViewPage.Views.HelperResult
Microsoft.AspNetCore.Mvc.Formatters.Xml.ProblemDetails21Wrapper
Microsoft.AspNetCore.Mvc.Formatters.Xml.ValidationProblemDetails21Wrapper
Microsoft.AspNetCore.Mvc.Razor.Compilation.ViewsFeatureProvider
Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageArgumentBinder
Microsoft.AspNetCore.Routing.IRouteValuesAddressMetadata
Microsoft.AspNetCore.Routing.RouteValuesAddressMetadata

Constructores
Microsoft.AspNetCore.Cors.Infrastructure.CorsService(IOptions{CorsOptions})
Microsoft.AspNetCore.Routing.Tree.TreeRouteBuilder(ILoggerFactory,UrlEncoder,ObjectPool{UriBuildingContext},IInlineConstraintResolver)
Microsoft.AspNetCore.Mvc.Formatters.OutputFormatterCanWriteContext
Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider)

Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider,IActionResultTypeMapper)
Microsoft.AspNetCore.Mvc.Formatters.FormatFilter(IOptions{MvcOptions})
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ArrayModelBinder`1(IModelBinder)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ByteArrayModelBinder
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.CollectionModelBinder`1(IModelBinder)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder(IDictionary`2)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DictionaryModelBinder`2(IModelBinder,IModelBinder)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder(System.Globalization.NumberStyles)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder(System.Globalization.NumberStyles)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder`2(IModelBinder,IModelBinder)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder(System.Type)
Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object})
Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object},IEnumerable{System.Object})
Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory(IModelMetadataProvider,IOptions{MvcOptions})
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder(IModelMetadataProvider,IModelBinderFactory,IObjectModelValidator)
Microsoft.AspNetCore.Mvc.Routing.KnownRouteValueConstraint()
Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter
Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)
Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)
Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter
Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(System.Boolean)
Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(MvcOptions)
Microsoft.AspNetCore.Mvc.TagHelpers.ImageTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,IUrlHelperFactory)
Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter(RazorPageBase)

Propiedades
 Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieDomain
Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieName
Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookiePath
Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.RequireSsl
Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.AllowInferringBindingSourceForCollectionTypesAsFromQuery
Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressUseValidationProblemDetailsForInvalidModelStateResponses
Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.CookieName
Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Domain
Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Path
Microsoft.AspNetCore.Mvc.DataAnnotations.MvcDataAnnotationsLocalizationOptions.AllowDataAnnotationsLocalizationForEnumDisplayAttributes
Microsoft.AspNetCore.Mvc.Formatters.Xml.MvcXmlOptions.AllowRfc7807CompliantProblemDetailsFormat
Microsoft.AspNetCore.Mvc.MvcOptions.AllowBindingHeaderValuesToNonStringModelTypes
Microsoft.AspNetCore.Mvc.MvcOptions.AllowCombiningAuthorizeFilters
Microsoft.AspNetCore.Mvc.MvcOptions.AllowShortCircuitingValidationWhenNoValidatorsArePresent
Microsoft.AspNetCore.Mvc.MvcOptions.AllowValidatingTopLevelNodes
Microsoft.AspNetCore.Mvc.MvcOptions.InputFormatterExceptionPolicy
Microsoft.AspNetCore.Mvc.MvcOptions.SuppressBindingUndefinedValueToEnumType
Microsoft.AspNetCore.Mvc.MvcViewOptions.AllowRenderingMaxLengthAttribute
Microsoft.AspNetCore.Mvc.MvcViewOptions.SuppressTempDataAttributePrefix
Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowAreas
Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowDefaultHandlingForOptionsRequests
Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowMappingHeadRequestsToGetHandler

Métodos
Microsoft.AspNetCore.Mvc.LocalRedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToActionResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToPageResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToRouteResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor,Object)

API "Pubternal" quitadas

Para mantener mejor la superficie de la API pública de ASP.NET Core, la mayoría de los tipos de los espacios de nombres *.Internal (conocidos como API
"pubternal") se han vuelto realmente internos. Los miembros de estos espacios de nombres nunca debían admitirse como API de acceso público. Las API
podían dividirse en versiones secundarias y con frecuencia lo hacían. El código que depende de estas API se divide cuando se actualiza a ASP.NET Core 3.0.
Para más información, consulte dotnet/aspnetcore#4932 y dotnet/aspnetcore#11312.
Versión introducida
3.0
Comportamiento anterior
Las API afectadas se marcan con el modificador de acceso public y existen en los espacios de nombres *.Internal .
Comportamiento nuevo
Las API afectadas se marcan con el modificador de acceso internal y ya no se pueden usar en el código fuera de ese ensamblado.
Motivo del cambio
Las instrucciones para estas API de "pubternal" eran las siguientes:
Podían cambiar sin previo aviso.
No estaban sujetas a las directivas de .NET para evitar cambios importantes.
La salida de las API public (incluso en los espacios de nombres de *.Internal ) era confusa para los clientes.
Acción recomendada
Deje de usar estas API "pubternal". Si tiene alguna pregunta sobre API alternativas, abra una incidencia en el repositorio dotnet/aspnetcore.
Por ejemplo, considere el siguiente código de almacenamiento en búfer de solicitudes HTTP en un proyecto ASP.NET Core 2.2. El método de extensión
EnableRewind existe en el espacio de nombres Microsoft.AspNetCore.Http.Internal .

HttpContext.Request.EnableRewind();

En un proyecto ASP.NET Core 3.0, reemplace la llamada EnableRewind por una llamada al método de extensión EnableBuffering . La característica de
almacenamiento en búfer de solicitudes funciona igual que lo hacía antes. EnableBuffering llama a la API internal ahora.
 HttpContext.Request.EnableBuffering();

Categoría
ASP.NET Core
API afectadas
Todas las API de los espacios de nombres Microsoft.AspNetCore.* y Microsoft.Extensions.* que tienen un segmento Internal en el nombre del espacio
de nombres. Por ejemplo:
Microsoft.AspNetCore.Authentication.Internal
Microsoft.AspNetCore.Builder.Internal
Microsoft.AspNetCore.DataProtection.Cng.Internal
Microsoft.AspNetCore.DataProtection.Internal
Microsoft.AspNetCore.Hosting.Internal
Microsoft.AspNetCore.Http.Internal
Microsoft.AspNetCore.Mvc.Core.Infrastructure
Microsoft.AspNetCore.Mvc.Core.Internal
Microsoft.AspNetCore.Mvc.Cors.Internal
Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
Microsoft.AspNetCore.Mvc.Formatters.Internal
Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
Microsoft.AspNetCore.Mvc.Internal
Microsoft.AspNetCore.Mvc.ModelBinding.Internal
Microsoft.AspNetCore.Mvc.Razor.Internal
Microsoft.AspNetCore.Mvc.RazorPages.Internal
Microsoft.AspNetCore.Mvc.TagHelpers.Internal
Microsoft.AspNetCore.Mvc.ViewFeatures.Internal
Microsoft.AspNetCore.Rewrite.Internal
Microsoft.AspNetCore.Routing.Internal
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure
Microsoft.AspNetCore.Server.Kestrel.Https.Internal

**
Autenticación: Google+ se ha dejado en desuso y se ha reemplazado
Google está empezando a apagar el inicio de sesión de Google+ en las aplicaciones a partir del 28 de enero de 2019.
Descripción del cambio
ASP.NET 4.x y ASP.NET Core han estado usando las API de inicio de sesión de Google+ para autenticar a los usuarios de cuentas de Google en las
aplicaciones web. Los paquetes NuGet afectados son Microsoft.AspNetCore.Authentication.Google para ASP.NET Core y Microsoft.Owin.Security.Google
para Microsoft.Owin con ASP.NET Web Forms y MVC.
Las API de reemplazo de Google utilizan un formato y un origen de datos distintos. Las mitigaciones y soluciones que se proporcionan a continuación
tienen en cuenta los cambios estructurales. Las aplicaciones deben comprobar que los datos en sí cumplen sus requisitos. Por ejemplo, los nombres, las
direcciones de correo electrónico, los vínculos de perfil y las fotos de perfil pueden proporcionar valores ligeramente distintos a los anteriores.
Versión introducida
Todas las versiones. Este cambio es externo a ASP.NET Core.
Acción recomendada
O w i n c o n A SP.N E T W e b F o r m s y M V C

En el caso de Microsoft.Owin 3.1.0 y versiones posteriores, se describe una mitigación temporal aquí. Las aplicaciones deben completar las pruebas con la
mitigación para comprobar si hay cambios en el formato de datos. Existen planes para lanzar Microsoft.Owin 4.0.1 con una corrección. Las aplicaciones que
usen cualquier versión anterior deben actualizarse a la versión 4.0.1.
A SP.N E T C o r e 1 .x

La mitigación en Owin con ASP.NET Web Forms y MVC puede adaptarse a ASP.NET Core 1.x. Las revisiones del paquete NuGet no están planeadas porque
1.x ha alcanzado el estado final del ciclo de vida.
A SP.N E T C o r e 2 .x

En el caso la versión 2.x de Microsoft.AspNetCore.Authentication.Google , reemplace la llamada existente a AddGoogle en Startup.ConfigureServices por el
código siguiente:
 .AddGoogle(o =>
{
o.ClientId = Configuration["Authentication:Google:ClientId"];
o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
o.UserInformationEndpoint = "https://www.googleapis.com/oauth2/v2/userinfo";
o.ClaimActions.Clear();
o.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "id");
o.ClaimActions.MapJsonKey(ClaimTypes.Name, "name");
o.ClaimActions.MapJsonKey(ClaimTypes.GivenName, "given_name");
o.ClaimActions.MapJsonKey(ClaimTypes.Surname, "family_name");
o.ClaimActions.MapJsonKey("urn:google:profile", "link");
o.ClaimActions.MapJsonKey(ClaimTypes.Email, "email");
});

Las revisiones 2.1 y 2.2 de febrero incorporaron la reconfiguración anterior como el nuevo valor predeterminado. No hay ninguna revisión planeada para
ASP.NET Core 2.0 porque ha alcanzado el final del ciclo de vida.
A SP.N E T C o r e 3 .0

La mitigación proporcionada para ASP.NET Core 2.x también puede usarse para ASP.NET Core 3.0. En versiones preliminares futuras de la versión 3.0, se
puede quitar el paquete Microsoft.AspNetCore.Authentication.Google . A los usuarios se les dirigirá a Microsoft.AspNetCore.Authentication.OpenIdConnect en
su lugar. El código siguiente muestra cómo reemplazar AddGoogle por AddOpenIdConnect en Startup.ConfigureServices . Este reemplazo se puede usar con
ASP.NET Core 2.0 y versiones posteriores, y se puede adaptar para ASP.NET Core 1.x, según sea necesario.

.AddOpenIdConnect("Google", o =>
{
o.ClientId = Configuration["Authentication:Google:ClientId"];
o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
o.Authority = "https://accounts.google.com";
o.ResponseType = OpenIdConnectResponseType.Code;
o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Authentication.Google
*
Autenticación: se ha quitado la propiedad HttpContext.Authentication
La propiedad Authentication en desuso se ha quitado en HttpContext .
Descripción del cambio
Como parte de dotnet/aspnetcore#6504, la propiedad Authentication en desuso se ha quitado en HttpContext . La propiedad Authentication se ha
dejado en desuso desde la versión 2.0. Se ha publicado una guía de migración para migrar código con esta propiedad en desuso a las nuevas API de
reemplazo. Las clases o API restantes no utilizadas relacionadas con la pila de autenticación antigua ASP.NET Core 1.x se han quitado en la confirmación
dotnet/aspnetcore@d7a7c65.
Para obtener información, vea dotnet/aspnetcore#6533.
Versión introducida
3.0
Motivo del cambio
Las API de ASP.NET Core 1.0 se han reemplazado por métodos de extensión en Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.
Acción recomendada
Consulte la guía de migración.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Http.Authentication.AuthenticateInfo
Microsoft.AspNetCore.Http.Authentication.AuthenticationManager
Microsoft.AspNetCore.Http.Authentication.AuthenticationProperties
Microsoft.AspNetCore.Http.Features.Authentication.AuthenticateContext
Microsoft.AspNetCore.Http.Features.Authentication.ChallengeBehavior
Microsoft.AspNetCore.Http.Features.Authentication.ChallengeContext
Microsoft.AspNetCore.Http.Features.Authentication.DescribeSchemesContext
Microsoft.AspNetCore.Http.Features.Authentication.IAuthenticationHandler
Microsoft.AspNetCore.Http.Features.Authentication.IHttpAuthenticationFeature.Handler
Microsoft.AspNetCore.Http.Features.Authentication.SignInContext
Microsoft.AspNetCore.Http.Features.Authentication.SignOutContext
Microsoft.AspNetCore.Http.HttpContext.Authentication
*
Autenticación: se han reemplazado los tipos Newtonsoft.Json
En ASP.NET Core 3.0, los tipos de Newtonsoft.Json utilizados en las API de autenticación se han reemplazado por tipos de System.Text.Json . Excepto en los
casos siguientes, el uso básico de los paquetes de autenticación no se ve afectado:
Clases que se derivan de los proveedores de OAuth, como las de aspnet-contrib.
Implementaciones avanzadas de manipulación de notificaciones.
Para obtener más información, consulte dotnet/aspnetcore#7105. Para obtener información, vea dotnet/aspnetcore#7289.
Versión introducida
3.0
Acción recomendada
En el caso de las implementaciones de OAuth derivadas, el cambio más común es reemplazar JObject.Parse por JsonDocument.Parse en la invalidación
CreateTicketAsync , tal como se muestra aquí. JsonDocument implementa IDisposable .

En la lista siguiente se describen los cambios conocidos:

ClaimAction.Run(JObject, ClaimsIdentity, String) se convierte en ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer) . Todas
las implementaciones derivadas de ClaimAction se ven afectadas de manera similar.
ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, Func<JObject,String>) se convierte en
MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver) .
ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, String, Func<JObject,String>) se convierte en
MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver) .
Ha habido un constructor anterior de OAuthCreatingTicketContext que se ha quitado y otro que ha reemplazado JObject por JsonElement . La
propiedad User y el método RunClaimActions se han actualizado para que coincidan.
Success(JObject) ahora acepta un parámetro de tipo JsonDocument en lugar de JObject . La propiedad Response se ha actualizado para que coincida.
OAuthTokenResponse ahora es descartable y se eliminará mediante OAuthHandler . Las implementaciones de OAuth derivadas que invalidan
ExchangeCodeAsync no necesitan desechar JsonDocument o OAuthTokenResponse .
UserInformationReceivedContext.User ha cambiado de JObject a JsonDocument .
TwitterCreatingTicketContext.User ha cambiado de JObject a JsonElement .
El último parámetro de TwitterHandler.CreateTicketAsync(ClaimsIdentity,AuthenticationProperties,AccessToken,JObject) se ha cambiado de JObject a
JsonElement . El método de reemplazo es TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).

Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Authentication.Facebook
Microsoft.AspNetCore.Authentication.Google
Microsoft.AspNetCore.Authentication.MicrosoftAccount
Microsoft.AspNetCore.Authentication.OAuth
Microsoft.AspNetCore.Authentication.OpenIdConnect
Microsoft.AspNetCore.Authentication.Twitter
*
Autenticación: se ha cambiado la firma ExchangeCodeAsync de OAuthHandler
En ASP.NET Core 3.0, la firma de OAuthHandler.ExchangeCodeAsync cambió de:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string

redirectUri) { throw null; }

A:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse>

ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }

Versión introducida
3.0
Comportamiento anterior
Las cadenas code y redirectUri se pasaron como argumentos independientes.
Comportamiento nuevo
Code y RedirectUri son propiedades de OAuthCodeExchangeContext que se pueden establecer mediante el constructor de OAuthCodeExchangeContext . El
nuevo tipo de OAuthCodeExchangeContext es el único argumento que se pasa a OAuthHandler.ExchangeCodeAsync .
Motivo del cambio
Este cambio permite proporcionar parámetros adicionales de forma no interrumpida. No es necesario crear sobrecargas nuevas de ExchangeCodeAsync .
Acción recomendada
Construya un elemento OAuthCodeExchangeContext con los valores adecuados de code y redirectUri . Se debe proporcionar una instancia de
AuthenticationProperties. Esta instancia de OAuthCodeExchangeContext única se puede pasar a OAuthHandler.ExchangeCodeAsync en lugar de varios
argumentos.
Categoría
ASP.NET Core
API afectadas
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
*
Autorización: la sobrecarga de AddAuthorization se ha cambiado a otro ensamblado
Se ha cambiado a AddAuthorizationCore el nombre de los métodos AddAuthorization principales que antes se encontraban en
Microsoft.AspNetCore.Authorization . Los métodos AddAuthorization antiguos todavía existen, pero ahora se encuentran en el ensamblado
Microsoft.AspNetCore.Authorization.Policy . Las aplicaciones en las que se usen ambos métodos no se verán afectadas. Tenga en cuenta que
Microsoft.AspNetCore.Authorization.Policy ahora se incluye en el marco compartido en lugar de en un paquete independiente, tal como se describe en
Marco compartido: se han quitado los ensamblados de Microsoft.AspNetCore.App.
Versión introducida
3.0
Comportamiento anterior
Los métodos AddAuthorization existían en Microsoft.AspNetCore.Authorization .
Comportamiento nuevo
Los métodos AddAuthorization existen en Microsoft.AspNetCore.Authorization.Policy . AddAuthorizationCore es el nuevo nombre de los métodos antiguos.
Motivo del cambio
AddAuthorization es un nombre de método más indicado para agregar todos los servicios comunes necesarios para la autorización.
Acción recomendada
Agregue una referencia a Microsoft.AspNetCore.Authorization.Policy o, en su lugar, use AddAuthorizationCore .
Categoría
ASP.NET Core
API afectadas
Microsoft.Extensions.DependencyInjection.AuthorizationServiceCollectionExtensions.AddAuthorization(IServiceCollection, Action<AuthorizationOptions>)
*
Autorización: IAllowAnonymous se quitó de AuthorizationFilterContext.Filters
A partir de ASP.NET Core 3.0, MVC no agrega AllowAnonymousFilters para los atributos [AllowAnonymous] que se detectaron en los controladores y
métodos de acción. Este cambio se dirige localmente para los derivados de AuthorizeAttribute, pero es un cambio importante en las implementaciones de
IAsyncAuthorizationFilter y IAuthorizationFilter. Estas implementaciones contenidas en un atributo [TypeFilter] son una conocidas y compatibles para lograr
la autorización basada en atributos fuertemente tipados cuando se requieren tanto la configuración como la inserción de dependencias.
Versión introducida
3.0
Comportamiento anterior
IAllowAnonymous aparecía en la colección AuthorizationFilterContext.Filters. La prueba de la presencia de la interfaz era un enfoque válido para invalidar o
deshabilitar el filtro en métodos de controlador individuales.
Comportamiento nuevo
IAllowAnonymous ya no aparece en la colección AuthorizationFilterContext.Filters . Las implementaciones IAsyncAuthorizationFilter que dependen del
comportamiento anterior normalmente producen respuestas intermitentes HTTP 401 no autorizadas o HTTP 403 prohibidas.
Motivo del cambio
Se presentó una nueva estrategia de enrutamiento de puntos de conexión en ASP.NET Core 3.0.
Acción recomendada
Busque IAllowAnonymous en los metadatos del punto de conexión. Por ejemplo:

var endpoint = context.HttpContext.GetEndpoint();

if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}

Un ejemplo de esta técnica se encuentra en este método HasAllowAnonymous.

Categoría
ASP.NET Core
API afectadas
None
*
Autorización: las implementaciones de IAuthorizationPolicyProvider requieren un método nuevo
En ASP.NET Core 3.0, se ha agregado un nuevo método GetFallbackPolicyAsync a IAuthorizationPolicyProvider . El middleware de autorización usa esta
directiva de reserva cuando no se especifica ninguna directiva.
Para obtener más información, consulte dotnet/aspnetcore#9759.
Versión introducida
3.0
Comportamiento anterior
Las implementaciones de IAuthorizationPolicyProvider no requerían un método GetFallbackPolicyAsync .
Comportamiento nuevo
Las implementaciones de IAuthorizationPolicyProvider requieren un método GetFallbackPolicyAsync .
Motivo del cambio
Se necesitaba un nuevo método para que el nuevo AuthorizationMiddleware lo usara cuando no se especificara ninguna directiva.
Acción recomendada
Agregue el método GetFallbackPolicyAsync a las implementaciones de IAuthorizationPolicyProvider .
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
*
Almacenamiento en caché: se ha quitado la propiedad CompactOnMemoryPressure
En la versión ASP.NET Core 3.0 se han quitado las API MemoryCacheOptions obsoletas.
Descripción del cambio
Este cambio es una continuación de aspnet/Caching#221. Para obtener información, vea dotnet/extensions#1062.
Versión introducida
3.0
Comportamiento anterior
La propiedad MemoryCacheOptions.CompactOnMemoryPressure estaba disponible.
Comportamiento nuevo
Se ha quitado la propiedad MemoryCacheOptions.CompactOnMemoryPressure .
Motivo del cambio
La compactación automática de la caché provocaba problemas. Para evitar un comportamiento inesperado, solo se debe compactar la caché cuando sea
necesario.
Acción recomendada
Para compactar la caché, realice la conversión a un tipo heredado MemoryCache y llame a Compact cuando sea necesario.
Categoría
ASP.NET Core
API afectadas
MemoryCacheOptions.CompactOnMemoryPressure
*
Almacenamiento en caché: Microsoft.Extensions.Caching.SqlServer usa el paquete nuevo SqlClient
El paquete Microsoft.Extensions.Caching.SqlServer usará el paquete nuevo Microsoft.Data.SqlClient en lugar del System.Data.SqlClient . Este cambio
podría producir pequeños cambios en el comportamiento. Para obtener más información, vea Introducción al nuevo Microsoft.Data.SqlClient.
Versión introducida
3.0
Comportamiento anterior
El paquete Microsoft.Extensions.Caching.SqlServer usaba el paquete System.Data.SqlClient .
Comportamiento nuevo
Microsoft.Extensions.Caching.SqlServer ahora usa el paquete Microsoft.Data.SqlClient .
Motivo del cambio
Microsoft.Data.SqlClient es un nuevo paquete que se ha creado a partir de System.Data.SqlClient . A partir de ahora, aquí es donde se realizará todo el
trabajo de las nuevas características.
Acción recomendada
Los clientes no deben preocuparse por este cambio importante, a menos que usaran los tipos que devolvía el paquete
Microsoft.Extensions.Caching.SqlServer y los convirtieran en tipos de System.Data.SqlClient . Por ejemplo, si algún usuario estuviera convirtiendo un
elemento DbConnection al tipo de SqlConnection anterior, tendría que cambiar la conversión al nuevo tipo de Microsoft.Data.SqlClient.SqlConnection .
Categoría
ASP.NET Core
API afectadas
None
*
Almacenamiento en caché: los tipos de ResponseCaching "pubternal" se han cambiado a internal
En ASP.NET Core 3.0, los tipos "pubternal" de ResponseCaching han cambiado a internal .
Además, las implementaciones predeterminadas de IResponseCachingPolicyProvider y IResponseCachingKeyProvider ya no se agregan a los servicios como
parte del método AddResponseCaching .
Descripción del cambio
In ASP.NET Core, los tipos "pubternal" se declaran como public pero residen en un espacio de nombres con un sufijo .Internal . Aunque estos tipos son
públicos, no tienen ninguna directiva compatible y están sujetos a cambios importantes. Desafortunadamente, el uso accidental de estos tipos es habitual,
lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.
Versión introducida
3.0
Comportamiento anterior
Estos tipos eran visibles públicamente, pero no eran compatibles.
Comportamiento nuevo
Estos tipos ahora son internal .
Motivo del cambio
El ámbito de internal refleja mejor la directiva no compatible.
Acción recomendada
Copiar los tipos que usa la aplicación o biblioteca.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponse
Microsoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRules
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntry
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContext
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.ResponseCachingMiddleware(RequestDelegate,
IOptions<ResponseCachingOptions>, ILoggerFactory, IResponseCachingPolicyProvider, IResponseCache, IResponseCachingKeyProvider)
*
Protección de datos: uso de nuevas API de Azure Storage por parte de DataProtection.Blobs
Azure.Extensions.AspNetCore.DataProtection.Blobs depende de las bibliotecas de Azure Storage. Estas bibliotecas han cambiado el nombre de los
ensamblados, paquetes y espacios de nombres. A partir de ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs utiliza las nuevas API y
paquetes con prefijo Azure.Storage. .
Si tiene preguntas sobre las API de Azure Storage, utilice https://github.com/Azure/azure-storage-net. Para obtener información sobre esta incidencia,
consulte dotnet/aspnetcore#19570.
Versión introducida
3.0
Comportamiento anterior
El paquete hacía referencia al paquete NuGet WindowsAzure.Storage . El paquete hace referencia al paquete NuGet Microsoft.Azure.Storage.Blob .
Comportamiento nuevo
El paquete hace referencia al paquete NuGet Azure.Storage.Blob .
Motivo del cambio
Este cambio permite a Azure.Extensions.AspNetCore.DataProtection.Blobs migrar a los paquetes de Azure Storage recomendados.
Acción recomendada
Si todavía necesita usar las API de Azure Storage anteriores con ASP.NET Core 3.0, agregue una dependencia directa al paquete WindowsAzure.Storage o
Microsoft.Azure.Storage. Este paquete se puede instalar junto con las nuevas API de Azure.Storage .
En muchos casos, la actualización solo implica cambiar las instrucciones using para usar los espacios de nombres nuevos:
 - using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
- using Microsoft.Azure.Storage;
- using Microsoft.Azure.Storage.Blob;
+ using Azure.Storage;
+ using Azure.Storage.Blobs;

Categoría
ASP.NET Core
API afectadas
None
*
Hospedaje: AspNetCoreModule V1 se ha quitado del conjunto de hospedaje de Windows
A partir de ASP.NET Core 3.0, el conjunto de hospedaje de Windows no incluirá AspNetCoreModule (ANCM) V1.
ANCM V2 es compatible con las versiones anteriores de ANCM OutOfProcess y se recomienda para su uso con aplicaciones de ASP.NET Core 3.0.
Para obtener información, vea dotnet/aspnetcore#7095.
Versión introducida
3.0
Comportamiento anterior
ANCM V1 está incluido en el conjunto de hospedaje de Windows.
Comportamiento nuevo
ANCM V1 no está incluido en el conjunto de hospedaje de Windows.
Motivo del cambio
ANCM V2 es compatible con las versiones anteriores de ANCM OutOfProcess y se recomienda para su uso con aplicaciones de ASP.NET Core 3.0.
Acción recomendada
Use ANCM V2 con aplicaciones de ASP.NET Core 3.0.
Si se requiere ANCM V1, se puede instalar mediante el conjunto de hospedaje de Windows ASP.NET Core 2.1 o 2.2.
Este cambio interrumpirá las aplicaciones de ASP.NET Core 3.0 que:
Participen del uso de ANCM V1 con <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName> .
Tengan un archivo web.config personalizado con <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> .
Categoría
ASP.NET Core
API afectadas
None
*
Hospedaje: el host genérico restringe la inserción del constructor de Startup
Los únicos tipos que admite el host genérico para la inserción del constructor de la clase Startup son IHostEnvironment , IWebHostEnvironment e
IConfiguration . Las aplicaciones que usan WebHost no se ven afectadas.

Descripción del cambio

Antes de ASP.NET Core 3.0, se podía usar la inserción de constructores para tipos arbitrarios en el constructor de la clase Startup . En ASP.NET Core 3.0, se
ha cambiado la plataforma de la pila web a la biblioteca de host genéricos. Puede ver el cambio en el archivo Program.cs de las plantillas:
ASP.NET Core 2.x:
https://github.com/dotnet/aspnetcore/blob/5cb615fcbe8559e49042e93394008077e30454c0/src/Templating/src/Microsoft.DotNet.Web.ProjectTemplates/
content/EmptyWeb-CSharp/Program.cs#L20-L22
ASP.NET Core 3.0:
https://github.com/dotnet/aspnetcore/blob/b1ca2c1155da3920f0df5108b9fedbe82efaa11c/src/ProjectTemplates/Web.ProjectTemplates/content/EmptyWe
b-CSharp/Program.cs#L19-L24
Host usa un contenedor de inserción de dependencias (DI) para compilar la aplicación. WebHost usa dos contenedores: uno para el host y otro para la
aplicación. Como resultado, el constructor de Startup ya no admite la inserción de servicios personalizados. Solo se pueden insertar IHostEnvironment ,
IWebHostEnvironment e IConfiguration . Este cambio evita problemas de DI, como la creación duplicada de un servicio singleton.

Versión introducida
3.0
Motivo del cambio
Este cambio es consecuencia del cambio de plataforma de la pila web a la biblioteca de host genéricos.
Acción recomendada
Inserte los servicios en la firma del método Startup.Configure . Por ejemplo:
 public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)

Categoría
ASP.NET Core
API afectadas
None
*
Hospedaje: redireccionamiento de HTTPS habilitado para aplicaciones fuera de proceso de IIS
La versión 13.0.19218.0 del módulo ASP.NET Core (ANCM) para el hospedaje a través de IIS fuera de proceso habilita una característica de
redireccionamiento de HTTPS existente para aplicaciones ASP.NET Core 3.0 y 2.2.
Para obtener información, vea dotnet/AspNetCore#15243.
Versión introducida
3.0
Comportamiento anterior
La plantilla de proyecto de ASP.NET Core 2.1 incorporó por primera vez compatibilidad con métodos de middleware de HTTPS como UseHttpsRedirection y
UseHsts. La habilitación del redireccionamiento de HTTPS exigía la adición de configuración, ya que las aplicaciones en desarrollo no usan el puerto
predeterminado 443. La seguridad de transporte estricta de HTTP (HSTS) solo está activa si la solicitud ya usa HTTPS. Localhost se omite de forma
predeterminada.
Comportamiento nuevo
En ASP.NET Core 3.0, el escenario de HTTPS de IIS se ha mejorado. Con la mejora, una aplicación puede detectar los puertos HTTPS del servidor y hacer que
UseHttpsRedirection funcione de forma predeterminada. El componente en proceso ha logrado la detección de puertos con la característica
IServerAddresses , que solo afecta a las aplicaciones ASP.NET Core 3.0, dado que a la biblioteca en proceso se le asigna la versión del marco de trabajo. El
componente fuera de proceso ha cambiado para agregar automáticamente la variable de entorno ASPNETCORE_HTTPS_PORT . Este cambio afecta a las
aplicaciones ASP.NET Core 2.2 y 3.0, ya que el componente fuera de proceso se comparte de forma global. Las aplicaciones ASP.NET Core 2.1 no se ven
afectadas porque usan una versión anterior de ANCM de forma predeterminada.
El comportamiento anterior se modificó en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3) a fin de invertir los cambios de comportamiento en ASP.NET
Core 2.x. Estos cambios solo afectan a aplicaciones fuera de proceso de IIS.
Como se ha explicado anteriormente, la instalación de ASP.NET Core 3.0.0 tenía el efecto secundario de activar también el middleware de
UseHttpsRedirection en las aplicaciones ASP.NET Core 2.x. Se ha realizado un cambio en ANCM en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3) que
consiste en que su instalación ya no tiene este efecto en las aplicaciones ASP.NET Core 2.x. La variable de entorno ASPNETCORE_HTTPS_PORT que ANCM
rellenaba en ASP.NET Core 3.0.0 se ha cambiado a ASPNETCORE_ANCM_HTTPS_PORT en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3). UseHttpsRedirection
también se ha actualizado en estas versiones para comprender las variables antiguas y nuevas. ASP.NET Core 2.x no se va a actualizar. Por eso, revierte al
comportamiento anterior de estar deshabilitado de forma predeterminada.
Motivo del cambio
Funcionalidad mejorada de ASP.NET Core 3.0.
Acción recomendada
No es necesario hacer nada si se quiere que todos los clientes usen HTTPS. Para permitir que algunos clientes empleen HTTP, siga uno de los pasos
siguientes:
Quite las llamadas a UseHttpsRedirection y UseHsts del método Startup.Configure del proyecto y vuelva a implementar la aplicación.
En el archivo web.config, establezca la variable de entorno ASPNETCORE_HTTPS_PORT en una cadena vacía. Este cambio puede producirse directamente
en el servidor sin volver a implementar la aplicación. Por ejemplo:

<aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" >

<environmentVariables>
<environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" />
</environmentVariables>
</aspNetCore>

UseHttpsRedirection todavía se puede:

Activar de forma manual en ASP.NET Core 2.x al establecer la variable de entorno ASPNETCORE_HTTPS_PORT en el número de puerto correcto (443 en la
mayoría de los escenarios de producción).
Desactivar en ASP.NET Core 3.x al definir ASPNETCORE_ANCM_HTTPS_PORT con un valor de cadena vacía. Este valor se establece de la misma manera que en el
ejemplo de ASPNETCORE_HTTPS_PORT anterior.

Los equipos que ejecutan aplicaciones ASP.NET Core 3.0.0 deben instalar el runtime de ASP.NET Core 3.0.1 antes de instalar el ANCM de ASP.NET Core 3.1.0
(versión preliminar 3). De este modo se garantiza que UseHttpsRedirection siga funcionando según lo previsto para las aplicaciones ASP.NET Core 3.0.
En Azure App Service, ANCM se implementa conforme a una programación independiente del runtime debido a su naturaleza global. ANCM se
implementó en Azure con estos cambios tras la implementación de ASP.NET Core 3.0.1 y 3.1.0.
Categoría
ASP.NET Core
API afectadas
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
*
Hospedaje: los tipos IHostingEnvironment e IApplicationLifetime se han marcado como obsoletos y se han reemplazado
Se han introducido tipos nuevos para reemplazar los tipos de IHostingEnvironment y IApplicationLifetime existentes.
Versión introducida
3.0
Comportamiento anterior
Había dos tipos de IHostingEnvironment y IApplicationLifetime distintos de Microsoft.Extensions.Hosting y Microsoft.AspNetCore.Hosting .
Comportamiento nuevo
Los tipos antiguos se han marcado como obsoletos y se han reemplazado por tipos nuevos.
Motivo del cambio
Cuando se presentó en ASP.NET Core 2.1, algunos tipos como IHostingEnvironment y IApplicationLifetime se copiaron de
Microsoft.Extensions.Hosting
Microsoft.AspNetCore.Hosting . Algunos cambios de ASP.NET Core 3.0 provocan que las aplicaciones incluyan los espacios de nombres
Microsoft.Extensions.Hosting y Microsoft.AspNetCore.Hosting . Cualquier uso de estos tipos duplicados produce un error del compilador de "referencia
ambigua" cuando se hace referencia a ambos espacios de nombres.
Acción recomendada
Reemplazados los usos de los tipos anteriores por los tipos recién introducidos, como se indica a continuación:
Tipos obsoletos (adver tencia):
Microsoft.Extensions.Hosting.IHostingEnvironment
Microsoft.AspNetCore.Hosting.IHostingEnvironment
Microsoft.Extensions.Hosting.IApplicationLifetime
Microsoft.AspNetCore.Hosting.IApplicationLifetime
Microsoft.Extensions.Hosting.EnvironmentName
Microsoft.AspNetCore.Hosting.EnvironmentName
Tipos nuevos:
Microsoft.Extensions.Hosting.IHostEnvironment
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
Microsoft.Extensions.Hosting.IHostApplicationLifetime
Microsoft.Extensions.Hosting.Environments
Los nuevos métodos de extensión IsDevelopment y IsProduction de IHostEnvironment se encuentran en el espacio de nombres
Microsoft.Extensions.Hosting . Es posible que sea necesario agregar ese espacio de nombres al proyecto.

Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Hosting.EnvironmentName
Microsoft.AspNetCore.Hosting.IApplicationLifetime
Microsoft.AspNetCore.Hosting.IHostingEnvironment
Microsoft.Extensions.Hosting.EnvironmentName
Microsoft.Extensions.Hosting.IApplicationLifetime
Microsoft.Extensions.Hosting.IHostingEnvironment
*
Hospedaje: se ha quitado ObjectPoolProvider de las dependencias de WebHostBuilder
Para aumentar la naturaleza de pago por uso de ASP.NET Core, se ha quitado ObjectPoolProvider del conjunto principal de dependencias. Ahora
componentes específicos que dependen de ObjectPoolProvider lo agregan por sí mismos.
Para obtener información, vea dotnet/aspnetcore#5944.
Versión introducida
3.0
Comportamiento anterior
WebHostBuilder proporciona ObjectPoolProvider de forma predeterminada en el contenedor de DI.
Comportamiento nuevo
WebHostBuilder ya no proporciona ObjectPoolProvider de forma predeterminada en el contenedor de DI.
Motivo del cambio
Este cambio se ha realizado para aumentar la naturaleza de pago por uso de ASP.NET Core.
Acción recomendada
Si el componente requiere ObjectPoolProvider , tendrá que agregarlo a las dependencias mediante IServiceCollection .
Categoría
ASP.NET Core
API afectadas
None
*
HTTP: se ha quitado la extensibilidad de DefaultHttpContext
Como parte de las mejoras de rendimiento de ASP.NET Core 3.0, se ha quitado la extensibilidad de DefaultHttpContext . La clase ahora es sealed . Para
obtener más información, consulte dotnet/aspnetcore#6504.
Si en las pruebas unitarias se usa Mock<DefaultHttpContext> , use Mock<HttpContext> o new DefaultHttpContext() en su lugar.
Para obtener información, vea dotnet/aspnetcore#6534.
Versión introducida
3.0
Comportamiento anterior
Las clases se pueden derivar de DefaultHttpContext .
Comportamiento nuevo
Las clases se pueden derivar de DefaultHttpContext .
Motivo del cambio
La extensibilidad se proporcionó inicialmente para permitir la agrupación de HttpContext , pero incorporaba una complejidad innecesaria e impedía otras
optimizaciones.
Acción recomendada
Si usa Mock<DefaultHttpContext> en las pruebas unitarias, empiece a usar Mock<HttpContext> en su lugar.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Http.DefaultHttpContext
*
HTTP: las constantes HeaderNames se han cambiado a static readonly
A partir de ASP.NET Core 3.0 Preview 5, los campos de Microsoft.Net.Http.Headers.HeaderNames se han cambiado de const a static readonly .
Para obtener información, vea dotnet/aspnetcore#9514.
Versión introducida
3.0
Comportamiento anterior
Estos campos solían ser const .
Comportamiento nuevo
Ahora estos campos son static readonly .
Motivo del cambio
El cambio:
Impide que los valores se inserten en los límites de los ensamblados, lo que permite corregirlos según sea necesario.
Permite comprobaciones de igualdad de referencia más rápidas.
Acción recomendada
Vuelva a compilar para la versión 3.0. El código fuente que use estos campos de las maneras siguientes ya no podrá hacerlo:
Como un argumento de atributo
Como un objeto case en una instrucción switch
Al definir otra instancia de const
Para solucionar el cambio importante, use constantes de nombre de encabezado autodefinidas o literales de cadena.
Categoría
ASP.NET Core
API afectadas
Microsoft.Net.Http.Headers.HeaderNames
*
HTTP: cambios en la infraestructura del cuerpo de respuesta
La infraestructura que respalda un cuerpo de respuesta HTTP ha cambiado. Si usa HttpResponse directamente, no debe realizar ningún cambio en el código.
Siga leyendo si ajusta o reemplaza HttpResponse.Body , o si accede a HttpContext.Features .
Versión introducida
3.0
Comportamiento anterior
Había tres API asociadas al cuerpo de respuesta HTTP:
IHttpResponseFeature.Body
IHttpSendFileFeature.SendFileAsync
IHttpBufferingFeature.DisableResponseBuffering

Comportamiento nuevo
Si reemplaza HttpResponse.Body , reemplaza todo el elemento IHttpResponseBodyFeature por un contenedor en torno a la secuencia dada mediante
StreamResponseBodyFeature con el fin de proporcionar implementaciones predeterminadas para todas las API esperadas. Al volver a establecer la secuencia
original, este cambio se revierte.
Motivo del cambio
La motivación es combinar las API del cuerpo de la respuesta en una única interfaz de características nueva.
Acción recomendada
Use IHttpResponseBodyFeature donde anteriormente usaba IHttpResponseFeature.Body , IHttpSendFileFeature o IHttpBufferingFeature .
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Http.Features.IHttpBufferingFeature
Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.Body
Microsoft.AspNetCore.Http.Features.IHttpSendFileFeature
*
HTTP: Cambio a Ninguno de algunos valores predeterminados de cookie de SameSite
SameSite es una opción para cookies que puede ayudar a mitigar algunos ataques de falsificación de solicitud entre sitios (CSRF). Cuando esta opción se
presentó inicialmente, se usaron valores predeterminados incoherentes en varias API de ASP.NET Core. La incoherencia ha generado unos resultados
confusos. A partir de ASP.NET Core 3.0, estos valores predeterminados están organizados de mejor forma. Debe aceptar participar en esta característica
individualmente para cada componente.
Versión introducida
3.0
Comportamiento anterior
Las API de ASP.NET Core similares usaban diferentes valores predeterminados de SameSiteMode. Un ejemplo de la incoherencia se percibe en
HttpResponse.Cookies.Append(String, String) y HttpResponse.Cookies.Append(String, String, CookieOptions) , que tenían como valor predeterminado
SameSiteMode.None y SameSiteMode.Lax , respectivamente.

Comportamiento nuevo
Todas las API afectadas tienen como valor predeterminado SameSiteMode.None .
Motivo del cambio
El valor predeterminado se ha cambiado para que SameSite fuera una característica de participación opcional.
Acción recomendada
Cada componente que emite cookies debe decidir si SameSite es adecuado para sus escenarios. Revise el uso de las API afectadas y vuelva a configurar
SameSite según sea necesario.

Categoría
ASP.NET Core
API afectadas
IResponseCookies.Append(String, String, CookieOptions)
CookiePolicyOptions.MinimumSameSitePolicy
*
HTTP: se ha deshabilitado la E/S sincrónica en todos los servidores
A partir de ASP.NET Core 3.0, las operaciones de servidor sincrónicas están deshabilitadas de forma predeterminada.
Descripción del cambio
AllowSynchronousIO es una opción en cada servidor que habilita o deshabilita las API de E/S sincrónicas, como HttpRequest.Body.Read ,
HttpResponse.Body.Write y Stream.Flush . Estas API han sido durante mucho tiempo una fuente de colapsos de subprocesos y de bloqueos de la aplicación.
A partir de ASP.NET Core 3.0, versión preliminar 3, estas operaciones sincrónicas están deshabilitadas de forma predeterminada.
Servidores afectados:
Kestrel
HttpSys
IIS en proceso
TestServer
Se esperan errores parecidos a los siguientes:
 Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

Cada servidor tiene una opción AllowSynchronousIO que controla este comportamiento y el valor predeterminado para todos ellos ahora es false .
El comportamiento también se puede invalidar en función de cada solicitud como una mitigación temporal. Por ejemplo:

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();

if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}

Si tiene problemas con una elemento TextWriter u otra secuencia que llama a una API sincrónica en Dispose , llame a la nueva API de DisposeAsync en su
lugar.
Para obtener información, vea dotnet/aspnetcore#7644.
Versión introducida
3.0
Comportamiento anterior
De manera predeterminada, solo se permitían HttpRequest.Body.Read , HttpResponse.Body.Write y Stream.Flush .
Comportamiento nuevo
Estas API sincrónicas no están permitidas de forma predeterminada:
Se esperan errores parecidos a los siguientes:
Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

Motivo del cambio

Estas API sincrónicas han sido durante mucho tiempo una fuente de colapsos de subprocesos y de bloqueos de la aplicación. A partir de ASP.NET Core 3.0,
versión preliminar 3, las operaciones sincrónicas están deshabilitadas de forma predeterminada.
Acción recomendada
Use las versiones asincrónicas de los métodos. El comportamiento también se puede invalidar en función de cada solicitud como una mitigación temporal.

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();

if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}

Categoría
ASP.NET Core
API afectadas
Stream.Flush
Stream.Read
Stream.Write
*
Identidad: se ha quitado la sobrecarga del método AddDefaultUI
A partir de ASP.NET Core 3.0, ya no existe la sobrecarga del método IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework).
Versión introducida
3.0
Motivo del cambio
Este cambio fue el resultado de la adopción de la característica de recursos web estáticos.
Acción recomendada
Llame a IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) en lugar de a la sobrecarga que toma dos argumentos. Si usa Bootstrap 3, agregue
también la línea siguiente a un elemento <PropertyGroup> del archivo de proyecto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Categoría
ASP.NET Core
API afectadas
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
*
Identity: se ha cambiado la versión de Bootstrap predeterminada de la interfaz de usuario
A partir de ASP.NET Core 3.0, la interfaz de usuario de Identity tiene como valor predeterminado el uso de la versión 4 de Bootstrap.
Versión introducida
3.0
Comportamiento anterior
La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); era la misma que en
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3); .
Comportamiento nuevo
La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); es la misma que en
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4); .
Motivo del cambio
Bootstrap 4 se lanzó durante el periodo de tiempo de ASP.NET Core 3.0.
Acción recomendada
En el caso de que use la interfaz de usuario predeterminada de Identity y la haya agregado en Startup.ConfigureServices , este cambio le afectará, como se
muestra en el ejemplo siguiente:

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();

Realice una de las siguientes acciones:

Migre su aplicación para usar Bootstrap 4 usando la guía de migración.
Actualice Startup.ConfigureServices para forzar el uso de Bootstrap 3. Por ejemplo:

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Categoría
ASP.NET Core
API afectadas
None
*
Identity: SignInAsync produce una excepción para la identidad no autenticada
De forma predeterminada, SignInAsync produce una excepción para las entidades de seguridad o identidades en las que IsAuthenticated es false .
Versión introducida
3.0
Comportamiento anterior
SignInAsync acepta entidades de seguridad e identidades, incluidas las identidades en las que IsAuthenticated es false .
Comportamiento nuevo
De forma predeterminada, SignInAsync produce una excepción para las entidades de seguridad o identidades en las que IsAuthenticated es false . Hay
una nueva marca para suprimir este comportamiento, pero el comportamiento predeterminado ha cambiado.
Motivo del cambio
El comportamiento anterior era problemático porque, de forma predeterminada, [Authorize] / RequireAuthenticatedUser() rechazó estas entidades de
seguridad.
Acción recomendada
En ASP.NET Core 3.0, versión preliminar 6, hay una marca de RequireAuthenticatedSignIn en AuthenticationOptions que es true de forma
predeterminada. Establezca esta marca en false para restaurar el comportamiento anterior.
Categoría
ASP.NET Core
API afectadas
None
*
Identity: el constructor SignInManager acepta un nuevo parámetro
A partir de ASP.NET Core 3.0, se ha agregado un nuevo parámetro IUserConfirmation<TUser> al constructor SignInManager . Para obtener más información,
consulte dotnet/aspnetcore#8356.
Versión introducida
3.0
Motivo del cambio
La motivación del cambio consistió en agregar compatibilidad con nuevos flujos de correo electrónico o de confirmación en Identity.
Acción recomendada
Si crea manualmente un elemento SignInManager , proporcione una implementación de IUserConfirmation o capte una de la inserción de dependencias
que se va a proporcionar.
Categoría
ASP.NET Core
API afectadas
SignInManager<TUser>
*
Identity: la interfaz de usuario usa la característica de recursos web estáticos
ASP.NET Core 3.0 ha presentado una característica de recursos web estáticos y la interfaz de usuario de Identity la ha adoptado.
Descripción del cambio
Como resultado de la interfaz de usuario de Identity que adopta la característica de recursos web estáticos:
La selección del marco se realiza mediante el uso de la propiedad IdentityUIFrameworkVersion en el archivo del proyecto.
Bootstrap 4 es el marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity. Bootstrap 3 ha alcanzado el final del ciclo de
vida y debe considerar la posibilidad de migrar a una versión compatible.
Versión introducida
3.0
Comportamiento anterior
El marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity era Bootstrap 3 . El marco de la interfaz de usuario se puede
configurar mediante un parámetro para la llamada al método AddDefaultUI en Startup.ConfigureServices .
Comportamiento nuevo
El marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity es Bootstrap 4 . El marco de la interfaz de usuario debe
configurarse en el archivo del proyecto, en lugar de en la llamada al método AddDefaultUI .
Motivo del cambio
La adopción de la característica de recursos web estáticos requiere que la configuración del marco de la interfaz de usuario se mueva a MSBuild. La decisión
sobre qué marco se debe insertar es una decisión en tiempo de compilación, no una decisión en runtime.
Acción recomendada
Revise la interfaz de usuario del sitio para garantizar que los nuevos componentes de Bootstrap 4 son compatibles. En caso necesario, use la propiedad
IdentityUIFrameworkVersion de MSBuild para revertir a Bootstrap 3. Agregue la propiedad a un elemento <PropertyGroup> en el archivo del proyecto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Categoría
ASP.NET Core
API afectadas
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
*
Kestrel: se han quitado los adaptadores de conexión
Como parte de la migración de las API de "pubternal" a public , se ha quitado de Kestrel el concepto de un elemento IConnectionAdapter . Los adaptadores
de conexión se han reemplazado por el middleware de conexión, que es similar al middleware HTTP en la canalización de ASP.NET Core, pero para
conexiones de nivel inferior. HTTPS y el registro de conexiones se han movido de los adaptadores de conexión al middleware de conexión. Estos métodos de
extensión deberían seguir funcionando sin problemas, pero los detalles de implementación han cambiado.
Para obtener más información, vea dotnet/aspnetcore#11412. Para obtener información, vea dotnet/aspnetcore#11475.
Versión introducida
3.0
Comportamiento anterior
Los componentes de extensibilidad de Kestrel se creaban mediante el uso de IConnectionAdapter .
Comportamiento nuevo
Los componentes de extensibilidad de Kestrel se crean como middleware.
Motivo del cambio
Este cambio está pensado para proporcionar una arquitectura de extensibilidad más flexible.
Acción recomendada
Convierta las implementaciones de IConnectionAdapter para usar el nuevo patrón de middleware, tal como se muestra aquí.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter

*
Kestrel: se ha quitado un ensamblado HTTPS vacío
Se ha quitado el ensamblado Microsoft.AspNetCore.Server.Kestrel.Https.
Versión introducida
3.0
Motivo del cambio
En ASP.NET Core 2.1, el contenido de Microsoft.AspNetCore.Server.Kestrel.Https se ha movido a Microsoft.AspNetCore.Server.Kestrel.Core. Este cambio se
realizado de forma no interrumpida mediante el uso de atributos de [TypeForwardedTo] .
Acción recomendada
Las bibliotecas que hacen referencia a Microsoft.AspNetCore.Server.Kestrel.Https 2.0 deben actualizar todas las dependencias de ASP.NET Core a 2.1 o
una versión posterior. De lo contrario, se pueden interrumpir cuando se cargan en una aplicación ASP.NET Core 3.0.
Las aplicaciones y bibliotecas que tienen como destino ASP.NET Core 2.1 y versiones posteriores deben quitar las referencias directas al paquete NuGet
Microsoft.AspNetCore.Server.Kestrel.Https .

Categoría
ASP.NET Core
API afectadas
None
*
Kestrel: se han movido los encabezados de finalizador de solicitud a una nueva recopilación
En versiones anteriores, Kestrel agregaba encabezados de finalizador fragmentados de HTTP/1.1 en la recopilación de encabezados de solicitud cuando el
cuerpo de la solicitud se leía al final. Este comportamiento provocó problemas de ambigüedad entre encabezados y finalizadores. Se tomó la decisión de
mover los finalizadores a una nueva recopilación.
Los finalizadores de solicitudes HTTP/2 no estaban disponibles en ASP.NET Core 2.2, pero ahora también están disponibles en esta nueva recopilación en
ASP.NET Core 3.0.
Se han agregado métodos nuevos de extensión de solicitud para tener acceso a estos finalizadores.
Los finalizadores de HTTP/1.1 están disponibles una vez que se ha leído todo el cuerpo de la solicitud.
Los finalizadores de HTTP/2 están disponibles una vez que se han recibido del cliente. El cliente no enviará los finalizadores hasta que el servidor haya
almacenado en búfer como mínimo el cuerpo de la solicitud completo. Es posible que deba leer el cuerpo de la solicitud para liberar espacio en búfer. Los
finalizadores siempre están disponibles si lee el cuerpo de la solicitud hasta el final. Los finalizadores marcan el final del cuerpo.
Versión introducida
3.0
Comportamiento anterior
Los encabezados de finalizador de solicitud se agregarán a la recopilación HttpRequest.Headers .
Comportamiento nuevo
Los encabezados de finalizador de solicitud no están presentes en la recopilación HttpRequest.Headers . Use los métodos de extensión siguientes en
HttpRequest para tener acceso a ellos:

GetDeclaredTrailers() : obtiene el encabezado de "finalizador" de la solicitud que muestra los finalizadores que se esperan después del cuerpo.
SupportsTrailers() : indica si la solicitud admite la recepción de encabezados de finalizador.
CheckTrailersAvailable() : determina si la solicitud admite finalizadores y si están disponible para lectura.
GetTrailer(string trailerName) : obtiene el encabezado de finalización solicitado de la respuesta.

Motivo del cambio

Los finalizadores son una característica clave en escenarios como gRPC. Combinar los finalizadores en los encabezados de solicitud ha sido confuso para
los usuarios.
Acción recomendada
Use los métodos de extensión relacionados con el finalizador en HttpRequest para tener acceso a los finalizadores.
Categoría
ASP.NET Core
API afectadas
HttpRequest.Headers
*
Kestrel: las abstracciones de transporte se han quitado y se han hecho públicas
Como parte del desplazamiento de las API de "pubternal", las API de la capa de transporte de Kestrel se exponen como una interfaz pública en la biblioteca
de Microsoft.AspNetCore.Connections.Abstractions .
Versión introducida
3.0
Comportamiento anterior
Las abstracciones relacionadas con el transporte estaban disponibles en la biblioteca de Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions .
La propiedad ListenOptions.NoDelay estaba disponible.
Comportamiento nuevo
La interfaz de IConnectionListener se presentaba en la biblioteca de Microsoft.AspNetCore.Connections.Abstractions para exponer la funcionalidad más
usada de la biblioteca de ...Transport.Abstractions .
NoDelay está ahora disponible en opciones de transporte ( LibuvTransportOptions y SocketTransportOptions ).
SchedulingMode ya no está disponible.

Motivo del cambio

ASP.NET Core 3.0 se ha desplazado de las API de "pubternal".
Acción recomendada
Categoría
ASP.NET Core
API afectadas
None
*
Localización: ResourceManagerWithCultureStringLocalizer y WithCulture se han marcado como obsoletos
La clase ResourceManagerWithCultureStringLocalizer y el miembro de interfaz WithCulture suelen ser fuentes de confusión para los usuarios de
localización, en particular al crear su propia implementación de IStringLocalizer . Estos elementos proporcionan al usuario la impresión de que una
instancia de IStringLocalizer es "por lenguaje y por recurso". En realidad, las instancias solo deben ser "por recurso". El lenguaje que se busca lo
determina el CultureInfo.CurrentUICulture en tiempo de ejecución. Para eliminar el origen de la confusión, las API se han marcado como obsoletas en
ASP.NET Core 3.0, versión preliminar 3. Las API se quitarán en una versión futura.
Para obtener el contexto, consulte dotnet/aspnetcore#3324. Para obtener información, vea dotnet/aspnetcore#7756.
Versión introducida
3.0
Comportamiento anterior
Los métodos no se marcaban como Obsolete .
Comportamiento nuevo
Los métodos se marcan como Obsolete .
Motivo del cambio
Las API representan un caso de uso que no se recomienda. Ha habido confusión sobre el diseño de la localización.
Acción recomendada
La recomendación es usar ResourceManagerStringLocalizer en su lugar. Permita que CurrentCulture establezca la referencia cultural. Si no es una opción,
cree y use una copia de ResourceManagerWithCultureStringLocalizer.
Categoría
ASP.NET Core
API afectadas
ResourceManagerWithCultureStringLocalizer
ResourceManagerStringLocalizer.WithCulture
*
Registro: la clase DebugLogger se ha convertido en interna
Antes de ASP.NET Core 3.0, el modificador de acceso de DebugLogger era public . En ASP.NET Core 3.0, el modificador de acceso se ha cambiado a
internal .

Versión introducida
3.0
Motivo del cambio
El cambio se realiza para:
Aplicar la coherencia con otras implementaciones de registrador como ConsoleLogger .
Reducir la superficie de la API.
Acción recomendada
Use el método de extensión AddDebug de ILoggingBuilder para habilitar el registro de depuración. DebugLoggerProvider también sigue siendo public
en caso de que el servicio se tenga que registrar de forma manual.
Categoría
ASP.NET Core
API afectadas
Microsoft.Extensions.Logging.Debug.DebugLogger
*
MVC: se ha recortado el sufijo Async de los nombres de acción de controlador
Como parte de la solución de dotnet/aspnetcore#4849, en ASP.NET Core MVC se recorta el sufijo Async de los nombres de acción de forma
predeterminada. A partir de ASP.NET Core 3.0, este cambio afecta tanto al enrutamiento como a la generación de vínculos.
Versión introducida
3.0
Comportamiento anterior
Tenga en cuenta el siguiente controlador de ASP.NET Core MVC:

public class ProductController : Controller

{
public async IActionResult ListAsync()
{
var model = await DbContext.Products.ToListAsync();
return View(model);
}
}

La acción es enrutable mediante Product/ListAsync . La generación de vínculos requiere que se especifique el sufijo Async . Por ejemplo:

<a asp-controller="Product" asp-action="ListAsync">List</a>

Comportamiento nuevo
En ASP.NET Core 3.0, la acción es enrutable mediante Product/List . El código de generación de vínculos debe omitir el sufijo Async . Por ejemplo:

<a asp-controller="Product" asp-action="List">List</a>

Este cambio no afecta a los nombres especificados mediante el atributo [ActionName] . El nuevo comportamiento se puede deshabilitar si se establece
MvcOptions.SuppressAsyncSuffixInActionNames en false en Startup.ConfigureServices :

services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});

Motivo del cambio

Por convención, los métodos asincrónicos de .NET tienen el sufijo Async . Pero cuando un método define una acción de MVC, no es recomendable usar el
sufijo Async .
Acción recomendada
Si la aplicación depende de que las acciones de MVC conserven el sufijo Async del nombre, elija una de las mitigaciones siguientes:
Use el atributo [ActionName] para conservar el nombre original.
Establezca MvcOptions.SuppressAsyncSuffixInActionNames en false en Startup.ConfigureServices para deshabilitar totalmente el cambio de nombre:

services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});

Categoría
ASP.NET Core
API afectadas
None
*
MVC: JsonResult se ha trasladado a Microsoft.AspNetCore.Mvc.Core
JsonResult se ha trasladado al ensamblado Microsoft.AspNetCore.Mvc.Core . Este tipo se ha usado para definirse en
Microsoft.AspNetCore.Mvc.Formatters.Json. Se ha agregado un atributo [TypeForwardedTo] de nivel de ensamblado a
Microsoft.AspNetCore.Mvc.Formatters.Json para solucionar este problema en la mayoría de los usuarios. Las aplicaciones que usan bibliotecas de terceros
pueden encontrar problemas.
Versión introducida
3.0 Preview 6
Comportamiento anterior
Una aplicación que usa una biblioteca basada en la versión 2.2 se compila correctamente.
Comportamiento nuevo
Una aplicación que usa una biblioteca basada en la versión 2.2 produce un error en la compilación. Se proporciona un error que contiene una variación del
texto siguiente:

The type 'JsonResult' exists in both 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and
'Microsoft.AspNetCore.Mvc.Formatters.Json, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

Para obtener un ejemplo de este tipo de problema, consulte dotnet/aspnetcore#7220.

Motivo del cambio
Los cambios en el nivel de plataforma de la composición de ASP.NET Core como se describe en aspnet/Announcements#325.
Acción recomendada
Es posible que sea necesario volver a compilar las bibliotecas compiladas con la versión 2.2 de Microsoft.AspNetCore.Mvc.Formatters.Json para solucionar el
problema de todos los consumidores. Si se ve afectado, póngase en contacto con el autor de la biblioteca. Solicite volver a compilar la biblioteca para tener
como destino ASP.NET Core 3.0.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Mvc.JsonResult
*
MVC: herramienta de precompilación en desuso
En ASP.NET Core 1.1, se presentó el paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (herramienta de precompilación MVC) para agregar
compatibilidad con la compilación en tiempo de publicación de archivos Razor (archivos .cshtml). En ASP.NET Core 2.1, se presentó el SDK de Razor para
ampliar las características de la herramienta de precompilación. El SDK de Razor agregaba compatibilidad con los archivos Razor en tiempo de compilación
y publicación. El SDK comprueba la exactitud de los archivos .cshtml en tiempo de compilación mientras mejora el tiempo de inicio de la aplicación. El SDK
de Razor está activado de forma predeterminada y no se requiere ningún gesto para empezar a usarlo.
En ASP.NET Core 3.0, se quitó la herramienta de precompilación MVC de ASP.NET Core 1.1. Las versiones anteriores del paquete seguirán recibiendo
correcciones de seguridad y de errores importantes en la versión de revisión.
Versión introducida
3.0
Comportamiento anterior
El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation se usaba para compilar previamente las vistas de Razor de MVC.
Comportamiento nuevo
El SDK de Razor es compatible de forma nativa con esta funcionalidad. El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation ya no está actualizado.
Motivo del cambio
El SDK de Razor proporciona más funcionalidad y comprueba la exactitud de los archivos .cshtml en tiempo de compilación. El SDK también mejora el
tiempo de inicio de la aplicación.
Acción recomendada
Para los usuarios de ASP.NET Core 2.1 o versiones posteriores, actualice para usar la compatibilidad nativa con la precompilación en el SDK de Razor. Si los
errores o las características que faltan impiden la migración al SDK de Razor, abra una incidencia en dotnet/aspnetcore.
Categoría
ASP.NET Core
API afectadas
None
*
MVC: los tipos "pubternal" se han cambiado a internal
En ASP.NET Core 3.0, todos los tipos "pubternal" de MVC se actualizaron para ser public en un espacio de nombres compatible o internal , según
correspondiera.
Descripción del cambio
In ASP.NET Core, los tipos "pubternal" se declaran como public pero residen en un espacio de nombres con un sufijo .Internal . Aunque estos tipos son
public , no tienen ninguna directiva compatible y están sujetos a cambios importantes. Desafortunadamente, el uso accidental de estos tipos es habitual, lo
que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.
Versión introducida
3.0
Comportamiento anterior
Algunos tipos de MVC eran public pero en un espacio de nombres .Internal . Estos tipos no tenían ninguna directiva compatible y estaban sujetos a
cambios importantes.
Comportamiento nuevo
Todos estos tipos se actualizan para ser public en un espacio de nombres compatible o que se marquen como internal .
Motivo del cambio
El uso accidental de los tipos "pubternal" es habitual, lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.
Acción recomendada
Si usa tipos que se han convertido realmente en public y se han movido a un nuevo espacio de nombres compatible, actualice las referencias para que
coincidan con los espacios de nombres nuevos.
Si utiliza tipos que se han marcado como internal , deberá buscar una alternativa. Los tipos "pubternal" anteriores nunca se admitieron para uso público.
Si hay tipos específicos en estos espacios de nombres que son fundamentales para las aplicaciones, registre una incidencia en dotnet/aspnetcore. Se
pueden pensar ideas para hacer los tipos solicitados public .
Categoría
ASP.NET Core
API afectadas
Este cambio incluye tipos en los espacios de nombres siguientes:
Microsoft.AspNetCore.Mvc.Cors.Internal
Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
Microsoft.AspNetCore.Mvc.Formatters.Internal
Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
Microsoft.AspNetCore.Mvc.Internal
Microsoft.AspNetCore.Mvc.ModelBinding.Internal
Microsoft.AspNetCore.Mvc.Razor.Internal
Microsoft.AspNetCore.Mvc.RazorPages.Internal
Microsoft.AspNetCore.Mvc.TagHelpers.Internal
Microsoft.AspNetCore.Mvc.ViewFeatures.Internal

*
MVC: se han quitado las correcciones de compatibilidad (shim) con la API web
A partir de ASP.NET Core 3.0, el paquete Microsoft.AspNetCore.Mvc.WebApiCompatShim ya no está disponible.
Descripción del cambio
El paquete Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) proporciona compatibilidad parcial en ASP.NET Core con ASP.NET 4.x Web API
2 para simplificar la migración de implementaciones existentes de API web a ASP.NET Core. Pero las aplicaciones que usan WebApiCompatShim no se
benefician de las características relacionadas con la API que se distribuyen en versiones recientes de ASP.NET Core. Estas características incluyen la
generación mejorada de especificaciones de Open API, el control de errores estandarizado y la generación de código de cliente. Para centrar mejor los
esfuerzos de API en la versión 3.0, se ha quitado WebApiCompatShim. Las aplicaciones existentes en las que se usa WebApiCompatShim se deben migrar al
modelo de [ApiController] más reciente.
Versión introducida
3.0
Motivo del cambio
La corrección de compatibilidad (shim) de la API web era una herramienta de migración. Restringe el acceso de los usuarios a la nueva funcionalidad
agregada en ASP.NET Core.
Acción recomendada
Quite el uso de esta corrección de compatibilidad y migre directamente a la funcionalidad similar en ASP.NET Core.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Mvc.WebApiCompatShim
*
Razor: API RazorTemplateEngine eliminada
Se ha quitado la API RazorTemplateEngine y se ha reemplazado por RazorProjectEngine.
Para obtener información, vea la incidencia de GitHub dotnet/aspnetcore#25215.
Versión introducida
3.0
Comportamiento anterior
Un motor de plantillas se puede crear y usar para analizar y generar código para archivos de Razor.
Comportamiento nuevo
Se puede crear RazorProjectEngine y se le puede proporcionar el mismo tipo de información que a RazorTemplateEngine para analizar y generar código
para archivos de Razor. RazorProjectEngine también proporciona niveles de configuración adicionales.
Motivo del cambio
RazorTemplateEngine estaba demasiado acoplado a las implementaciones existentes. Este acoplamiento tan estrecho daba lugar a más preguntas al intentar
configurar correctamente una canalización de análisis y generación de Razor.
Acción recomendada
Use RazorProjectEngine en lugar de RazorTemplateEngine . Considere los ejemplos siguientes.
C r e a c i ó n y c o n fi g u r a c i ó n d e R a z o r P r o j e c t En g i n e
 RazorProjectEngine projectEngine =
RazorProjectEngine.Create(RazorConfiguration.Default,
RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
builder =>
{
builder.ConfigureClass((document, classNode) =>
{
classNode.ClassName = "MyClassName";

// Can also configure other aspects of the class here.

});

// More configuration can go here

});

Gen er ac i ó n de c ó di go par a u n ar c h i vo de Raz o r

RazorProjectItem item = projectEngine.FileSystem.GetItem(

@"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();

Categoría
ASP.NET Core
API afectadas
RazorTemplateEngine
RazorTemplateEngineOptions
*
Razor: la compilación en entorno de ejecución se ha movido a un paquete
La compatibilidad con la compilación en entorno de ejecución de las vistas de Razor y Razor Pages se ha movido a un paquete independiente.
Versión introducida
3.0
Comportamiento anterior
La compilación en entorno de ejecución está disponible sin necesidad de paquetes adicionales.
Comportamiento nuevo
La funcionalidad se ha pasado al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.
Las siguientes API estaban disponibles anteriormente en Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions para admitir la compilación en entorno de
ejecución. Las API ahora están disponibles mediante Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions .
RazorViewEngineOptions.FileProviders es ahora MvcRazorRuntimeCompilationOptions.FileProviders
RazorViewEngineOptions.AdditionalCompilationReferences es ahora MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Además, se ha quitado Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange . La recompilación en los cambios de

archivo está habilitada de forma predeterminada al hacer referencia al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .
Motivo del cambio
Este cambio era necesario para quitar la dependencia de marco compartido de ASP.NET Core en Roslyn.
Acción recomendada
Las aplicaciones que requieren la compilación o recompilación en entorno de ejecución de archivos Razor deben realizar los pasos siguientes:
1. Agregar una referencia al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .
2. Actualizar el método Startup.ConfigureServices del proyecto para incluir una llamada a AddRazorRuntimeCompilation . Por ejemplo:

services.AddMvc()
.AddRazorRuntimeCompilation();

Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
*
Estado de sesión: se han quitado las API obsoletas
Se han quitado las API obsoletas para configurar las cookies de sesión. Para obtener más información, consulte aspnet/Announcements#257.
Versión introducida
3.0
Motivo del cambio
Este cambio exige coherencia entre las API para configurar las características que usan cookies.
Acción recomendada
Migre el uso de las API quitadas a sus reemplazos más recientes. Considere el ejemplo siguiente de Startup.ConfigureServices :

public void ConfigureServices(ServiceCollection services)

{
services.AddSession(options =>
{
// Removed obsolete APIs
options.CookieName = "SessionCookie";
options.CookieDomain = "contoso.com";
options.CookiePath = "/";
options.CookieHttpOnly = true;
options.CookieSecure = CookieSecurePolicy.Always;

// new API
options.Cookie.Name = "SessionCookie";
options.Cookie.Domain = "contoso.com";
options.Cookie.Path = "/";
options.Cookie.HttpOnly = true;
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});
}

Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Builder.SessionOptions.CookieDomain
Microsoft.AspNetCore.Builder.SessionOptions.CookieHttpOnly
Microsoft.AspNetCore.Builder.SessionOptions.CookieName
Microsoft.AspNetCore.Builder.SessionOptions.CookiePath
Microsoft.AspNetCore.Builder.SessionOptions.CookieSecure
*
Marco compartido: se han quitado los ensamblados de Microsoft.AspNetCore.App
A partir de ASP.NET Core 3.0, el marco compartido de ASP.NET Core ( Microsoft.AspNetCore.App ) solo contiene ensamblados propios totalmente
desarrollados, admitidos y mantenidos por Microsoft.
Descripción del cambio
Considere el cambio como la redefinición de los límites de la "plataforma" ASP.NET Core. A través de GitHub, cualquier usuario puede compilar el código
fuente del marco compartido y seguirá ofreciendo a las aplicaciones las ventajas existentes de los marcos compartidos de .NET Core. Algunas ventajas son
el tamaño de implementación más pequeño, la revisión centralizada y el tiempo de inicio más rápido.
Como parte del cambio, en Microsoft.AspNetCore.App se han introducido algunos cambios importantes.
Versión introducida
3.0
Comportamiento anterior
Los proyectos hacían referencia a Microsoft.AspNetCore.App mediante un elemento <PackageReference> en el archivo de proyecto.
Además, Microsoft.AspNetCore.App incluía los subcomponentes siguientes:
Json.NET ( Newtonsoft.Json )
Entity Framework Core (ensamblados con el prefijo Microsoft.EntityFrameworkCore. )
Roslyn ( Microsoft.CodeAnalysis )
Comportamiento nuevo
Una referencia a Microsoft.AspNetCore.App ya no requiere un elemento <PackageReference> en el archivo de proyecto. El SDK de .NET Core admite un
nuevo elemento denominado <FrameworkReference> , que reemplaza el uso de <PackageReference> .
Para obtener más información, vea dotnet/aspnetcore#3612.
Entity Framework Core se distribuye como paquetes NuGet. Este cambio alinea el modelo de envío con el resto de las bibliotecas de acceso a datos de .NET.
Proporciona a Entity Framework Core la ruta más sencilla para continuar con la innovación al tiempo que admite las distintas plataformas .NET. La exclusión
de Entity Framework Core del marco compartido no tiene ningún impacto en su estado como biblioteca desarrollada, admitida y mantenida por Microsoft.
Continúa bajo la cobertura de la directiva de compatibilidad de .NET Core.
Json.NET y Entity Framework Core siguen funcionando con ASP.NET Core. Pero no se incluirán en el marco compartido.
Para obtener más información, vea El futuro de JSON en .NET Core 3.0. Vea también la lista completa de archivos binarios que se han quitado del marco
compartido.
Motivo del cambio
Este cambio simplifica el consumo de Microsoft.AspNetCore.App y reduce la duplicación entre paquetes NuGet y marcos compartidos.
Para obtener más información sobre la motivación de este cambio, vea esta entrada de blog.
Acción recomendada
No será necesario que los proyectos consuman ensamblados en Microsoft.AspNetCore.App como paquetes NuGet. Para simplificar la selección como
destino y el uso del marco compartido de ASP.NET Core, ya no se generan muchos paquetes NuGet enviados desde ASP.NET Core 1.0. Las API que
proporcionan esos paquetes siguen estando disponibles para las aplicaciones mediante el uso de un elemento <FrameworkReference> para
Microsoft.AspNetCore.App . Entre los ejemplos de API comunes se incluyen Kestrel, MVC y Razor.

Este cambio no se aplica a todos los archivos binarios a los que se hace referencia a través de Microsoft.AspNetCore.App en ASP.NET Core 2.x. Entre las
excepciones destacables se incluyen las siguientes:
Las bibliotecas de Microsoft.Extensions que todavía tienen .NET Standard como destino estarán disponibles como paquetes NuGet (vea
https://github.com/dotnet/extensions).
API generadas por el equipo de ASP.NET Core que no forman parte de Microsoft.AspNetCore.App . Por ejemplo, los componentes siguientes están
disponibles como paquetes NuGet:
Entity Framework Core
API que proporcionan integración de terceros
Características experimentales
API con dependencias que no han podido cumplir los requisitos para ser incluidas en el marco compartido
Extensiones para MVC que mantienen la compatibilidad con Json.NET. Se proporcionará una API como paquete NuGet para admitir el uso de Json.NET y
MVC.
El cliente de SignalR para .NET seguirá admitiendo .NET Standard y se enviará como un paquete NuGet. Está diseñado para usarse en muchos entornos
de ejecución de .NET, como Xamarin y UWP.
Para obtener más información, vea Detección de la generación de paquetes para ensamblados de marco compartido en 3.0. Para obtener información, vea
dotnet/aspnetcore#3757.
Categoría
ASP.NET Core
API afectadas
Microsoft.CodeAnalysis
Microsoft.EntityFrameworkCore
*
Marco compartido: se ha eliminado Microsoft.AspNetCore.All
A partir de ASP.NET Core 3.0, ya no se generan el metapaquete Microsoft.AspNetCore.All y el marco compartido Microsoft.AspNetCore.All
correspondiente. Este paquete está disponible en ASP.NET Core 2.2 y seguirá recibiendo actualizaciones de mantenimiento en ASP.NET Core 2.1.
Versión introducida
3.0
Comportamiento anterior
Las aplicaciones podían usar el metapaquete Microsoft.AspNetCore.All para seleccionar como destino el marco compartido Microsoft.AspNetCore.All en
.NET Core.
Comportamiento nuevo
En .NET Core 3.0 no se incluye un marco compartido Microsoft.AspNetCore.All .
Motivo del cambio
En el metapaquete Microsoft.AspNetCore.All se incluía un gran número de dependencias externas.
Acción recomendada
Migre el proyecto para usar el marco Microsoft.AspNetCore.App . Los componentes que anteriormente estaban disponibles en Microsoft.AspNetCore.All lo
siguen estando en NuGet. Ahora esos componentes se implementan con la aplicación en lugar de incluirse en el marco compartido.
Categoría
ASP.NET Core
API afectadas
None
*
SignalR: se ha reemplazado HandshakeProtocol.SuccessHandshakeData
El campo HandshakeProtocol.SuccessHandshakeData se ha quitado y se ha reemplazado por un método auxiliar que genera una respuesta de protocolo de
enlace correcta dado un protocolo IHubProtocol específico.
Versión introducida
3.0
Comportamiento anterior
HandshakeProtocol.SuccessHandshakeData era un campo public static ReadOnlyMemory<byte> .
Comportamiento nuevo
HandshakeProtocol.SuccessHandshakeData se ha reemplazado por un método GetSuccessfulHandshake(IHubProtocol protocol)``static que devuelve un objeto
ReadOnlyMemory<byte> basado en el protocolo especificado.
Motivo del cambio
Se han agregado campos adicionales a la respuesta del protocolo de enlace que no son constantes y cambian en función del protocolo seleccionado.
Acción recomendada
Ninguno. Este tipo no está diseñado para su uso desde el código de usuario. Es public , por lo que se puede compartir entre el servidor de SignalR y el
cliente. También lo pueden usar clientes de SignalR personalizados escritos en .NET. Los usuarios de SignalR no deberían verse afectados por este cambio.
Categoría
ASP.NET Core
API afectadas
HandshakeProtocol.SuccessHandshakeData
*
SignalR: se han quitado los métodos ResetSendPing y ResetTimeout de HubConnection
Los métodos ResetSendPing y ResetTimeout se han quitado de la API HubConnection de SignalR. Estos métodos se diseñaron originalmente solo para uso
interno, pero se hicieron públicos en ASP.NET Core 2.2. Estos métodos no estarán disponibles a partir de ASP.NET Core 3.0, versión preliminar 4. Para
obtener información, vea dotnet/aspnetcore#8543.
Versión introducida
3.0
Comportamiento anterior
Las API estaban disponibles.
Comportamiento nuevo
Las API se quitan.
Motivo del cambio
Estos métodos se diseñaron originalmente solo para uso interno, pero se hicieron públicos en ASP.NET Core 2.2.
Acción recomendada
No use estos métodos.
Categoría
ASP.NET Core
API afectadas
HubConnection.ResetSendPing()
HubConnection.ResetTimeout()
*
SignalR: se han cambiado los constructores de HubConnectionContext
Los constructores de HubConnectionContext de SignalR han cambiado para aceptar un tipo de opciones, en lugar de varios parámetros, para agregar
opciones con garantía de futuro. Este cambio reemplaza dos constructores por un único constructor que acepta un tipo de opciones.
Versión introducida
3.0
Comportamiento anterior
HubConnectionContext tiene dos constructores:

public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);

public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan
clientTimeoutInterval);

Comportamiento nuevo
Los dos constructores se han quitado y se han reemplazado por uno:

public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)

Motivo del cambio

El nuevo constructor usa un nuevo objeto de opciones. Por tanto, las características de HubConnectionContext se pueden expandir en el futuro sin crear más
constructores y cambios importantes.
Acción recomendada
En lugar de usar el constructor siguiente:

HubConnectionContext connectionContext = new HubConnectionContext(

connectionContext,
keepAliveInterval: TimeSpan.FromSeconds(15),
loggerFactory,
clientTimeoutInterval: TimeSpan.FromSeconds(15));
Use el constructor siguiente:

HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()

{
KeepAliveInterval = TimeSpan.FromSeconds(15),
ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);

Categoría
ASP.NET Core
API afectadas
HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory)
HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory, TimeSpan)
*
SignalR: se ha cambiado el nombre del paquete de cliente de JavaScript
En ASP.NET Core 3.0, versión preliminar 7, el nombre del paquete de cliente de JavaScript de SignalR ha cambiado de @aspnet/signalr a
@microsoft/signalr . El cambio de nombre refleja el hecho de que SignalR es útil más allá de las aplicaciones de ASP.NET Core, gracias a Azure SignalR
Service.
Para reaccionar a este cambio, cambie las referencias en los archivos package.json, las instrucciones require y las instrucciones import de ECMAScript. No
se cambiará ninguna API como parte de este cambio de nombre.
Para obtener información, vea dotnet/aspnetcore#11637.
Versión introducida
3.0
Comportamiento anterior
El paquete de cliente se llamaba @aspnet/signalr .
Comportamiento nuevo
El paquete de cliente se llama @microsoft/signalr .
Motivo del cambio
El cambio de nombre clarifica que SignalR es útil más allá de las aplicaciones de ASP.NET Core, gracias a Azure SignalR Service.
Acción recomendada
Cambie al paquete @microsoft/signalr nuevo.
Categoría
ASP.NET Core
API afectadas
None
*
SignalR: los métodos UseSignalR y UseConnections se han marcado como obsoletos
Los métodos UseConnections y UseSignalR , y las clases ConnectionsRouteBuilder y HubRouteBuilder están marcados como obsoletos en ASP.NET Core 3.0.
Versión introducida
3.0
Comportamiento anterior
El enrutamiento del centro de conectividad de SignalR se configuraba mediante UseSignalR o UseConnections .
Comportamiento nuevo
La forma antigua de configurar el enrutamiento ha quedado obsoleta y se ha reemplazado por el enrutamiento del punto de conexión.
Motivo del cambio
El middleware se está trasladando al sistema de enrutamiento nuevo de puntos de conexión. La forma anterior de agregar middleware está obsoleta.
Acción recomendada
Reemplace UseSignalR por UseEndpoints :
Código anterior :

app.UseSignalR(routes =>
{
routes.MapHub<SomeHub>("/path");
});

Código nuevo:
 app.UseEndpoints(endpoints =>
{
endpoints.MapHub<SomeHub>("/path");
});

Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Builder.ConnectionsAppBuilderExtensions.UseConnections(IApplicationBuilder, Action<ConnectionsRouteBuilder>)
Microsoft.AspNetCore.Builder.SignalRAppBuilderExtensions.UseSignalR(IApplicationBuilder, Action<HubRouteBuilder>)
Microsoft.AspNetCore.Http.Connections.ConnectionsRouteBuilder
Microsoft.AspNetCore.SignalR.HubRouteBuilder
*
SPA: SpaServices y NodeServices se han marcado como obsoletos
El contenido de los siguientes paquetes NuGet no es necesario a partir de ASP.NET Core 2.1. Por lo tanto, los paquetes siguientes se marcan como
obsoletos:
Microsoft.AspNetCore.SpaServices
Microsoft.AspNetCore.NodeServices
Por el mismo motivo, los módulos siguientes npm se han marcado como en desuso:
aspnet-angular
aspnet-prerendering
aspnet-webpack
aspnet-webpack-react
domain-task
Los paquetes y módulos npm anteriores se quitarán más adelante en .NET 5.
Versión introducida
3.0
Comportamiento anterior
Los paquetes y módulos npm en desuso se diseñaron para integrar ASP.NET Core con varios marcos de aplicación de página única (SPA). Estos marcos
incluyen React, and React con Redux.
Comportamiento nuevo
Existe un nuevo mecanismo de integración en el paquete de NuGet Microsoft.AspNetCore.SpaServices.Extensions. El paquete sigue siendo la base de las
plantillas de proyecto Angular y React a partir de ASP.NET Core 2.1.
Motivo del cambio
ASP.NET Core admite la integración con varios marcos de aplicación de página única (SPA), como Angular, React y React con Redux. Inicialmente, la
integración con estos marcos se logró con componentes específicos de ASP.NET Core que administraban escenarios como la representación previa y la
integración del lado servidor con Webpack. Con el paso del tiempo, los estándares del sector cambiaron. Cada uno de los marcos de SPA lanzó sus propias
interfaces de línea de comandos estándar. Por ejemplo, la CLI de Angular y create-react-app.
Cuando se publicó ASP.NET Core 2.1 en mayo de 2018, el equipo respondió al cambio en los estándares. Se proporcionó una manera más nueva y sencilla
de integrarse con las cadenas de herramientas propias de los marcos de SPA. El nuevo mecanismo de integración existe en el paquete
Microsoft.AspNetCore.SpaServices.Extensions y sigue siendo la base de las plantillas de proyecto Angular y React a partir de ASP.NET Core 2.1.

Para aclarar que los componentes específicos de ASP.NET Core antiguos son irrelevantes y no se recomiendan, se realizan las acciones siguientes:
El mecanismo de integración anterior a la versión 2.1 está marcado como obsoleto.
Los paquetes npm compatibles se marcan como en desuso.
Acción recomendada
Si usa estos paquetes, actualice las aplicaciones para usar la funcionalidad:
En el paquete Microsoft.AspNetCore.SpaServices.Extensions .
Que proporcionan los marcos de SPA que está usando.
Para habilitar características como la representación previa del lado servidor y la recarga de módulos frecuentes, consulte la documentación del marco de
SPA correspondiente. La funcionalidad de Microsoft.AspNetCore.SpaServices.Extensions no está obsoleta y seguirá siendo compatible.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Builder.SpaRouteExtensions
Microsoft.AspNetCore.Builder.WebpackDevMiddleware
Microsoft.AspNetCore.NodeServices.EmbeddedResourceReader
 Microsoft.AspNetCore.NodeServices.INodeServices
Microsoft.AspNetCore.NodeServices.NodeServicesFactory
Microsoft.AspNetCore.NodeServices.NodeServicesOptions
Microsoft.AspNetCore.NodeServices.StringAsTempFile
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.Prerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
*
SPA: SpaServices y NodeServices ya no vuelven al registrador de la consola
Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices no mostrarán los registros de la consola a menos que el registro esté
configurado.
Versión introducida
3.0
Comportamiento anterior
Antes, Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices creaban de forma automática un registrador de consola cuando el registro
no estaba configurado.
Comportamiento nuevo
Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices no mostrarán los registros de la consola a menos que el registro esté configurado.
Motivo del cambio
Existe la necesidad de alinearse con el modo de implementar el registro en otros paquetes de ASP.NET Core.
Acción recomendada
Si se requiere el comportamiento anterior, agregue services.AddLogging(builder => builder.AddConsole()) al método Setup.ConfigureServices para
configurar el registro de la consola.
Categoría
ASP.NET Core
API afectadas
None
*
Plataforma de destino: se ha quitado la compatibilidad con .NET Framework
A partir de ASP.NET Core 3.0, .NET Framework es un marco de destino que no se admite.
Descripción del cambio
.NET Framework 4.8 es la última versión principal de .NET Framework. Las nuevas aplicaciones de ASP.NET Core se deben compilar en .NET Core. A partir de
NET Core 3.0, puede considerar a ASP.NET Core 3.0 una parte de .NET Core.
Los clientes que usen ASP.NET Core con .NET Framework pueden continuar utilizando la versión 2.1 LTS de forma totalmente compatible. La compatibilidad
y el servicio para la versión 2.1 continuarán hasta el 21 de agosto de 2021. Esta fecha es tres años posterior a la declaración de la versión LTS de acuerdo a
la Directiva de compatibilidad de .NET. La compatibilidad con los paquetes de ASP.NET Core 2.1 en .NET Framework se extenderá indefinidamente, de
forma similar a la directiva de servicio para otros marcos de ASP.NET basados en paquetes.
Para más información sobre cómo migrar de .NET Framework a .NET Core, vea Portabilidad a .NET Core.
Los paquetes Microsoft.Extensions (como el registro, la inserción de dependencias y la configuración) y Entity Framework Core no se ven afectados.
Seguirán admitiendo .NET Standard.
Para más información sobre la motivación de este cambio, vea la entrada de blog original.
Versión introducida
3.0
Comportamiento anterior
Las aplicaciones ASP.NET Core se podían ejecutar en .NET Core o .NET Framework.
Comportamiento nuevo
Las aplicaciones ASP.NET Core solo se pueden ejecutar en .NET Core.
Acción recomendada
Realice una de las siguientes acciones:
Mantenga la aplicación en ASP.NET Core 2.1.
Migre la aplicación y las dependencias a .NET Core.
Categoría
ASP.NET Core
API afectadas
Ninguna
*

Bibliotecas de Core .NET

Las API que notifican la versión ahora notifican la versión del producto y no la del archivo
Las instancias personalizadas de EncoderFallbackBuffer no pueden retroceder de forma recursiva
Cambios en el comportamientos de formato y análisis de punto flotante
Las operaciones de análisis de punto flotante ya no producen un error ni una excepción OverflowException
Se ha movido InvalidAsynchronousStateException a otro ensamblado
Al reemplazar las secuencias de bytes UTF-8 con formato incorrecto se siguen las instrucciones de Unicode
Se ha movido TypeDescriptionProviderAttribute a otro ensamblado
ZipArchiveEntry ya no controla los archivos con tamaños de entrada incoherentes
FieldInfo.SetValue produce una excepción en los campos estáticos de solo inicialización
El paso de GroupCollection a métodos de extensión que toman IEnumerable<T> requiere desambiguación
Las API que notifican la versión ahora notifican la versión del producto y no la del archivo
Muchas de las API que devuelven versiones en .NET Core ahora devuelven la versión del producto en lugar de la del archivo.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, métodos como Environment.Version y RuntimeInformation.FrameworkDescription, y el cuadro de diálogo de las
propiedades del archivo para los ensamblados de .NET Core reflejan la versión del archivo. A partir de .NET Core 3.0, reflejan la versión del producto.
En la ilustración siguiente se muestra la diferencia en la información sobre la versión del ensamblado System.Runtime.dll para .NET Core 2.2 (a la izquierda)
y .NET Core 3.0 (a la derecha), tal y como se muestra en los cuadros de diálogo de las propiedades del archivo de Windows Explorer .

Versión introducida
3.0
Acción recomendada
Ninguno. Este cambio debería hacer que la comprobación de la versión sea intuitiva en lugar de difícil de entender.
Categoría
Bibliotecas de Core .NET
API afectadas
Environment.Version
RuntimeInformation.FrameworkDescription
*
No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer
No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer. La implementación de
EncoderFallbackBuffer.GetNextChar() debe traducirse en una secuencia de caracteres que se pueda convertir a la codificación de destino. De lo contrario, se
produce una excepción.
Descripción del cambio
Durante una operación de transcodificación de caracteres a bytes, el runtime detecta secuencias UTF-16 de formato incorrecto o no convertibles y
proporciona esos caracteres al método EncoderFallbackBuffer.Fallback. El método Fallback determina los caracteres que han de sustituirse por los datos
originales no convertibles y estos caracteres se drenan llamando a EncoderFallbackBuffer.GetNextChar en un bucle.
El runtime intenta luego transcodificar estos caracteres de sustitución en la codificación de destino. Si esta operación se realiza correctamente, el runtime
continúa con la transcodificación desde donde se quedó en la cadena de entrada original.
Antes, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() pueden devolver secuencias de caracteres que no se pueden convertir
en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, el runtime vuelve a invocar el método
EncoderFallbackBuffer.Fallback con los caracteres de sustitución, esperando que el método EncoderFallbackBuffer.GetNextChar() devuelva una nueva
secuencia de sustitución. Este proceso continúa hasta que el runtime ve finalmente una sustitución convertible de formato correcto o hasta que se alcanza
un número máximo de repeticiones.
A partir de .NET Core 3.0, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() deben devolver secuencias de caracteres que se
pueden convertir en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, se produce una
ArgumentException. El runtime ya no realizará llamadas recursivas a la instancia de EncoderFallbackBuffer.
Este comportamiento solo se aplica cuando se cumplen las tres condiciones siguientes:
El runtime detecta una secuencia UTF-16 de formato incorrecto o una secuencia UTF-16 que no se puede convertir en la codificación de destino.
Se ha especificado un EncoderFallback personalizado.
El EncoderFallback personalizado intenta sustituir una nueva secuencia UTF-16 con formato incorrecto o no convertible.
Versión introducida
3.0
Acción recomendada
La mayoría de los desarrolladores no tienen que realizar ninguna acción.
Si una aplicación usa un objeto EncoderFallback personalizado con una clase EncoderFallbackBuffer, asegúrese de que la implementación de
EncoderFallbackBuffer.Fallback rellena el búfer de reserva con datos UTF-16 de formato correcto que se puedan convertir directamente en la codificación de
destino cuando el runtime invoque por primera vez el método Fallback.
Categoría
Bibliotecas de Core .NET
API afectadas
EncoderFallbackBuffer.Fallback
EncoderFallbackBuffer.GetNextChar()
*
Cambios en los comportamientos de formato y análisis de los números de punto flotante
Los comportamientos de formato y análisis de los números de punto flotante (de los tipos Double y Single) ahora son compatibles con IEEE.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, dar formato con Double.ToString y Single.ToString, y realizar análisis con Double.Parse, Double.TryParse,
Single.Parse y Single.TryParse no es compatible con IEEE. Como resultado, no es posible garantizar que un valor realizará todo el proceso con una cadena de
formato estándar o personalizado compatible. En algunas entradas, se puede producir un error al intentar analizar un valor con formato y, en otras, el valor
analizado no es igual que el valor original.
A partir de .NET Core 3.0, las operaciones de análisis y formato son compatibles con IEEE 754. Esto garantiza que el comportamiento de los tipos de punto
flotante en .NET coincide con el de los lenguajes compatibles con IEEE, como C#. Para obtener más información, vea la entrada de blog Mejoras de formato
y análisis de punto flotante en .NET Core 3.0.
Versión introducida
3.0
Acción recomendada
En la sección “Posible impacto en el código existente” de la entrada de blog Mejoras de formato y análisis de punto flotante en .NET Core 3.0, se sugieren
cambios en el código si observa un cambio de comportamiento en comparación con las aplicaciones de .NET Core 2.2. Por lo general, esto implica el uso de
una cadena de formato estándar o personalizado diferente para aplicar el comportamiento deseado. Es posible que algunos resultados no tengan una
solución alternativa si anteriormente eran incorrectos.
Categoría
Bibliotecas de Core .NET
API afectadas
Double.ToString
Single.ToString
Double.Parse
Double.TryParse
Single.Parse
Single.TryParse
*
Las operaciones de análisis de punto flotante ya no producen un error o lanzan una excepción OverflowException
Los métodos de análisis de punto flotante ya no lanzan una OverflowException o devuelven false cuando analizan una cadena cuyo valor numérico está
fuera del rango del tipo de punto flotante Single o Double.
Descripción del cambio
En .NET Core 2.2 y versiones anteriores, los métodos Double.Parse y Single.Parse lanzan una OverflowException para los valores que se encuentran fuera
del rango de su tipo respectivo. Los métodos Double.TryParse y Single.TryParse devuelven false para las representaciones de cadena de valores
numéricos fuera del rango.
A partir de .NET Core 3.0, los métodos Double.Parse, Double.TryParse, Single.Parse y Single.TryParse ya no producen errores al analizar cadenas numéricas
fuera del rango. En su lugar, los métodos de análisis de Double devuelven Double.PositiveInfinity para los valores que superan Double.MaxValue y
Double.NegativeInfinity para los valores menores que Double.MinValue. Del mismo modo, los métodos de análisis de Single devuelven
Single.PositiveInfinity para los valores que superan Single.MaxValue y Single.NegativeInfinity para los valores menores que Single.MinValue.
Este cambio se ha realizado para mejorar el cumplimiento de la norma IEEE 754:2008.
Versión introducida
3.0
Acción recomendada
Este cambio puede afectar al código de alguna de estas dos formas:
El código depende del controlador para que OverflowException se ejecute cuando se produce un desbordamiento. En este caso, debe quitar la
instrucción catch y colocar cualquier código necesario en una instrucción If que compruebe si Double.IsInfinity o Single.IsInfinity es true .
El código presupone que los valores de punto flotante no son Infinity . En este caso, debe agregar el código necesario para comprobar los valores
de punto flotante de PositiveInfinity y NegativeInfinity .
Categoría
Bibliotecas de Core .NET
API afectadas
Double.Parse
Double.TryParse
Single.Parse
Single.TryParse
*
Se ha movido InvalidAsynchronousStateException a otro ensamblado
La clase InvalidAsynchronousStateException se ha movido.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, la clase InvalidAsynchronousStateException se encuentra en el ensamblado
System.ComponentModel.TypeConverter.
A partir de .NET Core 3.0, se encuentra en el ensamblado System.ComponentModel.Primitives.
Versión introducida
3.0
Acción recomendada
Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar InvalidAsynchronousStateException mediante la llamada a un método como
Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, actualice el
ensamblado al que se hace referencia en la llamada de método para reflejar la nueva ubicación del ensamblado del tipo.
Categoría
Bibliotecas de Core .NET
API afectadas
Ninguno.
*
Al reemplazar las secuencias de bytes UTF-8 con formato incorrecto se siguen las instrucciones de Unicode
Cuando la clase UTF8Encoding encuentra una secuencia de bytes UTF-8 con formato incorrecto durante una operación de transcodificación de byte a
carácter, reemplaza esa secuencia por un carácter "� " (CARÁCTER DE REEMPLAZO DE U+FFFD) en la cadena de salida. .NET Core 3.0 se diferencia de las
versiones anteriores de .NET Core y de .NET Framework en que sigue los procedimientos recomendados de Unicode para realizar este reemplazo durante la
operación de transcodificación.
Esto forma parte de un trabajo mayor para mejorar el control de UTF-8 en .NET, que los nuevos tipos System.Text.Unicode.Utf8 y System.Text.Rune incluyen.
Se asignó una mecánica de control de errores mejorada al tipo UTF8Encoding para que genere una salida coherente con los tipos recién incorporados.
Descripción del cambio
A partir de .NET Core 3.0, al transcodificar bytes en caracteres, la clase UTF8Encoding realiza la sustitución de caracteres en función de los procedimientos
recomendados de Unicode. El mecanismo de sustitución que se usa se describe en The Unicode Standard, Version 12.0, Sec. 3.9 (PDF) en el apartado
titulado U+FFFD Substitution of Maximal Subparts.
Este comportamiento solo se aplica cuando la secuencia de bytes de entrada contiene datos UTF-8 con formato incorrecto. Además, si la instancia de
UTF8Encoding se ha construido con throwOnInvalidBytes: true , la instancia de UTF8Encoding continuará produciéndose en una entrada no válida en lugar
de realizar el reemplazo de U+FFFD. Para obtener más información sobre el constructor UTF8Encoding , vea UTF8Encoding(Boolean, Boolean).
En la siguiente tabla se muestra el impacto de este cambio con una entrada de 3 bytes no válida:

EN T RA DA DE 3 B Y T ES C O N F O RM ATO IN C O RREC TO SA L IDA A N T ES DE . N ET C O RE 3. 0 SA L IDA A PA RT IR DE . N ET C O RE 3. 0

[ ED A0 90 ] [ FFFD FFFD ] (salida de 2 caracteres) [ FFFD FFFD FFFD ] (salida de 3 caracteres)

La salida de 3 caracteres es la preferida, según la tabla 3-9 del PDF del estándar Unicode vinculado anteriormente.
Versión introducida
3.0
Acción recomendada
No se requiere ninguna acción por parte del desarrollador.
Categoría
Bibliotecas de Core .NET
API afectadas
UTF8Encoding.GetCharCount
UTF8Encoding.GetChars
UTF8Encoding.GetString(Byte[], Int32, Int32)
*
Se ha movido TypeDescriptionProviderAttribute a otro ensamblado
La clase TypeDescriptionProviderAttribute se ha movido.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, la clase TypeDescriptionProviderAttribute se encuentra en el ensamblado
System.ComponentModel.TypeConverter.
A partir de .NET Core 3.0, se encuentra en el ensamblado System.ObjectModel.
Versión introducida
3.0
Acción recomendada
Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar el tipo TypeDescriptionProviderAttribute mediante la llamada a un método como
Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, el ensamblado al
que se hace referencia en la llamada al método debe actualizarse para reflejar la nueva ubicación del ensamblado del tipo.
Categoría
Windows Forms
API afectadas
Ninguno.
*
ZipArchiveEntry ya no controla los archivos con tamaños de entrada incoherentes
Los archivos zip muestran tanto el tamaño comprimido como el tamaño no comprimido en el directorio central y en el encabezado local. Los propios datos
de entrada también indican su tamaño. En .NET Core 2.2 y versiones anteriores, nunca se comprobó la coherencia de estos valores. A partir de .NET Core 3.0,
ahora son.
Descripción del cambio
En .NET Core 2.2 y versiones anteriores, ZipArchiveEntry.Open() funciona correctamente aunque el encabezado local no concuerde con el encabezado
central del archivo zip. Los datos se descomprimen hasta que se alcanza el final del flujo comprimido, aunque su longitud supere el tamaño de archivo sin
comprimir que se muestra en el directorio central/encabezado local.
A partir de .NET Core 3.0, el método ZipArchiveEntry.Open() comprueba que el encabezado local y el encabezado central coinciden en el tamaño
comprimido y no comprimido de una entrada. Si no coinciden, el método produce una InvalidDataException si el encabezado local del archivo o el tamaño
de la lista de descriptores de datos que no están en desacuerdo con el directorio central del archivo zip. Al leer una entrada, los datos descomprimidos se
truncan hasta el tamaño de archivo sin comprimir que se muestra en el encabezado.
Este cambio se realizó para asegurarse de que un ZipArchiveEntryrepresenta correctamente el tamaño de sus datos y que solo se lee esa cantidad de datos.
Versión introducida
3.0
Acción recomendada
Vuelva a empaquetar los archivos ZIP que presentan estos problemas.
Categoría
CoreFX
API afectadas
ZipArchiveEntry.Open()
ZipFileExtensions.ExtractToDirectory
ZipFileExtensions.ExtractToFile
ZipFile.ExtractToDirectory
*
FieldInfo.SetValue produce una excepción en los campos estáticos de solo inicialización
A partir de .NET Core 3.0, se produce una excepción si intenta establecer un valor en un campo InitOnly estático al llamar a
System.Reflection.FieldInfo.SetValue.
Descripción del cambio
En .NET Framework y en versiones de .NET Core anteriores a la 3.0, podía establecer el valor de un campo estático constante una vez inicializado (readonly
en C#) mediante una llamada a System.Reflection.FieldInfo.SetValue. Con todo, al establecer este tipo de campo de esta manera, se producía un
comportamiento imprevisible en función de la plataforma de destino y la configuración de optimización.
En .NET Core 3.0 y versiones posteriores, al llamar a SetValue en un campo InitOnly estático, se produce una excepción System.FieldAccessException.

TIP
Un campo InitOnly es uno que solo se puede establecer en el momento en que se declara o en el constructor de la clase contenedora. En otras palabras, es constante
después de inicializarse.

Versión introducida
3.0
Acción recomendada
Inicialice los campos InitOnly estáticos en un constructor estático. Esto se aplica a los tipos dinámicos y no dinámicos.
Como alternativa, puede quitar el atributo FieldAttributes.InitOnly del campo y después llamar a FieldInfo.SetValue.
Categoría
Bibliotecas de Core .NET
API afectadas
FieldInfo.SetValue(Object, Object)
FieldInfo.SetValue(Object, Object, BindingFlags, Binder, CultureInfo)
*
El paso de GroupCollection a métodos de extensión que toman IEnumerable<T> requiere desambiguación
Al llamar a un método de extensión que toma IEnumerable<T> en un elemento GroupCollection, se debe eliminar la ambigüedad del tipo mediante una
conversión.
Descripción del cambio
A partir de .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementa IEnumerable<KeyValuePair<String,Group>> , además de los otros tipos
que implementa, incluido IEnumerable<Group> . Esto produce ambigüedad al llamar a un método de extensión que toma un elemento IEnumerable<T>. Si
llama a un método de extensión como este en una instancia de GroupCollection, por ejemplo, Enumerable.Count, verá el error del compilador siguiente:
CS1061: "GroupCollection" no contiene una definición para "Count" ni se encuentra ningún método de extensión accesible "Count" que
acepte un primer argumento del tipo "GroupCollection" (¿falta una directiva de uso o una referencia de ensamblado?) .
En versiones anteriores de .NET, no había ambigüedad ni ningún error del compilador.
Versión introducida
3.0
Motivo del cambio
Se trató de un cambio importante involuntario. Dado que no es algo nuevo de ahora, no tenemos previsto revertirlo. Además, un cambio de este tipo sería
importante en sí mismo.
Acción recomendada
En el caso de instancias de GroupCollection, elimine la ambigüedad de las llamadas a métodos de extensión que aceptan un elemento IEnumerable<T> con
una conversión.
 // Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.

((IEnumerable<Group>)m.Groups).Count(_ => true);

Categoría
Bibliotecas de Core .NET
API afectadas
Los métodos de extensión que aceptan un elemento IEnumerable<T> se ven afectados. Por ejemplo:
System.Collections.Immutable.ImmutableArray.ToImmutableArray<TSource>(IEnumerable<TSource>)
System.Collections.Immutable.ImmutableDictionary.ToImmutableDictionary
System.Collections.Immutable.ImmutableHashSet.ToImmutableHashSet
System.Collections.Immutable.ImmutableList.ToImmutableList<TSource>(IEnumerable<TSource>)
System.Collections.Immutable.ImmutableSortedDictionary.ToImmutableSortedDictionary
System.Collections.Immutable.ImmutableSortedSet.ToImmutableSortedSet
System.Data.DataTableExtensions.CopyToDataTable
Gran parte de los métodos System.Linq.Enumerable , por ejemplo, System.Linq.Enumerable.Count
System.Linq.ParallelEnumerable.AsParallel
System.Linq.Queryable.AsQueryable
*

Criptografía
Ya no se admite la sintaxis BEGIN TRUSTED CERTIFICATE en Linux
EnvelopedCms usa de forma predeterminada el cifrado AES-256
Ha aumentado el tamaño mínimo de la generación de claves RSAOpenSsl
.NET Core 3.0 prefiere OpenSSL 1.1.x a OpenSSL 1.0.x
Transformación del bloque final solo durante el proceso de escritura mediante CryptoStream.Dispose
Ya no se admite la sintaxis "BEGIN TRUSTED CERTIFICATE" en certificados raíz de Linux
Los certificados raíz de Linux y otros sistemas similares a Unix (a excepción de macOS) se pueden presentar de dos formas: el encabezado PEM
BEGIN CERTIFICATE estándar y el encabezado PEM BEGIN TRUSTED CERTIFICATE específico de OpenSSL. La última sintaxis permite una configuración adicional
que ha provocado problemas de compatibilidad con la clase System.Security.Cryptography.X509Certificates.X509Chain de .NET Core. El motor de cadena ya
no carga el contenido del certificado raíz BEGIN TRUSTED CERTIFICATE a partir de .NET Core 3.0.
Descripción del cambio
Anteriormente, las sintaxisBEGIN CERTIFICATE y BEGIN TRUSTED CERTIFICATE se usaban para rellenar la lista de confianza raíz. Si se ha usado la sintaxis
BEGIN TRUSTED CERTIFICATE y se han especificado opciones adicionales en el archivo, es posible que X509Chain haya informado de que la confianza de
cadena no se permite explícitamente (X509ChainStatusFlags.ExplicitDistrust). Con todo, si el certificado también se había especificado con la sintaxis
BEGIN CERTIFICATE en un archivo cargado anteriormente, se permitía la confianza de cadena.

A partir de .NET Core 3.0, ya no se lee el contenido de BEGIN TRUSTED CERTIFICATE . Si el certificado no se especifica también mediante una sintaxis
BEGIN CERTIFICATE estándar, X509Chain informa de que la raíz no es de confianza (X509ChainStatusFlags.UntrustedRoot).

Versión introducida
3.0
Acción recomendada
La mayoría de las aplicaciones no se ven afectadas por este cambio, pero las aplicaciones que no pueden ver ambos orígenes del certificado raíz por
problemas de permisos pueden experimentar errores inesperados de UntrustedRoot después de actualizarse.
Muchas distribuciones de Linux escriben certificados raíz en dos ubicaciones: un directorio con un certificado por archivo y una concatenación de un
archivo. En algunas distribuciones, el directorio con un certificado por archivo usa la sintaxis BEGIN TRUSTED CERTIFICATE mientras que la concatenación de
archivos usa la sintaxis BEGIN CERTIFICATE estándar. Asegúrese de que los certificados raíz personalizados se agregan como BEGIN CERTIFICATE en al menos
una de estas ubicaciones y que la aplicación puede leer ambas ubicaciones.
El directorio típico es /etc/ssl/certs/ y el archivo concatenado típico es /etc/ssl/cert.pem. Use el comando openssl version -d para determinar la raíz
específica de la plataforma, que puede ser diferente de /etc/ssl/ . Por ejemplo, en Ubuntu 18.04, el directorio es /usr/lib/ssl/certs/ y el archivo es
/usr/lib/ssl/cert.pem. A pesar de esto, /usr/lib/ssl/certs/ es un vínculo simbólico a /etc/ssl/certs/ y /usr/lib/ssl/cert.pem no existe.

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ ls -al /usr/lib/ssl
total 12
drwxr-xr-x 3 root root 4096 Dec 12 17:10 .
drwxr-xr-x 73 root root 4096 Feb 20 15:18 ..
lrwxrwxrwx 1 root root 14 Mar 27 2018 certs -> /etc/ssl/certs
drwxr-xr-x 2 root root 4096 Dec 12 17:10 misc
lrwxrwxrwx 1 root root 20 Nov 12 16:58 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx 1 root root 16 Mar 27 2018 private -> /etc/ssl/private
Categoría
Criptografía
API afectadas
System.Security.Cryptography.X509Certificates.X509Chain
*
EnvelopedCms utiliza de forma predeterminada el cifrado AES-256
El algoritmo de cifrado simétrico predeterminado que usa EnvelopedCms ha cambiado de TripleDES a AES-256.
Descripción del cambio
En versiones anteriores, cuando se usa EnvelopedCms para cifrar datos sin especificar un algoritmo de cifrado simétrico a través de una sobrecarga de
constructor, los datos se cifran con el algoritmo TripleDES/3DES/3DEA/DES3-EDE.
A partir de .NET Core 3.0 (a través de la versión 4.6.0 del paquete NuGet System.Security.Cryptography.Pkcs), el algoritmo predeterminado se ha cambiado
a AES-256 para la modernización de algoritmos y para mejorar la seguridad de opciones predeterminadas. Si el certificado del destinatario de un mensaje
tiene una clave pública Diffie-Hellman (no de cliente de empresa), es posible que se produzca un error CryptographicException en la operación de cifrado
debido a limitaciones de la plataforma subyacente.
En el siguiente código de ejemplo, los datos se cifran con TripleDES si se ejecutan en .NET Core 2.2 o anterior. Si se ejecutan en .NET Core 3.0 o posterior, se
cifran con AES-256.

EnvelopedCms cms = new EnvelopedCms(content);

cms.Encrypt(recipient);
return cms.Encode();

Versión introducida
3.0
Acción recomendada
Si el cambio le afecta negativamente, puede restaurar el cifrado TripleDES especificando explícitamente el identificador del algoritmo de cifrado en un
constructor de EnvelopedCms que incluya un parámetro del tipo AlgorithmIdentifier, por ejemplo:

Oid tripleDesOid = new Oid("1.2.840.113549.3.7", null);

AlgorithmIdentifier tripleDesIdentifier = new AlgorithmIdentifier(tripleDesOid);
EnvelopedCms cms = new EnvelopedCms(content, tripleDesIdentifier);

cms.Encrypt(recipient);
return cms.Encode()l

Categoría
Criptografía
API afectadas
EnvelopedCms()
EnvelopedCms(ContentInfo)
EnvelopedCms(SubjectIdentifierType, ContentInfo)
*
Ha aumentado el tamaño mínimo de la generación de claves RSAOpenSsl
El tamaño mínimo para generar nuevas claves RSA en Linux ha aumentado de 384 bits a 512 bits.
Descripción del cambio
A partir de .NET Core 3.0, el tamaño mínimo de clave permitido que notifica la propiedad LegalKeySizes en instancias de RSA desde RSA.Create,
RSAOpenSsl y RSACryptoServiceProvider en Linux ha aumentado de 384 a 512.
Por consiguiente, .NET Core 2.2 y versiones anteriores, una llamada de método como RSA.Create(384) se realiza correctamente. En .NET Core 3.0 y
versiones posteriores, la llamada de método RSA.Create(384) produce una excepción que indica que el tamaño es demasiado pequeño.
Este cambio se realizó porque OpenSSL, que realiza las operaciones criptográficas en Linux, ha aumentado su mínimo entre las versiones 1.0.2 y 1.1.0.
.NET Core 3.0 prefiere OpenSSL 1.1. x a 1.0. x, y la versión mínima notificada se elevó para reflejar esta nueva limitación de dependencia más alta.
Versión introducida
3.0
Acción recomendada
Si llama a cualquiera de las API afectadas, asegúrese de que el tamaño de las claves generadas no sea inferior al mínimo del proveedor.

NOTE
El RSA de 384 bits ya se considera inseguro (al igual que el RSA de 512 bits). Las recomendaciones modernas, como NIST Special Publication 800-57 Part 1 Revision 4,
sugieren 2048 bits como tamaño mínimo para las claves recién generadas.

Categoría
Criptografía
API afectadas
AsymmetricAlgorithm.LegalKeySizes
RSA.Create
RSAOpenSsl
RSACryptoServiceProvider
*
.NET Core 3.0 prefiere OpenSSL 1.1.x a OpenSSL 1.0.x
.NET Core para Linux, que funciona en varias distribuciones de Linux, puede admitir OpenSSL 1.0.x y OpenSSL 1.1.x. .NET Core 2.1 y .NET Core 2.2 buscan
1.0.x primero y luego recurren a 1.1.x; .NET Core 3.0 busca 1.1.x primero. Este cambio se realizó para agregar compatibilidad con nuevos estándares
criptográficos.
Este cambio puede afectar a las bibliotecas o aplicaciones que llevan a cabo la interoperabilidad de la plataforma con los tipos de interoperabilidad
específicos de OpenSSL en .NET Core.
Descripción del cambio
En .NET Core 2.2 y versiones anteriores, el runtime prefiere cargar OpenSSL 1.0.x a 1.1.x. Esto significa que los tipos IntPtr y SafeHandle para la
interoperabilidad con OpenSSL se usan, por orden de preferencia, con libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10.
A partir de .NET Core 3.0, el runtime prefiere cargar OpenSSL 1.1.x a OpenSSL 1.0.x, por lo que los tipos IntPtr y SafeHandle para la interoperabilidad con
OpenSSL se usan, por orden de preferencia, con libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1. Por consiguiente, las bibliotecas y
aplicaciones que interactúan directamente con OpenSSL pueden tener punteros incompatibles con los valores expuestos en .NET Core cuando se actualiza
desde .NET Core 2.1 o.NET Core 2.2.
Versión introducida
3.0
Acción recomendada
Las bibliotecas y aplicaciones que realizan operaciones directas con OpenSSL deben tener cuidado de asegurarse de que usan la misma versión de
OpenSSL que el runtime de .NET Core.
Todas las bibliotecas o aplicaciones que usan los valores IntPtr o SafeHandle de los tipos criptográficos de .NET Core directamente con OpenSSL deben
comparar la versión de la biblioteca que usan con la nueva propiedad SafeEvpPKeyHandle.OpenSslVersion para asegurarse de que los punteros son
compatible.
Categoría
Criptografía
API afectadas
SafeEvpPKeyHandle
RSAOpenSsl(IntPtr)
RSAOpenSsl(SafeEvpPKeyHandle)
RSAOpenSsl.DuplicateKeyHandle()
DSAOpenSsl(IntPtr)
DSAOpenSsl(SafeEvpPKeyHandle)
DSAOpenSsl.DuplicateKeyHandle()
ECDsaOpenSsl(IntPtr)
ECDsaOpenSsl(SafeEvpPKeyHandle)
ECDsaOpenSsl.DuplicateKeyHandle()
ECDiffieHellmanOpenSsl(IntPtr)
ECDiffieHellmanOpenSsl(SafeEvpPKeyHandle)
ECDiffieHellmanOpenSsl.DuplicateKeyHandle()
X509Certificate.Handle
*
Transformación del bloque final solo durante el proceso de escritura mediante CryptoStream.Dispose
El método CryptoStream.Dispose, que se usa para finalizar operaciones CryptoStream , ya no intenta transformar el bloque final durante la lectura.
Descripción del cambio
En versiones anteriores de .NET, si un usuario realizaba una lectura incompleta al usar CryptoStream en el modo Read, el método Dispose podía producir
una excepción (por ejemplo, al usar AES con espaciado interno). Se producía la excepción porque se intentaba transformar el bloque final, pero los datos
estaban incompletos.
En .NET Core 3.0 y versiones posteriores, Dispose ya no intenta transformar el bloque final durante la lectura, lo que permite hacer lecturas incompletas.
Motivo del cambio
Este cambio permite las lecturas incompletas de la secuencia de cifrado cuando se cancela una operación de red, sin necesidad de capturar una excepción.
Versión introducida
3.0
Acción recomendada
La mayoría de las aplicaciones no se verán afectadas por este cambio.
Si su aplicación detectaba anteriormente una excepción en caso de una lectura incompleta, puede eliminar ese bloque catch . Si su aplicación usaba la
transformación del bloque final en operaciones hash, puede que tenga que asegurarse de que se lee toda la secuencia antes de eliminar el bloque.
Categoría
Criptografía
API afectadas
System.Security.Cryptography.CryptoStream.Dispose
*

Entity Framework Core

Cambios importantes de Entity Framework Core

Globalización
La configuración regional de "C" se asigna a la configuración regional invariable
La configuración regional de “C” se asigna a la configuración regional invariable
.NET Core 2.2 y las versiones anteriores dependen del comportamiento predeterminado de ICU, el cual asigna la configuración regional de “C” a la
configuración regional en_US_POSIX. La configuración regional en_US_POSIX tiene un comportamiento de intercalación no deseado, porque no admite
comparaciones de cadenas que no distinguen mayúsculas de minúsculas. Algunas distribuciones de Linux establecían la configuración regional de “C”
como la configuración regional predeterminada, por lo que los usuarios experimentaban un comportamiento inesperado.
Descripción del cambio
A partir de .NET Core 3.0, la asignación de la configuración regional de “C” ha cambiado para usar la configuración regional invariable en lugar de
en_US_POSIX. La configuración regional de “C” con la asignación invariable también se aplica a Windows para mantener la coherencia.
La asignación de “C” a la referencia cultural en_US_POSIX causaba confusión entre los clientes porque en_US_POSIX no admite operaciones de ordenación
y búsqueda de cadenas que no distinguen mayúsculas de minúsculas. Dado que la configuración regional de “C” se usa como configuración regional
predeterminada en algunas de las distribuciones de Linux, los clientes experimentaron este comportamiento no deseado en estos sistemas operativos.
Versión introducida
3.0
Acción recomendada
Nada más aparte de conocer este cambio. Este cambio solo afecta a las aplicaciones que usan la asignación de configuración regional de “C”.
Categoría
Globalización
API afectadas
Este cambio afecta a todas las API de intercalación y de referencia cultural.
*

MSBuild
Cambio de nombre de archivo de manifiesto del recurso
Cambio de nombre de archivo de manifiesto del recurso
A partir de .NET Core 3.0, en el caso predeterminado, MSBuild genera un nombre de archivo de manifiesto diferente para los archivos de recursos.
Versión introducida
3.0
Descripción del cambio
Antes de .NET Core 3.0, si no se especificaban los metadatos LogicalName , ManifestResourceName o DependentUpon para un elemento de EmbeddedResource
del archivo del proyecto, MSBuild generaba un nombre de archivo de manifiesto con el patrón
<RootNamespace>.<ResourceFilePathFromProjectRoot>.resources . Si RootNamespace no está definido en el archivo del proyecto, se toma como valor
predeterminado el nombre del proyecto. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx en el
directorio raíz del proyecto era suproject.Form1.Resources.
A partir de .NET Core 3.0, si un archivo de recursos está ubicado conjuntamente con un archivo de código fuente del mismo nombre (por ejemplo,
Form1.resx y Form1.cs), MSBuild usa la información de tipo del archivo de código fuente para generar el nombre del archivo de manifiesto con el patrón
<Namespace>.<ClassName>.resources . El espacio de nombres y el nombre de clase se extraen del primer tipo del archivo de código fuente ubicado
conjuntamente. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx que se ubica conjuntamente con un
archivo de código fuente denominado Form1.cs es myNameSpace.Form1.Resources. Lo más importante que hay que tener en cuenta es que la primera
parte del nombre de archivo es diferente en versiones anteriores de .NET Core (myNameSpace en lugar de MyProject).

NOTE
Si tiene los metadatos LogicalName , ManifestResourceName o DependentUpon especificados en un elemento EmbeddedResource del archivo del proyecto, este
cambio no afecta a ese archivo de recursos.

Este cambio importante se presentó con la incorporación de la propiedad EmbeddedResourceUseDependentUponConvention a los proyectos de .NET Core. De
forma predeterminada, los archivos de recursos no se enumeran explícitamente en un archivo de proyecto de .NET Core, por lo que no tienen metadatos
DependentUpon para especificar cómo nombrar el archivo .resources generado. Cuando EmbeddedResourceUseDependentUponConvention se establece en true ,
que es el valor predeterminado, MSBuild busca un archivo de código fuente ubicado conjuntamente y extrae un espacio de nombres y un nombre de clase
de ese archivo. Si establece EmbeddedResourceUseDependentUponConvention en false , MSBuild genera el nombre del manifiesto según el comportamiento
anterior, que combina RootNamespace y la ruta de acceso relativa del archivo.
Acción recomendada
En la mayoría de los casos, no se requiere ninguna acción por parte del desarrollador y la aplicación seguirá funcionando. Sin embargo, si este cambio
invalida la aplicación, puede:
Cambiar el código para que espere el nuevo nombre de manifiesto.
Rechazar la nueva convención de nomenclatura mediante el establecimiento de EmbeddedResourceUseDependentUponConvention en false en el archivo
del proyecto.

<PropertyGroup>
<EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Categoría
MSBuild
API afectadas
N/D
*

Redes
El valor predeterminado de HttpRequestMessage.Version ha cambiado a 1.1
El valor predeterminado de HttpRequestMessage.Version ha cambiado a 1.1
El valor predeterminado de la propiedad System.Net.Http.HttpRequestMessage.Version ha cambiado de 2.0 a 1.1.
Versión introducida
3.0
Descripción del cambio
En las versiones 1.0 a 2.0 de .NET Core, el valor predeterminado de la propiedad System.Net.Http.HttpRequestMessage.Version es 1.1. A partir de la versión
2.1 de .NET Core, se ha cambiado a 2.1.
A partir de la versión 3.0 de .NET Core, el número de versión predeterminado devuelto por la propiedad System.Net.Http.HttpRequestMessage.Version es,
una vez más, 1.1.
Acción recomendada
Actualice el código si depende de que la propiedad System.Net.Http.HttpRequestMessage.Version devuelva un valor predeterminado de 2.0.
Categoría
Redes
API afectadas
System.Net.Http.HttpRequestMessage.Version
*

Visual Basic
Microsoft.VisualBasic.Constants.vbNewLine está obsoleto
Microsoft.VisualBasic.Constants.vbNewLine está obsoleto
La constante Microsoft.VisualBasic.Constants.vbNewLine está marcada como [obsoleta] a partir de .NET Core 3.0.
Versión introducida
3.0
Descripción del cambio
A partir de .NET Core 3.0, se ha aplicado el atributo Obsolete a la constante Microsoft.VisualBasic.Constants.vbNewLine. El uso de la constante genera una
advertencia del compilador. En .NET Framework y versiones anteriores de .NET Core, no estaba marcada como obsoleta.
Este cambio se realizó para admitir Visual Basic como lenguaje para el desarrollo multiplataforma. La constante vbNewLine equivale a \r\n , la secuencia
de caracteres de nueva línea en Windows. En los sistemas basados en Unix, el carácter de nueva línea es \n .
Acción recomendada
El mensaje del atributo Obsolete para vbNewLine incluye la siguiente recomendación:
Para un retorno de carro y un avance de línea, use vbCrLf. Para la nueva línea de la plataforma actual, use Environment.NewLine.
Categoría
Visual Basic
API afectadas
Microsoft.VisualBasic.Constants.vbNewLine
**
 Novedades de .NET Core 2.2
02/11/2020 • 8 minutes to read • Edit Online

.NET Core 2.2 incluye mejoras en la implementación de aplicaciones, en el control de eventos de los servicios en
tiempo de ejecución, en la autenticación de bases de datos SQL de Azure, en el rendimiento del compilador JIT y la
inyección de código antes de la ejecución del método Main .

Nuevo modo de implementación

A partir de .NET Core 2.2, puede implementar archivos ejecutables dependientes del marco, que son archivos .exe
en lugar de .dll . Los archivos ejecutable dependientes del marco (FDE), que funcionan de forma similar a las
implementaciones dependientes del marco, todavía se basan en la presencia de una versión compartida por todo el
sistema de .NET Core para ejecutar. Su aplicación contiene solo el código y cualquier dependencia de terceros. A
diferencia de las implementaciones dependientes del marco, los FDE son específicos de la plataforma.
Este nuevo modo de implementación tiene la ventaja de compilar un archivo ejecutable en lugar de una biblioteca,
lo que significa que puede ejecutar la aplicación directamente sin invocar dotnet primero.

Principal
Control de eventos en los ser vicios en tiempo de ejecución
A menudo es posible que desee supervisar el uso que hace la aplicación de los servicios de tiempo de ejecución,
como GC, JIT y ThreadPool, para comprender cómo afectan a la aplicación. En los sistemas Windows, esto se hace
normalmente mediante la supervisión de los eventos ETW del proceso actual. Aunque este método sigue
funcionando bien, no siempre es posible usar ETW si la ejecución se realiza en un entorno con pocos privilegios o
en Linux o macOS.
A partir de .NET Core 2.2, ahora se pueden consumir eventos CoreCLR utilizando la clase
System.Diagnostics.Tracing.EventListener. Estos eventos describen el comportamiento de esos servicios en tiempo
de ejecución como la interoperabilidad, ThreadPool, JIT y GC. Estos son los mismos eventos que se exponen como
parte del proveedor ETW de CoreCLR. De esta forma, las aplicaciones pueden consumir estos eventos o usar un
mecanismo de transporte para enviarlos a un servicio de agregación de telemetría. Puede ver cómo suscribirse a
eventos en el código de ejemplo siguiente:
 internal sealed class SimpleEventListener : EventListener
{
// Called whenever an EventSource is created.
protected override void OnEventSourceCreated(EventSource eventSource)
{
// Watch for the .NET runtime EventSource and enable all of its events.
if (eventSource.Name.Equals("Microsoft-Windows-DotNETRuntime"))
{
EnableEvents(eventSource, EventLevel.Verbose, (EventKeywords)(-1));
}
}

// Called whenever an event is written.

protected override void OnEventWritten(EventWrittenEventArgs eventData)
{
// Write the contents of the event to the console.
Console.WriteLine($"ThreadID = {eventData.OSThreadId} ID = {eventData.EventId} Name =
{eventData.EventName}");
for (int i = 0; i < eventData.Payload.Count; i++)
{
string payloadString = eventData.Payload[i]?.ToString() ?? string.Empty;
Console.WriteLine($"\tName = \"{eventData.PayloadNames[i]}\" Value = \"{payloadString}\"");
}
Console.WriteLine("\n");
}
}

Además, .NET Core 2.2 agrega las dos propiedades siguientes a la clase EventWrittenEventArgs para proporcionar
información adicional sobre los eventos ETW:
EventWrittenEventArgs.OSThreadId
EventWrittenEventArgs.TimeStamp

Datos
Autenticación de AAD en bases de datos SQL de Azure con la propiedad SqlConnection.AccessToken
A partir de .NET Core 2.2, puede usarse un token de acceso emitido por Azure Active Directory para autenticarse en
una base de datos SQL de Azure. Para admitir tokens de acceso, la propiedad AccessToken se ha agregado a la clase
SqlConnection. Para aprovechar las ventajas de la autenticación de AAD, descargue la versión 4.6 del paquete
System.Data.SqlClient NuGet. Para poder usar la característica, puede obtener el valor del token de acceso mediante
la biblioteca de autenticación de Active Directory para .NET contenida en el paquete NuGet
Microsoft.IdentityModel.Clients.ActiveDirectory .

Mejoras del compilador JIT

La compilación en niveles sigue siendo una característica opcional
En .NET Core 2.1, el compilador JIT implementó una nueva tecnología de compilador, la compilación en niveles,
como característica opcional. El objetivo de la compilación en niveles es mejorar el rendimiento. Una de las tareas
importantes realizadas por el compilador JIT es optimizar la ejecución de código. Sin embargo, para las rutas de
código poco utilizadas, el compilador puede dedicar más tiempo a la optimización del código del que dedica el
tiempo de ejecución al ejecutar el código no optimizado. La compilación por niveles incluye dos fases en la
compilación JIT:
Un primer nivel , que genera código tan pronto como sea posible.
Un segundo nivel , que genera código optimizado para los métodos que se ejecutan con frecuencia. El
segundo nivel de la compilación se realiza en paralelo para mejorar el rendimiento.
Para obtener información sobre la mejora del rendimiento que puede obtenerse gracias a la compilación en niveles,
vea Announcing .NET Core 2.2 Preview 2 (Anuncio de la versión preliminar 2 de .NET Core 2.2).
En la versión preliminar 2 de .NET Core 2.2, la compilación en niveles se habilitó de forma predeterminada. Sin
embargo, hemos decidido que aún no estamos listos para habilitar la compilación en niveles de forma
predeterminada. Por tanto, en .NET Core 2.2, la compilación en nieves sigue siendo una característica opcional. Para
obtener información sobre cómo usar la compilación en niveles, vea Mejoras del compilador JIT en Novedades de
.NET Core 2.1.

Tiempo de ejecución
Inyección de código antes de ejecutar el método Main
A partir de .NET Core 2.2, puede usar un enlace de inicio para inyectar código antes de ejecutar el método Main de
la aplicación. Los enlaces de inicio permiten a un host personalizar el comportamiento de las aplicaciones una vez
que se hayan implementado sin necesidad de volver a compilar o cambiar la aplicación.
Los proveedores de hospedaje deberían definir la directiva y la configuración personalizadas, incluida la
configuración que posiblemente influya en el comportamiento de carga del punto de entrada principal, como el
comportamiento System.Runtime.Loader.AssemblyLoadContext . El enlace puede usarse para configurar la
inyección de telemetría o el seguimiento, configurar las devoluciones de llamada para el control, así como definir
otros comportamientos dependientes del entorno. El enlace es independiente del punto de entrada, por lo que no
es necesario modificar el código de usuario.
Consulte Host startup hook (Hospedaje del enlace de inicio) para obtener más información.

Vea también
Novedades de .NET Core 3.1
Novedades de ASP.NET Core 2.2
Novedades de EF Core 2.2
 Novedades de .NET Core 2.1
18/12/2020 • 21 minutes to read • Edit Online

.NET Core 2.1 incluye mejoras y características nuevas en las áreas siguientes:
Herramientas
Puesta al día
Implementación
Paquete de compatibilidad de Windows
Mejoras de la compilación JIT
Cambios en la API

Tooling
El SDK de .NET Core 2.1 (v 2.1.300), el conjunto de herramientas incluidas con .NET Core 2.1, incluye los siguientes
cambios y mejoras:
Mejoras en el rendimiento de la compilación
Un aspecto fundamental de .NET Core 2.1 es mejorar el rendimiento del tiempo de compilación, especialmente
para compilaciones incrementales. Estas mejoras de rendimiento se aplican a las compilaciones de línea de
comandos mediante dotnet build y a las compilaciones de Visual Studio. Algunas áreas individuales de mejora
incluyen:
Para la resolución de activos del paquete, solo se resuelven los activos utilizados por una compilación en
lugar de todos los activos.
Almacenamiento en caché de referencias de ensamblado.
Uso de servidores de compilación de SDK de larga ejecución, que son procesos que se extienden a través de
invocaciones dotnet build individuales. Eliminan la necesidad de compilar mediante JIT grandes bloques
de código cada vez que se ejecuta dotnet build . Los procesos del servidor de compilación se pueden
terminar automáticamente con el siguiente comando:

dotnet buildserver shutdown

Nuevos comandos de la CLI

Una serie de herramientas que estaban disponibles solo en función del proyecto mediante
DotnetCliToolReference ahora están disponibles como parte del SDK de .NET Core. Estas herramientas incluyen:

dotnet watch proporciona un monitor del sistema de archivos que espera que un archivo cambie antes de
ejecutar un conjunto designado de comandos. Por ejemplo, el siguiente comando vuelve a generar
automáticamente el proyecto actual y genera un resultado detallado cada vez que cambie un archivo en él:

dotnet watch -- --verbose build

Tenga en cuenta que la opción -- precede a la opción --verbose . Delimita las opciones pasadas
directamente al comando dotnet watch de los argumentos que se pasan al proceso dotnet secundario.
Sin él, la opción --verbose se aplica al comando dotnet watch , no al comando dotnet build .
 Para más información, consulte Desarrollar aplicaciones ASP.NET Core con un monitor de archivos.
dotnet dev-certs genera y administra los certificados que se usan durante el desarrollo de aplicaciones de
ASP.NET Core.
dotnet user-secrets administra los secretos en un almacén de secretos de usuario en aplicaciones de
ASP.NET Core.
dotnet sql-cachecrea una tabla e índices en una base de datos de Microsoft SQL Server que se usará para
el almacenamiento en caché distribuido.
dotnet ef es una herramienta para administrar bases de datos, objetos DbContext y migraciones en las
aplicaciones de Entity Framework Core. Para obtener más información, vea EF Core .NET Command-line
Tools (Herramienta de la línea de comandos de .NET de EF Core).
Herramientas globales
.NET core 2.1 es compatible con Herramientas globales: es decir, las herramientas personalizadas que están
disponibles globalmente desde la línea de comandos. El modelo de extensibilidad en versiones previas de
.NET Core permitió que las herramientas personalizadas estuvieran disponibles en cada proyecto solo utilizando
DotnetCliToolReference .

Para instalar una herramienta global, use el comando dotnet tool install. Por ejemplo:

dotnet tool install -g dotnetsay

Una vez instalada, la herramienta se puede ejecutar desde la línea de comandos especificando el nombre de la
herramienta. Para más información, vea Información general sobre las herramientas globales de .NET Core.
Administración de herramientas con el comando dotnet tool

En el SDK de .NET Core 2.1, todas las operaciones de herramientas utilizan el comando dotnet tool . Están
disponibles las siguientes opciones:
dotnet tool install para instalar una herramienta.
dotnet tool update para desinstalar y reinstalar una herramienta, lo cual la actualiza eficazmente.
dotnet tool list para enumerar las herramientas instaladas actualmente.
dotnet tool uninstall para desinstalar las herramientas instaladas actualmente.

Puesta al día
Todas las aplicaciones de .NET Core a partir de .NET Core 2.0 se ponen al día automáticamente a la versión
secundaria más reciente instalada en un sistema.
A partir de .NET Core 2.0, si la versión de .NET Core que se creó una aplicación no está presente en tiempo de
ejecución, la aplicación se ejecuta automáticamente en la versión secundaria instalada más reciente de .NET Core.
En otras palabras, si una aplicación se compila con .NET Core 2.0, y .NET Core 2.0 no está presente en el sistema
host pero sí lo está .NET Core 2.1, la aplicación se ejecuta con .NET Core 2.1.

IMPORTANT
Este comportamiento de puesta al día no se aplica para versiones preliminares. De forma predeterminada, tampoco se aplica
a las versiones principales, pero se puede cambiar con las opciones siguientes.

Este comportamiento se puede modificar si se cambia la configuración para la puesta al día en los marcos de
trabajo compartidos que no sean candidatos. Los valores disponibles son los siguientes:
0 : se deshabilita el comportamiento de puesta al día de las versiones secundarias. Con este valor, una
aplicación compilada para .NET Core 2.0.0 se pondrá al día a .NET Core 2.0.1, pero no a .NET Core 2.2.0 ni .NET
Core 3.0.0.
1 : se habilita el comportamiento de puesta al día de las versiones secundarias. Este es el valor
predeterminado de la opción. Con este valor, una aplicación compilada para .NET Core 2.0.0 se pondrá al día a
.NET Core 2.0.1 o .NET Core 2.2.0, en función de la versión instalada, pero no a .NET Core 3.0.0.
2 : se habilita el comportamiento de puesta al día de las versiones principales y secundarias. Si se establece, se
tienen en cuenta incluso versiones principales diferentes, por lo que una aplicación compilada para .NET Core
2.0.0 se pondrá al día a .NET Core 3.0.0.
Esta configuración se puede modificar de estas tres maneras:
Si se establece la variable de entorno DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX en el valor deseado.
Agregue la línea siguiente con el valor deseado al archivo .runtimeconfig.json:

"rollForwardOnNoCandidateFx" : 0

Cuando se usa la CLI de .NET Core, si se agrega la opción siguiente con el valor deseado a un comando de
.NET Core como run :

dotnet run --rollForwardOnNoCandidateFx=0

La puesta al día de versiones de revisión es independiente de esta configuración y se realiza después de aplicar la
puesta al día de cualquier versión principal o secundaria posible.

Implementación
Mantenimiento de aplicaciones independientes
dotnet publish ahora publica aplicaciones independientes con una versión en tiempo de ejecución con
mantenimiento. Cuando publica una aplicación independiente con el SDK 2.1 de .NET Core (v. 2.1.300), su
aplicación incluye la última versión de tiempo de ejecución con mantenimiento conocida por ese SDK. Cuando
actualice a la versión más reciente del SDK, publicará con la versión más reciente del tiempo de ejecución de
.NET Core. Esto se aplica para tiempos de ejecución de .NET Core 1.0 y versiones posteriores.
La publicación independiente se basa en las versiones del tiempo de ejecución en NuGet.org. No necesita tener el
tiempo de ejecución con mantenimiento en su máquina.
Con el SDK de .NET Core 2.0, las aplicaciones independientes se publican con el tiempo de ejecución de .NET Core
2.0.0 a menos que se especifique una versión diferente a través de la propiedad RuntimeFrameworkVersion . Con
este nuevo comportamiento, ya no será necesario configurar esta propiedad para seleccionar una versión de
tiempo de ejecución más alta para una aplicación independiente. El enfoque más sencillo a partir de ahora es
publicar siempre con el SDK de .NET Core 2.1 (v. 2.1.300).
Para obtener más información, vea Puesta al día del runtime de implementación autocontenida.

Paquete de compatibilidad de Windows

Al trasladar el código existente de .NET Framework a .NET Core, puede usar el paquete de compatibilidad de
Windows. Esto proporciona acceso a 20 000 API más de las que están disponibles en .NET Core. Estas API incluyen
tipos en el espacio de nombres System.Drawing, la clase EventLog, WMI, contadores de rendimiento, servicios de
Windows y los tipos y miembros de Registro de Windows.
Mejoras del compilador JIT
.NET Core incorpora una nueva tecnología de compilador JIT denominada compilación por niveles (también
conocida como optimización adaptable) que puede mejorar significativamente el rendimiento. La compilación por
niveles es una configuración opcional.
Una de las tareas importantes realizadas por el compilador JIT es optimizar la ejecución de código. Sin embargo,
para las rutas de código poco utilizadas, el compilador puede dedicar más tiempo a la optimización del código del
que dedica el tiempo de ejecución a ejecutar el código no optimizado. La compilación por niveles incluye dos fases
en la compilación JIT:
Un primer nivel , que genera código tan pronto como sea posible.
Un segundo nivel , que genera código optimizado para los métodos que se ejecutan con frecuencia. El
segundo nivel de la compilación se realiza en paralelo para mejorar el rendimiento.
Puede participar en la compilación en niveles de cualquiera de estas dos maneras.
Para utilizar la compilación en capas en todos los proyectos que utilizan el SDK de .NET Core 2.1, establezca
la variable de entorno siguiente:

COMPlus_TieredCompilation="1"

Para utilizar la compilación por niveles por proyecto, agregue la propiedad <TieredCompilation> a la
sección <PropertyGroup> del archivo de proyecto de MSBuild, como se muestra en el ejemplo siguiente:

<PropertyGroup>
<!-- other property definitions -->

<TieredCompilation>true</TieredCompilation>
</PropertyGroup>

Cambios en la API
Span<T> y Memory<T>

.NET Core 2.1 incluye algunos tipos nuevos que hacen que trabajar con matrices y otros tipos de memoria sea
mucho más eficiente. Estos nuevos tipos incluyen:
System.Span<T> y System.ReadOnlySpan<T>.
System.Memory<T> y System.ReadOnlyMemory<T>.
Sin estos tipos, al pasar tales elementos como una porción de una matriz o una sección de un búfer de memoria,
debe hacer una copia de una parte de los datos antes de pasarlo a un método. Estos tipos proporcionan una vista
virtual de los datos que elimina la necesidad de ejecutar operaciones adicionales de copia y asignación de
memoria.
En el ejemplo siguiente se usa una instancia de Span<T> y Memory<T> para proporcionar una vista virtual de 10
elementos de una matriz.
 using System;

class Program
{
static void Main()
{
int[] numbers = new int[100];
for (int i = 0; i < 100; i++)
{
numbers[i] = i * 2;
}

var part = new Span<int>(numbers, start: 10, length: 10);

foreach (var value in part)
Console.Write($"{value} ");
}
}
// The example displays the following output:
// 20 22 24 26 28 30 32 34 36 38

Module Program
Sub Main()
Dim numbers As Integer() = New Integer(99) {}

For i As Integer = 0 To 99
numbers(i) = i * 2
Next

Dim part = New Memory(Of Integer)(numbers, start:=10, length:=10)

For Each value In part.Span

Console.Write($"{value} ")
Next
End Sub
End Module
' The example displays the following output:
' 20 22 24 26 28 30 32 34 36 38

Compresión de Brotli
.NET Core 2.1 agrega compatibilidad con la compresión y descompresión de Brotli. Brotli es un algoritmo de
compresión sin pérdida de datos de uso general que se define en RFC 7932 y es compatible con la mayoría de los
exploradores web y servidores web principales. Puede usar la clase System.IO.Compression.BrotliStream basada
en secuencias o las clases System.IO.Compression.BrotliEncoder y System.IO.Compression.BrotliDecoder basadas
en intervalos de alto rendimiento. En el ejemplo siguiente se muestra la compresión con la clase BrotliStream:

public static Stream DecompressWithBrotli(Stream toDecompress)

{
MemoryStream decompressedStream = new MemoryStream();
using (BrotliStream decompressionStream = new BrotliStream(toDecompress, CompressionMode.Decompress))
{
decompressionStream.CopyTo(decompressedStream);
}
decompressedStream.Position = 0;
return decompressedStream;
}
 Public Function DecompressWithBrotli(toDecompress As Stream) As Stream
Dim decompressedStream As New MemoryStream()
Using decompressionStream As New BrotliStream(toDecompress, CompressionMode.Decompress)
decompressionStream.CopyTo(decompressedStream)
End Using
decompressedStream.Position = 0
Return decompressedStream
End Function

El comportamiento de BrotliStream es el mismo que DeflateStream y GZipStream, lo que facilita la conversión de

código que llama a estas API a BrotliStream.
Nuevas API de criptografía y mejoras de criptografía
.NET Core 2.1 incluye numerosas mejoras para las API de criptografía:
System.Security.Cryptography.Pkcs.SignedCms está disponible en el paquete
System.Security.Cryptography.Pkcs. La implementación es la misma que la clase SignedCms en .NET
Framework.
Las nuevas sobrecargas de los métodos X509Certificate.GetCertHash y X509Certificate.GetCertHashString
aceptan un identificador de algoritmo hash para permitir que los autores de la llamada obtengan valores de
huella digital de certificado utilizando algoritmos distintos de SHA-1.
Las nuevas API de criptografía basadas en Span<T> están disponibles para crear valores hash, HMAC,
generación de números aleatorios criptográficos, generación de firmas asimétricas, procesamiento de
firmas asimétricas y cifrado RSA.
El rendimiento de System.Security.Cryptography.Rfc2898DeriveBytes mejoró aproximadamente un 15 %
mediante el uso de una implementación basada en Span<T>.
La nueva clase System.Security.Cryptography.CryptographicOperations incluye dos nuevos métodos:
FixedTimeEquals tarda una cantidad fija de tiempo en devolver dos entradas cualesquiera de la
misma longitud, siendo así adecuada para su uso en la comprobación criptográfica para evitar
contribuir al control de tiempo de la información en el canal.
ZeroMemory es una rutina de borrado de memoria que no se puede optimizar.
El método estático RandomNumberGenerator.Fill rellena un Span<T> con valores aleatorios.
System.Security.Cryptography.Pkcs.EnvelopedCms ahora es compatible con Linux y macOS.
La curva elíptica Diffie-Hellman (ECDH) ahora está disponible en la familia de clases
System.Security.Cryptography.ECDiffieHellman. El área expuesta es la misma que en .NET Framework.
La instancia devuelta por RSA.Create puede cifrar o descifrar con OAEP con un resumen de SHA-2, así como
generar o validar firmas mediante RSA-PSS.
Mejoras en los sockets
.NET Core incluye un nuevo tipo, System.Net.Http.SocketsHttpHandler y una reescritura
System.Net.Http.HttpMessageHandler, que forman la base de las API de red de nivel superior.
System.Net.Http.SocketsHttpHandler, por ejemplo, es la base de la implementación HttpClient. En versiones
anteriores de .NET Core, las API de nivel superior se basaban en implementaciones de redes nativas.
La implementación de sockets introducida en .NET Core 2.1 presenta una serie de ventajas:
Una mejora significativa del rendimiento en comparación con la implementación anterior.
Eliminación de las dependencias de plataforma, lo que simplifica la implementación y el mantenimiento.
 Comportamiento coherente en todas las plataformas de .NET Core.
SocketsHttpHandler es la implementación predeterminada en .NET Core 2.1. Sin embargo, puede configurar su
aplicación para usar la clase anterior HttpClientHandler llamando al método AppContext.SetSwitch:

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", False)

También puede usar una variable de entorno para optar por no usar implementaciones de sockets basadas en
SocketsHttpHandler. Para ello, configure DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER en false o en 0.
En Windows, también puede optar por usar System.Net.Http.WinHttpHandler, que se basa en una implementación
nativa, o la clase SocketsHttpHandler pasando una instancia de la clase al constructor HttpClient.
En Linux y macOS, solo se puede configurar HttpClient para cada proceso. En Linux, deberá implementar libcurl si
desea usar la antigua implementación de HttpClient. (Se instala con .NET Core 2.0).
Cambios importantes
Para obtener más información sobre los cambios importantes, vea Cambios importantes para la migración de la
versión 2.0 a la 2.1.

Vea también
Novedades de .NET Core 3.1
Novedades de EF Core 2.1
Novedades de ASP.NET Core 2.1
 Cambios importantes en .NET Core 2.1
18/12/2020 • 7 minutes to read • Edit Online

Si va a migrar a la versión 2.1 de .NET Core, es posible que los cambios importantes de este artículo afecten a la
aplicación.

Bibliotecas de Core .NET

Se han agregado campos privados a tipos struct integrados
Versiones de OpenSSL en macOS
Campos privados agregados a tipos struct integrados
Se han agregado campos privados a algunos tipos de struct en ensamblados de referencia. Como resultado, en C#,
siempre se deben crear instancias de esos structs mediante el operador new o un literal predeterminado.
Descripción del cambio
En .NET Core 2.0 y versiones anteriores, se podría crear una instancia de algunos tipos de struct proporcionados,
por ejemplo, ConsoleKeyInfo, sin usar el operador new ni un literal predeterminado en C#. Esto se debe a que los
ensamblados de referencia que usa el compilador de C# no contenían los campos privados de los structs. Todos los
campos privados de los tipos de struct .NET se agregan a los ensamblados de referencia a partir de .NET Core 2.1.
Por ejemplo, el siguiente código de C# se compila en .Net Core 2.0, pero no en .NET Core 2.1:

ConsoleKeyInfo key; // Struct type

if (key.ToString() == "y")
{
Console.WriteLine("Yes!");
}

En .NET Core 2.1, el código anterior genera el siguiente error del compilador: CS0165 - Uso de la variable
local no asignada "key"
Versión introducida
2.1
Acción recomendada
Cree instancias de tipos de struct mediante el operador new o el literal predeterminado.
Por ejemplo:

ConsoleKeyInfo key = new ConsoleKeyInfo(); // Struct type.

if (key.ToString() == "y")
Console.WriteLine("Yes!");

ConsoleKeyInfo key = default; // Struct type.

if (key.ToString() == "y")
Console.WriteLine("Yes!");

Categoría
Bibliotecas de Core .NET
API afectadas
System.ArraySegment<T>.Enumerator
System.ArraySegment<T>
System.Boolean
System.Buffers.MemoryHandle
System.Buffers.StandardFormat
System.Byte
System.Char
System.Collections.DictionaryEntry
System.Collections.Generic.Dictionary<TKey,TValue>.Enumerator
System.Collections.Generic.Dictionary<TKey,TValue>.KeyCollection.Enumerator
System.Collections.Generic.Dictionary<TKey,TValue>.ValueCollection.Enumerator
System.Collections.Generic.HashSet<T>.Enumerator
System.Collections.Generic.KeyValuePair<TKey,TValue>
System.Collections.Generic.LinkedList<T>.Enumerator
System.Collections.Generic.List<T>.Enumerator
System.Collections.Generic.Queue<T>.Enumerator
System.Collections.Generic.SortedDictionary<TKey,TValue>.Enumerator
System.Collections.Generic.SortedDictionary<TKey,TValue>.KeyCollection.Enumerator
System.Collections.Generic.SortedDictionary<TKey,TValue>.ValueCollection.Enumerator
System.Collections.Generic.SortedSet<T>.Enumerator
System.Collections.Generic.Stack<T>.Enumerator
System.Collections.Immutable.ImmutableArray<T>.Enumerator
System.Collections.Immutable.ImmutableArray<T>
System.Collections.Immutable.ImmutableDictionary<TKey,TValue>.Enumerator
System.Collections.Immutable.ImmutableHashSet<T>.Enumerator
System.Collections.Immutable.ImmutableList<T>.Enumerator
System.Collections.Immutable.ImmutableQueue<T>.Enumerator
System.Collections.Immutable.ImmutableSortedDictionary<TKey,TValue>.Enumerator
System.Collections.Immutable.ImmutableSortedSet<T>.Enumerator
System.Collections.Immutable.ImmutableStack<T>.Enumerator
System.Collections.Specialized.BitVector32.Section
System.Collections.Specialized.BitVector32
LazyMemberInfo
System.ComponentModel.Design.Serialization.MemberRelationship
System.ConsoleKeyInfo
System.Data.SqlTypes.SqlBinary
System.Data.SqlTypes.SqlBoolean
System.Data.SqlTypes.SqlByte
System.Data.SqlTypes.SqlDateTime
System.Data.SqlTypes.SqlDecimal
System.Data.SqlTypes.SqlDouble
System.Data.SqlTypes.SqlGuid
System.Data.SqlTypes.SqlInt16
System.Data.SqlTypes.SqlInt32
System.Data.SqlTypes.SqlInt64
System.Data.SqlTypes.SqlMoney
System.Data.SqlTypes.SqlSingle
System.Data.SqlTypes.SqlString
System.DateTime
System.DateTimeOffset
System.Decimal
System.Diagnostics.CounterSample
System.Diagnostics.SymbolStore.SymbolToken
System.Diagnostics.Tracing.EventSource.EventData
System.Diagnostics.Tracing.EventSourceOptions
System.Double
System.Drawing.CharacterRange
System.Drawing.Point
System.Drawing.PointF
System.Drawing.Rectangle
System.Drawing.RectangleF
System.Drawing.Size
System.Drawing.SizeF
System.Guid
System.HashCode
System.Int16
System.Int32
System.Int64
System.IntPtr
System.IO.Pipelines.FlushResult
System.IO.Pipelines.ReadResult
System.IO.WaitForChangedResult
System.Memory<T>
System.ModuleHandle
System.Net.Security.SslApplicationProtocol
System.Net.Sockets.IPPacketInformation
System.Net.Sockets.SocketInformation
System.Net.Sockets.UdpReceiveResult
System.Net.WebSockets.ValueWebSocketReceiveResult
System.Nullable<T>
System.Numerics.BigInteger
System.Numerics.Complex
System.Numerics.Vector<T>
System.ReadOnlyMemory<T>
System.ReadOnlySpan<T>.Enumerator
System.ReadOnlySpan<T>
System.Reflection.CustomAttributeNamedArgument
System.Reflection.CustomAttributeTypedArgument
System.Reflection.Emit.Label
System.Reflection.Emit.OpCode
System.Reflection.Metadata.ArrayShape
System.Reflection.Metadata.AssemblyDefinition
System.Reflection.Metadata.AssemblyDefinitionHandle
System.Reflection.Metadata.AssemblyFile
System.Reflection.Metadata.AssemblyFileHandle
System.Reflection.Metadata.AssemblyFileHandleCollection.Enumerator
System.Reflection.Metadata.AssemblyFileHandleCollection
System.Reflection.Metadata.AssemblyReference
System.Reflection.Metadata.AssemblyReferenceHandle
System.Reflection.Metadata.AssemblyReferenceHandleCollection.Enumerator
System.Reflection.Metadata.AssemblyReferenceHandleCollection
System.Reflection.Metadata.Blob
System.Reflection.Metadata.BlobBuilder.Blobs
System.Reflection.Metadata.BlobContentId
System.Reflection.Metadata.BlobHandle
System.Reflection.Metadata.BlobReader
System.Reflection.Metadata.BlobWriter
System.Reflection.Metadata.Constant
System.Reflection.Metadata.ConstantHandle
System.Reflection.Metadata.CustomAttribute
System.Reflection.Metadata.CustomAttributeHandle
System.Reflection.Metadata.CustomAttributeHandleCollection.Enumerator
System.Reflection.Metadata.CustomAttributeHandleCollection
System.Reflection.Metadata.CustomAttributeNamedArgument<TType>
System.Reflection.Metadata.CustomAttributeTypedArgument<TType>
System.Reflection.Metadata.CustomAttributeValue<TType>
System.Reflection.Metadata.CustomDebugInformation
System.Reflection.Metadata.CustomDebugInformationHandle
System.Reflection.Metadata.CustomDebugInformationHandleCollection.Enumerator
System.Reflection.Metadata.CustomDebugInformationHandleCollection
System.Reflection.Metadata.DeclarativeSecurityAttribute
System.Reflection.Metadata.DeclarativeSecurityAttributeHandle
System.Reflection.Metadata.DeclarativeSecurityAttributeHandleCollection.Enumerator
System.Reflection.Metadata.DeclarativeSecurityAttributeHandleCollection
System.Reflection.Metadata.Document
System.Reflection.Metadata.DocumentHandle
System.Reflection.Metadata.DocumentHandleCollection.Enumerator
System.Reflection.Metadata.DocumentHandleCollection
System.Reflection.Metadata.DocumentNameBlobHandle
System.Reflection.Metadata.Ecma335.ArrayShapeEncoder
System.Reflection.Metadata.Ecma335.BlobEncoder
System.Reflection.Metadata.Ecma335.CustomAttributeArrayTypeEncoder
System.Reflection.Metadata.Ecma335.CustomAttributeElementTypeEncoder
System.Reflection.Metadata.Ecma335.CustomAttributeNamedArgumentsEncoder
System.Reflection.Metadata.Ecma335.CustomModifiersEncoder
System.Reflection.Metadata.Ecma335.EditAndContinueLogEntry
System.Reflection.Metadata.Ecma335.ExceptionRegionEncoder
System.Reflection.Metadata.Ecma335.FixedArgumentsEncoder
System.Reflection.Metadata.Ecma335.GenericTypeArgumentsEncoder
System.Reflection.Metadata.Ecma335.InstructionEncoder
System.Reflection.Metadata.Ecma335.LabelHandle
System.Reflection.Metadata.Ecma335.LiteralEncoder
System.Reflection.Metadata.Ecma335.LiteralsEncoder
System.Reflection.Metadata.Ecma335.LocalVariablesEncoder
System.Reflection.Metadata.Ecma335.LocalVariableTypeEncoder
System.Reflection.Metadata.Ecma335.MethodBodyStreamEncoder.MethodBody
System.Reflection.Metadata.Ecma335.MethodBodyStreamEncoder
System.Reflection.Metadata.Ecma335.MethodSignatureEncoder
System.Reflection.Metadata.Ecma335.NamedArgumentsEncoder
System.Reflection.Metadata.Ecma335.NamedArgumentTypeEncoder
System.Reflection.Metadata.Ecma335.NameEncoder
System.Reflection.Metadata.Ecma335.ParametersEncoder
System.Reflection.Metadata.Ecma335.ParameterTypeEncoder
System.Reflection.Metadata.Ecma335.PermissionSetEncoder
System.Reflection.Metadata.Ecma335.ReturnTypeEncoder
System.Reflection.Metadata.Ecma335.ScalarEncoder
System.Reflection.Metadata.Ecma335.SignatureDecoder<TType,TGenericContext>
System.Reflection.Metadata.Ecma335.SignatureTypeEncoder
System.Reflection.Metadata.Ecma335.VectorEncoder
System.Reflection.Metadata.EntityHandle
System.Reflection.Metadata.EventAccessors
System.Reflection.Metadata.EventDefinition
System.Reflection.Metadata.EventDefinitionHandle
System.Reflection.Metadata.EventDefinitionHandleCollection.Enumerator
System.Reflection.Metadata.EventDefinitionHandleCollection
System.Reflection.Metadata.ExceptionRegion
System.Reflection.Metadata.ExportedType
System.Reflection.Metadata.ExportedTypeHandle
System.Reflection.Metadata.ExportedTypeHandleCollection.Enumerator
System.Reflection.Metadata.ExportedTypeHandleCollection
System.Reflection.Metadata.FieldDefinition
System.Reflection.Metadata.FieldDefinitionHandle
System.Reflection.Metadata.FieldDefinitionHandleCollection.Enumerator
System.Reflection.Metadata.FieldDefinitionHandleCollection
System.Reflection.Metadata.GenericParameter
System.Reflection.Metadata.GenericParameterConstraint
System.Reflection.Metadata.GenericParameterConstraintHandle
System.Reflection.Metadata.GenericParameterConstraintHandleCollection.Enumerator
System.Reflection.Metadata.GenericParameterConstraintHandleCollection
System.Reflection.Metadata.GenericParameterHandle
System.Reflection.Metadata.GenericParameterHandleCollection.Enumerator
System.Reflection.Metadata.GenericParameterHandleCollection
System.Reflection.Metadata.GuidHandle
System.Reflection.Metadata.Handle
System.Reflection.Metadata.ImportDefinition
System.Reflection.Metadata.ImportDefinitionCollection.Enumerator
System.Reflection.Metadata.ImportDefinitionCollection
System.Reflection.Metadata.ImportScope
System.Reflection.Metadata.ImportScopeCollection.Enumerator
System.Reflection.Metadata.ImportScopeCollection
System.Reflection.Metadata.ImportScopeHandle
System.Reflection.Metadata.InterfaceImplementation
System.Reflection.Metadata.InterfaceImplementationHandle
System.Reflection.Metadata.InterfaceImplementationHandleCollection.Enumerator
System.Reflection.Metadata.InterfaceImplementationHandleCollection
System.Reflection.Metadata.LocalConstant
System.Reflection.Metadata.LocalConstantHandle
System.Reflection.Metadata.LocalConstantHandleCollection.Enumerator
System.Reflection.Metadata.LocalConstantHandleCollection
System.Reflection.Metadata.LocalScope
System.Reflection.Metadata.LocalScopeHandle
System.Reflection.Metadata.LocalScopeHandleCollection.ChildrenEnumerator
System.Reflection.Metadata.LocalScopeHandleCollection.Enumerator
System.Reflection.Metadata.LocalScopeHandleCollection
System.Reflection.Metadata.LocalVariable
System.Reflection.Metadata.LocalVariableHandle
System.Reflection.Metadata.LocalVariableHandleCollection.Enumerator
System.Reflection.Metadata.LocalVariableHandleCollection
System.Reflection.Metadata.ManifestResource
System.Reflection.Metadata.ManifestResourceHandle
System.Reflection.Metadata.ManifestResourceHandleCollection.Enumerator
System.Reflection.Metadata.ManifestResourceHandleCollection
System.Reflection.Metadata.MemberReference
System.Reflection.Metadata.MemberReferenceHandle
System.Reflection.Metadata.MemberReferenceHandleCollection.Enumerator
System.Reflection.Metadata.MemberReferenceHandleCollection
System.Reflection.Metadata.MetadataStringComparer
System.Reflection.Metadata.MethodDebugInformation
System.Reflection.Metadata.MethodDebugInformationHandle
System.Reflection.Metadata.MethodDebugInformationHandleCollection.Enumerator
System.Reflection.Metadata.MethodDebugInformationHandleCollection
System.Reflection.Metadata.MethodDefinition
System.Reflection.Metadata.MethodDefinitionHandle
System.Reflection.Metadata.MethodDefinitionHandleCollection.Enumerator
System.Reflection.Metadata.MethodDefinitionHandleCollection
System.Reflection.Metadata.MethodImplementation
System.Reflection.Metadata.MethodImplementationHandle
System.Reflection.Metadata.MethodImplementationHandleCollection.Enumerator
System.Reflection.Metadata.MethodImplementationHandleCollection
System.Reflection.Metadata.MethodImport
System.Reflection.Metadata.MethodSignature<TType>
System.Reflection.Metadata.MethodSpecification
System.Reflection.Metadata.MethodSpecificationHandle
System.Reflection.Metadata.ModuleDefinition
System.Reflection.Metadata.ModuleDefinitionHandle
System.Reflection.Metadata.ModuleReference
System.Reflection.Metadata.ModuleReferenceHandle
System.Reflection.Metadata.NamespaceDefinition
System.Reflection.Metadata.NamespaceDefinitionHandle
System.Reflection.Metadata.Parameter
System.Reflection.Metadata.ParameterHandle
System.Reflection.Metadata.ParameterHandleCollection.Enumerator
System.Reflection.Metadata.ParameterHandleCollection
System.Reflection.Metadata.PropertyAccessors
System.Reflection.Metadata.PropertyDefinition
System.Reflection.Metadata.PropertyDefinitionHandle
System.Reflection.Metadata.PropertyDefinitionHandleCollection.Enumerator
System.Reflection.Metadata.PropertyDefinitionHandleCollection
System.Reflection.Metadata.ReservedBlob<THandle>
System.Reflection.Metadata.SequencePoint
System.Reflection.Metadata.SequencePointCollection.Enumerator
System.Reflection.Metadata.SequencePointCollection
System.Reflection.Metadata.SignatureHeader
System.Reflection.Metadata.StandaloneSignature
System.Reflection.Metadata.StandaloneSignatureHandle
System.Reflection.Metadata.StringHandle
System.Reflection.Metadata.TypeDefinition
System.Reflection.Metadata.TypeDefinitionHandle
System.Reflection.Metadata.TypeDefinitionHandleCollection.Enumerator
System.Reflection.Metadata.TypeDefinitionHandleCollection
System.Reflection.Metadata.TypeLayout
System.Reflection.Metadata.TypeReference
System.Reflection.Metadata.TypeReferenceHandle
System.Reflection.Metadata.TypeReferenceHandleCollection.Enumerator
System.Reflection.Metadata.TypeReferenceHandleCollection
System.Reflection.Metadata.TypeSpecification
System.Reflection.Metadata.TypeSpecificationHandle
System.Reflection.Metadata.UserStringHandle
System.Reflection.ParameterModifier
System.Reflection.PortableExecutable.CodeViewDebugDirectoryData
System.Reflection.PortableExecutable.DebugDirectoryEntry
System.Reflection.PortableExecutable.PEMemoryBlock
System.Reflection.PortableExecutable.SectionHeader
System.Runtime.CompilerServices.AsyncTaskMethodBuilder<TResult>
System.Runtime.CompilerServices.AsyncTaskMethodBuilder
System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder<TResult>
System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder
System.Runtime.CompilerServices.AsyncVoidMethodBuilder
System.Runtime.CompilerServices.ConfiguredTaskAwaitable<TResult>.ConfiguredTaskAwaiter
System.Runtime.CompilerServices.ConfiguredTaskAwaitable<TResult>
System.Runtime.CompilerServices.ConfiguredTaskAwaitable.ConfiguredTaskAwaiter
System.Runtime.CompilerServices.ConfiguredTaskAwaitable
System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable<TResult>
System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable<TResult>.ConfiguredValueTaskAwaiter
System.Runtime.CompilerServices.TaskAwaiter<TResult>
System.Runtime.CompilerServices.TaskAwaiter
System.Runtime.CompilerServices.ValueTaskAwaiter<TResult>
System.Runtime.CompilerServices.ValueTaskAwaiter<TResult>
System.Runtime.InteropServices.ArrayWithOffset
System.Runtime.InteropServices.GCHandle
System.Runtime.InteropServices.HandleRef
System.Runtime.InteropServices.OSPlatform
System.Runtime.InteropServices.WindowsRuntime.EventRegistrationToken
System.Runtime.Serialization.SerializationEntry
System.Runtime.Serialization.StreamingContext
System.RuntimeArgumentHandle
System.RuntimeFieldHandle
System.RuntimeMethodHandle
System.RuntimeTypeHandle
System.SByte
System.Security.Cryptography.CngProperty
System.Security.Cryptography.ECCurve
System.Security.Cryptography.HashAlgorithmName
System.Security.Cryptography.X509Certificates.X509ChainStatus
System.Security.Cryptography.Xml.X509IssuerSerial
System.ServiceProcess.SessionChangeDescription
System.Single
System.Span<T>.Enumerator
System.Span<T>
System.Threading.AsyncFlowControl
System.Threading.AsyncLocalValueChangedArgs<T>
System.Threading.CancellationToken
System.Threading.CancellationTokenRegistration
System.Threading.LockCookie
System.Threading.SpinLock
System.Threading.SpinWait
System.Threading.Tasks.Dataflow.DataflowMessageHeader
System.Threading.Tasks.ParallelLoopResult
System.Threading.Tasks.ValueTask<TResult>
System.TimeSpan
 System.TimeZoneInfo.TransitionTime
System.Transactions.TransactionOptions
System.TypedReference
System.TypedReference
System.UInt16
System.UInt32
System.UInt64
System.UIntPtr
System.Windows.Forms.ColorDialog.Color
System.Windows.Media.Animation.KeyTime
System.Windows.Media.Animation.RepeatBehavior
System.Xml.Serialization.XmlDeserializationEvents
Windows.Foundation.Point
Windows.Foundation.Rect
Windows.Foundation.Size
Windows.UI.Color
Windows.UI.Xaml.Controls.Primitives.GeneratorPosition
Windows.UI.Xaml.CornerRadius
Windows.UI.Xaml.Duration
Windows.UI.Xaml.GridLength
Windows.UI.Xaml.Media.Matrix
Windows.UI.Xaml.Media.Media3D.Matrix3D
Windows.UI.Xaml.Thickness

Versiones de OpenSSL en macOS

Ahora, los runtime de .NET Core 3.0 y versiones posteriores en macOS prefieren las versiones de OpenSSL 1.1.x a
las versiones de OpenSSL 1.0.x en los tipos AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl,
ECDsaOpenSsl, RSAOpenSsl y SafeEvpPKeyHandle.
Ahora, el runtime de .NET Core 2.1 es compatible con las versiones de OpenSSL 1.1.x, pero siguen siendo
preferibles las versiones de OpenSSL 1.0.x.
Descripción del cambio
Antes, el runtime de .NET Core usaba versiones de OpenSSL 1.0.x en macOS para en los tipos que interactúan con
OpenSSL. La versión más reciente de OpenSSL 1.0.x, OpenSSL 1.0.2, ya no se admite. Para mantener los tipos que
usan OpenSSL en versiones compatibles de OpenSSL, los runtime de .NET Core 3.0 y versiones posteriores usan
ahora las versiones más recientes de OpenSSL en macOS.
Con este cambio, el comportamiento de los runtime de .NET Core en macOS es el siguiente:
Los runtime de .NET Core 3.0 y versiones posteriores usan OpenSSL 1.1.x (si está disponible) y revierten a
OpenSSL 1.0.x solo si no hay disponible ninguna versión 1.1.x.
En el caso de los autores de llamada que usen los tipos de interoperabilidad de OpenSSL con P/Invoke
personalizados, siga las instrucciones de los comentarios sobre SafeEvpPKeyHandle.OpenSslVersion. La
aplicación se puede bloquear si no se comprueba el valor de OpenSslVersion.
Los runtime de .NET Core 2.1 usan OpenSSL 1.0.x (si está disponible) y revierten a OpenSSL 1.1.x si no hay
disponible ninguna versión 1.0.x.
El runtime 2.1 prefiere la versión anterior de OpenSSL porque la propiedad
SafeEvpPKeyHandle.OpenSslVersion no existe en .NET Core 2.1, por lo que la versión de OpenSSL no se
 puede determinar de forma confiable en tiempo de ejecución.
Versión introducida
.NET Core 2.1.16
.NET Core 3.0.3
.NET Core 3.1.2
Acción recomendada
Desinstale la versión 1.0.2 de OpenSSL si ya no la necesita.
Instale OpenSSL 1.1.x si usa los tipos AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl,
ECDsaOpenSsl, RSAOpenSsl o SafeEvpPKeyHandle.
Si usa los tipos de interoperabilidad de OpenSSL con P/Invoke personalizados, siga las instrucciones de los
comentarios sobre SafeEvpPKeyHandle.OpenSslVersion.
Categoría
Bibliotecas de Core .NET
API afectadas
System.Security.Cryptography.AesCcm
System.Security.Cryptography.AesGcm
System.Security.Cryptography.DSAOpenSsl
System.Security.Cryptography.ECDiffieHellmanOpenSsl
System.Security.Cryptography.ECDsaOpenSsl
System.Security.Cryptography.RSAOpenSsl
System.Security.Cryptography.SafeEvpPKeyHandle
 Novedades de .NET Core 2.0
02/11/2020 • 13 minutes to read • Edit Online

.NET Core 2.0 incluye mejoras y características nuevas en las áreas siguientes:
Herramientas
Compatibilidad con lenguajes
Mejoras en la plataforma
Cambios en la API
Integración de Visual Studio
Mejoras en la documentación

Tooling
dotnet restore se ejecuta de manera implícita
En las versiones anteriores de .NET Core, era necesario ejecutar el comando dotnet restore para descargar
dependencias inmediatamente después de crear un proyecto nuevo con el comando dotnet new, así como también
cada vez que se agregaba una dependencia nueva al proyecto.
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan que
se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test , dotnet publish y
dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los sistemas
de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore .
También puede deshabilitar la invocación automática de dotnet restore si pasa el modificador --no-restore a los
comandos new , run , build , publish , pack y test .
Redestinación a .NET Core 2.0
Si el SDK de .NET Core 2.0 SDK está instalado, los proyectos que tienen .NET Core 1.x como destino se pueden
redestinar a .NET Core 2.0.
Para redestinar a .NET Core 2.0, edite el archivo del proyecto cambiando el valor del elemento <TargetFramework>
(o del elemento <TargetFrameworks> , si tiene más de un destino en el archivo del proyecto) de 1.x a 2.0:

<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>

También puede redestinar las bibliotecas de .NET Standard a .NET Standard 2.0 del mismo modo:

<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>

Para más información sobre cómo migrar el proyecto a .NET Core 2.0, consulte el artículo sobre migración de
ASP.NET Core 1.x a ASP.NET Core 2.0.

Compatibilidad con lenguajes

Además de admitir C# y F#, .NET Core 2.0 también es compatible con Visual Basic.
Visual Basic
Con la versión 2.0, .NET Core ahora es compatible con Visual Basic 2017. Puede usar Visual Basic para crear los
tipos de proyecto siguientes:
Aplicaciones de consola .NET Core
Bibliotecas de clases .NET Core
Bibliotecas de clases .NET Standard
Proyectos de prueba unitaria .NET Core
Proyectos de prueba xUnit .NET Core
Por ejemplo, para crear una aplicación "Hola mundo" de Visual Basic, haga estos pasos en la línea de comandos:
1. En una ventana de la consola, cree un directorio para el proyecto y conviértalo en el directorio actual.
2. Escriba el comando dotnet new console -lang vb .
El comando crea un archivo del proyecto con una extensión de archivo .vbproj , además de un archivo de
código fuente de Visual Basic llamado Program.vb . Este archivo contiene el código fuente para escribir la
cadena "Hola mundo" en la ventana de consola.
3. Escriba el comando dotnet run . La CLI de .NET Core compila y ejecuta automáticamente la aplicación, con lo
que se muestra el mensaje "Hola mundo" en la ventana de la consola.
Compatibilidad con C# 7.1
.NET Core 2.0 es compatible con C# 7.1, que agrega varias características nuevas, entre las que se incluyen las
siguientes:
El método Main , el punto de entrada de la aplicación, se puede marcar con la palabra clave async.
Nombres de tupla deducidos.
Expresiones predeterminadas.

Mejoras en la plataforma
.NET Core 2.0 incluye varias características que facilitan la instalación de .NET Core y su uso en sistemas operativos
compatibles.
.NET Core para Linux es una sola implementación
.NET Core 2.0 ofrece una sola implementación de Linux que funciona en varias distribuciones de Linux. .NET Core
1.x requería que descargara una implementación de Linux específica para la distribución.
También puede desarrollar aplicaciones que tienen Linux como destino como un solo sistema operativo. .NET Core
1.x requería que se tuviera cada distribución de Linux como destino de forma independiente.
Compatibilidad con las bibliotecas de cifrado de Apple
.NET Core 1.x en macOS requería la biblioteca de cifrado del kit de herramientas OpenSSL. .NET Core 2.0 usa las
bibliotecas de cifrado de Apple y no requiere OpenSSL, por lo que ya no es necesario instalarlo.

Cambios en la API y compatibilidad con bibliotecas

Compatibilidad con .NET Standard 2.0
.NET Standard define un conjunto de API con versión que debe estar disponible en las implementaciones de .NET
que se ajustan a esa versión del estándar. .NET Standard está dirigido a los desarrolladores de bibliotecas. Pretende
garantizar la funcionalidad que está disponible a una biblioteca que tiene como destino una versión de
.NET Standard en cada implementación de .NET. .NET Core 1.x es compatible con la versión 1.6 de .NET Standard;
.NET Core 2.0 es compatible con la versión más reciente, .NET Standard 2.0. Para más información, consulte .NET
Standard.
.NET Standard 2.0 incluye más de 20 000 API más que las disponibles en .NET Standard 1.6. Gran parte de esta área
expuesta expandida es resultado de la incorporación de las API comunes de .NET Framework y Xamarin en .NET
Standard.
Las bibliotecas de clases de .NET Standard 2.0 también pueden hacer referencia a bibliotecas de clases de
.NET Framework, siempre que llamen a las API que existen en .NET Standard 2.0. No es necesario realizar una
nueva compilación de las bibliotecas .NET Framework.
Para obtener una lista de las API que se han agregado a .NET Standard desde su última versión, .NET Standard 1.6,
vea .NET Standard 2.0 frente a 1.6.
Área expuesta expandida
La cantidad total de API disponibles en .NET Core 2.0 aumentó más del doble en comparación con .NET Core 1.1.
Además, con el paquete de compatibilidad de Windows, la migración desde .NET Framework ahora es mucho más
fácil.
Compatibilidad con las bibliotecas .NET Framework
El código de .NET Core puede hacer referencia a bibliotecas .NET Framework existentes, incluidos paquetes NuGet
existentes. Tenga en cuenta que las bibliotecas deben usar las API que se encuentran en .NET Standard.

integración de Visual Studio

Visual Studio 2017 versión 15.3 y, en algunos casos, Visual Studio para Mac, ofrecen varias mejoras importantes
para los desarrolladores de .NET Core.
Redestinación de aplicaciones .NET Core y bibliotecas .NET Standard
Si el SDK de .NET Core 2.0 SDK está instalado, puede redestinar los proyectos de .NET Core 1.x a .NET Core 2.0 y las
bibliotecas .NET Standard 1.x a .NET Standard 2.0.
Para redestinar el proyecto en Visual Studio, abra la pestaña Aplicación del cuadro de diálogo de propiedades del
proyecto y cambie el valor de plataforma de destino a .NET Core 2.0 o .NET Standard 2.0 . También puede
cambiarlo si hace clic con el botón derecho en el proyecto y selecciona la opción Edit *.csproj file (Editar archivo
.csproj). Para más información, consulte la sección Herramientas anteriormente en este tema.
Compatibilidad con Live Unit Testing en .NET Core
Cada vez que modifique el código, Live Unit Testing ejecuta automáticamente y en segundo plano cualquier prueba
unitaria afectada y presenta los resultados y la cobertura de código en vivo en el entorno de Visual Studio. .NET
Core 2.0 ahora admite Live Unit Testing. Anteriormente, Live Unit Testing solo estaba disponible para aplicaciones
.NET Framework.
Para obtener más información, consulte Live Unit Testing con Visual Studio y las preguntas más frecuentes de Live
Unit Testing.
Mejor compatibilidad con varias plataformas de destino
Si compila un proyecto para varias plataformas de destino, ahora puede seleccionar la plataforma de destino en el
menú de nivel superior. En la figura siguiente, un proyecto llamado SCD1 tiene como destino macOS X 10.11 (
osx.10.11-x64 ) de 64 bits y Windows 10/Windows Server 2016 ( win10-x64 ) de 64 bits. Puede seleccionar la
plataforma de destino antes de seleccionar el botón del proyecto, en este caso para ejecutar una compilación de
depuración.

Compatibilidad en paralelo con SDK de .NET Core

Ahora es posible instalar el SDK de .NET Core de manera independiente de Visual Studio. Esto permite que una
versión única de Visual Studio compile proyectos que tienen como destino distintas versiones de .NET Core.
Anteriormente, Visual Studio y el SDK de .NET Core estaban estrechamente relacionados; una versión específica del
SDK acompañaba a una versión específica de Visual Studio.

Mejoras en la documentación
Arquitectura de aplicación de .NET
Arquitectura de aplicación de .NET le permite acceder a un conjunto de libros electrónicos que ofrecen orientación,
procedimientos recomendados y aplicaciones de ejemplo cuando use .NET para compilar:
Microservicios y contenedores Docker
Aplicaciones web con ASP.NET
Aplicaciones móviles con Xamarin
Aplicaciones que se implementan en la nube con Azure

Vea también
Novedades de ASP.NET Core 2.0
 Novedades de .NET Standard
18/12/2020 • 7 minutes to read • Edit Online

.NET Standard es una especificación formal que define un conjunto de API con control de versiones que debe estar
disponible en las implementaciones de .NET que cumplen con esa versión del estándar. .NET Standard está dirigido
a los desarrolladores de bibliotecas. Una biblioteca que tenga como destino una versión estándar de .NET Standard
se puede usar en cualquier implementación de .NET Framework, .NET Core o Xamarin que admita esa versión del
estándar.
.NET Standard se incluye con el SDK de .NET Core, así como con Visual Studio cuando se selecciona la carga de
trabajo de .NET Core.

Implementaciones de .NET compatibles

.NET Standard 2.0 es compatible con las implementaciones siguientes de .NET:
.NET Core 2.0 o versiones posteriores
.NET Framework 4.6.1 o versiones posteriores
Mono 5.4 o versiones posteriores
Xamarin.iOS 10.14 o versiones posteriores
Xamarin.Mac 3.8 o versiones posteriores
Xamarin.Android 8.0 o versiones posteriores
Plataforma universal de Windows 10.0.16299 o versiones posteriores

Novedades de .NET Standard 2.0

.NET Standard 2.0 incluye las siguientes características nuevas:
Un conjunto de API ampliamente expandido
Con la versión 1.6, .NET Standard incluía un subconjunto relativamente pequeño de API. Entre las excluidas había
muchas API usadas habitualmente en .NET Framework o Xamarin. Esto complica el desarrollo, ya que los
desarrolladores tienen que encontrar sustitutas adecuadas para API familiares para desarrollar aplicaciones y
bibliotecas destinadas a varias implementaciones de .NET. .NET Standard 2.0 soluciona esta limitación con la
incorporación de más de 20 000 API más de las que estaban disponibles en .NET Standard 1.6, la versión anterior
del estándar. Si quiere obtener una lista de las API agregadas a .NET Standard 2.0, vea comparación entre .NET
Standard 2.0 y 1.6.
Alguna de las adiciones al espacio de nombres System de .NET Standard 2.0 incluyen:
Compatibilidad con la clase AppDomain.
Mayor compatibilidad para trabajar con matrices de miembros adicionales en la clase Array.
Mayor compatibilidad para trabajar con atributos de miembros adicionales en la clase Attribute.
Mayor compatibilidad del calendario y opciones de formato adicionales para los valores DateTime.
Funcionalidad de redondeo Decimal adicional.
Funcionalidad adicional en la clase Environment.
Control mejorado sobre el recolector de elementos no utilizados en la clase GC.
Compatibilidad mejorada para la comparación de cadenas, la enumeración y la normalización en la clase String.
Compatibilidad para los tiempos de transición y los ajustes del horario de verano en las clases
TimeZoneInfo.AdjustmentRule y TimeZoneInfo.TransitionTime.
 Funcionalidad mejorada significativamente en la clase Type.
Mejor compatibilidad para la deserialización de objetos de excepción mediante la adición de un constructor de
excepción con los parámetros SerializationInfo y StreamingContext.
Compatibilidad con las bibliotecas .NET Framework
Muchas bibliotecas tienen como destino .NET Framework en lugar de .NET Standard. Sin embargo, la mayoría de
las llamadas de esas bibliotecas se realizan a las API incluidas en .NET Standard 2.0. A partir de .NET Standard 2.0,
puede acceder a las bibliotecas de .NET Framework desde una biblioteca de .NET Standard usando una corrección
de compatibilidad. Este nivel de compatibilidad es transparente para los desarrolladores; no tiene que hacer nada
para aprovechar las ventajas de las bibliotecas de .NET Framework.
El único requisito es que las API a las que llaman las bibliotecas de clases .NET Framework estén incluidas en .NET
Standard 2.0.
Compatibilidad con Visual Basic
Ahora puede desarrollar bibliotecas de .NET Standard en Visual Basic. Visual Studio 2019 y Visual Studio 2017,
versión 15.3 o una posterior con la carga de trabajo de .NET Core instalada, incluyen una plantilla de la biblioteca
de clases .NET Standard. Para los desarrolladores de Visual Basic que usan otras herramientas y entornos de
desarrollo, puede usar el comando dotnet new para crear un proyecto de biblioteca de .NET Standard. Para más
información, vea Compatibilidad con herramientas de bibliotecas estándar de .NET.
Compatibilidad con herramientas de bibliotecas de .NET Standard
Con la versión de .NET Core 2.0 y .NET Standard 2.0, Visual Studio 2017 y la CLI de .NET Core incluyen
compatibilidad con herramientas para crear bibliotecas de .NET Standard.
Si instala Visual Studio con la carga de trabajo de desarrollo multiplataforma de .NET Core , puede crear un
proyecto de biblioteca de .NET Standard 2.0 al usar una plantilla de proyecto, como se muestra en la ilustración
siguiente:
C#
Visual Basic
Si usa la CLI de .NET Core, el comando dotnet new siguiente crea un proyecto de biblioteca de clases que tiene
como destino .NET Standard 2.0:

dotnet new classlib

Vea también
.NET Standard
Introducing .NET Standard (Introducción a .NET Standard)
Descarga del SDK de .NET
 Herramientas y diagnósticos en .NET
18/12/2020 • 3 minutes to read • Edit Online

En este artículo, obtendrá información sobre las diversas herramientas disponibles para los desarrolladores de
.NET. Con .NET, tiene un sólido kit de desarrollo de software (SDK) que incluye una interfaz de línea de comandos
(CLI). La CLI de .NET permite muchas de las características de en. Entornos de desarrollo integrado (IDE) preparados
para NET. En este artículo también se proporcionan recursos para las funcionalidades de productividad, como las
herramientas de la CLI de .NET para diagnosticar problemas de rendimiento, fugas de memoria, CPU elevada,
interbloqueos y compatibilidad de herramientas para el análisis de código.

.NET SDK
El SDK de .NET incluye el tiempo de ejecución de .net y la CLI de .NET. Puede descargar el SDK de .net para
Windows, Linux, MacOS o Docker. Para obtener más información, vea información general sobre el SDK de .net.

CLI de .NET
La CLI de .NET es una cadena de herramientas multiplataforma para desarrollar, compilar, ejecutar y publicar
aplicaciones .NET. La CLI de .NET se incluye con el SDK de .NET. Para obtener más información, vea información
general sobre la CLI de .net.

IDE
Puede escribir aplicaciones .NET en Visual Studio Code, Visual Studioo Visual Studio para Mac. Para obtener
información sobre los entornos de desarrollo basados en la nube, vea Visual Studio Codespaces.

Herramientas adicionales
Además de las herramientas más comunes, .NET también proporciona herramientas para escenarios específicos.
Algunos de los casos de uso incluyen la desinstalación del SDK de .NET o el tiempo de ejecución de .NET, la
recuperación de metadatos de Windows Communication Foundation (WCF), la generación de código fuente de
proxy y la serialización de XML. Para obtener más información, vea información general sobre herramientas
adicionales de .net.

Diagnóstico e instrumentación
Como desarrollador de .NET, puede usar las herramientas de diagnóstico de rendimiento comunes para supervisar
el rendimiento de las aplicaciones, generar perfiles de aplicaciones con seguimiento, recopilar métricas de
rendimiento y analizar archivos de volcado de memoria. Recopile las métricas de rendimiento con los contadores
de eventos y use las herramientas de generación de perfiles para obtener información sobre cómo funcionan las
aplicaciones. Para obtener más información, consulte herramientas de diagnóstico de .net.

Análisis de código
Los analizadores de .NET Compiler Platform (Roslyn) inspeccionan el código de C# o Visual Basic para los
problemas de estilo de código y calidad del código. Para obtener más información, vea información general sobre
análisis de código fuente .net.
 Información general sobre el SDK de .NET Core
04/05/2020 • 3 minutes to read • Edit Online

El SDK de .NET Core es un conjunto de bibliotecas y herramientas que permiten a los desarrolladores crear
aplicaciones y bibliotecas de .NET Core. Contiene los siguientes componentes que se usan para compilar y
ejecutar aplicaciones:
La CLI de .NET Core.
Bibliotecas y runtime de .NET Core.
El controlador dotnet .

Adquisición del SDK de .NET Core

Del mismo modo que ocurre con todas las herramientas, lo primero que debe hacer es instalar las herramientas
en su máquina. Según el escenario, puede instalar el SDK mediante uno de los métodos siguientes:
Los instaladores nativos.
El script de shell de instalación.
Los instaladores nativos están pensados principalmente para las máquinas de los desarrolladores. El SDK se
distribuye mediante el mecanismo de instalación nativo de cada plataforma compatible, como los paquetes DEB
en Ubuntu o los conjuntos de MSI en Windows. Estos instaladores instalan y configuran el entorno según sea
necesario para que el usuario use el SDK inmediatamente después de la instalación. Sin embargo, también se
necesitan privilegios administrativos en la máquina. Puede encontrar el SDK para instalar en la página de
descargas de .NET.
Por el contrario, los scripts de instalación no requieren privilegios administrativos, aunque tampoco instalan
ningún requisito previo en el equipo; debe instalarlos todos manualmente el usuario. Los scripts están pensados
principalmente para configurar servidores de compilación o cuando desee instalar las herramientas sin
privilegios de administración (tenga en cuenta la salvedad con respecto a los requisitos previos que ya se
mencionó). Puede encontrar más información en el artículo referencia de scripts de dotnet-install. Si está
interesado en cómo configurar el SDK en el servidor de compilación de CI, vea el artículo Uso de .NET Core SDK y
herramientas de integración continua (CI).
De forma predeterminada, el SDK se instala en paralelo (SxS), lo que significa que varias versiones pueden
coexistir en un único equipo en cualquier momento. La forma en que se detecta la versión al ejecutar los
comandos de la CLI se explica más detalladamente en el artículo Selección de la versión de .NET Core que se va a
usar.

Vea también
Información general sobre la CLI de .NET Core
Introducción a la creación de versiones de .NET Core
Cómo quitar los componentes .NET Core Runtime y SDK
Selección de la versión de .NET Core que se va a usar
 NETSDK1005 y NETSDK1047: Falta el destino del
archivo de recursos
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1.100 y versiones posteriores
Cuando el SDK de .NET emite el error NETSDK1005 o NETSDK1047, falta información sobre una de las plataformas
de destino en el archivo de recursos del proyecto. Normalmente, para corregir esto debe asegurarse de que se
ejecute la restauración y de que el valor de destino que falta está incluido en la propiedad TargetFrameworks del
proyecto.

NOTE
Ha habido un problema conocido con las primeras compilaciones de .NET 5 Preview 8 cuando se usaba con versiones de vista
previa de Visual Studio 16.8 en las que se producía este error. En concreto, si el destino que falta es net5.0-windows7.0 o
net5.0 , asegúrese de que ha actualizado a las versiones más recientes de Visual Studio y el SDK de .NET 5.
 NETSDK1013: No se ha reconocido el valor
TargetFramework
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.100 y versiones posteriores
El SDK intenta analizar los valores proporcionados en el archivo del proyecto para <TargetFramework> o
<TargetFrameworks> en un valor conocido. Si no se reconoce, el valor TargetFrameworkIdentifier o
TargetFrameworkVersion se puede establecer en una cadena vacía o Unsupported .

Para solucionarlo, compruebe la ortografía del valor TargetFramework en la lista de marcos admitidos. También
puede establecer las propiedades TargetFrameworkIdentifier y TargetFrameworkVersion directamente en el archivo
del proyecto.

<PropertyGroup Condition="'$(TargetFrameworkIdentifier)' == ''">

<TargetFrameworkIdentifier>.NETCOREAPP</TargetFrameworkIdentifier>
<TargetFrameworkVersion>3.1</TargetFrameworkVersion>
</PropertyGroup>
 NETSDK1022: Se han incluido elementos duplicados.
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1.100 y versiones posteriores
A partir de Visual Studio 2017 y MSBuild, versión 15.3, el SDK de .NET incluye automáticamente los elementos del
directorio del proyecto de forma predeterminada. Esto incluye los destinos Compile y Content . Esto debería limpiar
en gran medida el archivo del proyecto y reducir su complejidad.
Puede revertir al comportamiento anterior si establece la propiedad correcta en "false".
Ejemplo para elementos Compile :

<PropertyGroup>
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
</PropertyGroup>
 NETSDK1059: El proyecto contiene la herramienta de
la CLI de .NET obsoleta
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1.100 y versiones posteriores
Cuando el SDK de .NET emite la advertencia NETSDK1059, el proyecto contiene una herramienta de la CLI de .NET
obsoleta. A partir de .NET Core 2.1, estas herramientas se incluyen en el SDK de .NET y no es necesario que en el
proyecto se les haga referencia de forma explícita. Aquí puede encontrar más información para migrar a
.NET Core 2.1.
 NETSDK1071: Elemento PackageReference con una
versión explícita a un metapaquete que se incluiría
con el marco.
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET 5.0.100 y versiones posteriores
Si el SDK de .NET emite una advertencia NETSDK1071, sugiere que puede haber un conflicto de versiones en el
futuro entre la versión de un metapaquete especificada en un elemento PackageReference y la versión de ese
metapaquete a la que se hace referencia de forma implícita a través de una propiedad TargetFramework:

<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

Como TargetFramework aporta de forma automática una versión del metapaquete, las versiones entrarán en
conflicto en caso de que difieran.
Para resolver este problema:
1. Al seleccionar como destino .NET Core o .NET Standard, considere la posibilidad de evitar referencias
explícitas a Microsoft.NETCore.App o NETStandard.Library en el archivo del proyecto.
2. Si necesita una versión concreta del entorno de ejecución cuando el destino es .NET Core, use la propiedad
<RuntimeFrameworkVersion> en lugar de hacer referencia de forma directa al metapaquete. Por ejemplo, esto
puede ocurrir si usa implementaciones independientes y necesita una versión específica del entorno de
ejecución de LTS 1.0.0.
3. Si necesita una versión concreta de NetStandard.Library cuando el destino es .NET Standard, puede usar la
propiedad <NetStandardImplicitPackageVersion> y establecerla en la versión necesaria.
4. No agregue referencias a Microsoft.NETCore.App y NETSTandard.Library ni las actualice de forma explícita en
proyectos de .NET Framework. NuGet instala de forma automática cualquier versión de NETStandard.Library
que necesite al usar un paquete NuGet basado en .NET Standard.
5. No especifique una versión para Microsoft.AspNetCore.App o Microsoft.AspNetCore.All al usar
.NET Core 2.1 y posteriores, ya que el SDK de .NET Core selecciona de forma automática la versión adecuada.
(Nota: Esto solo funciona cuando el destino es .NET Core 2.1 si el proyecto también utiliza
Microsoft.NET.Sdk.Web . Este problema se ha resuelto en el SDK de .NET Core 2.2).

6. Si quiere que desaparezca la advertencia, también puede deshabilitarla:

<PackageReference Include="Microsoft.NetCore.App" Version="2.2.8" >

<AllowExplicitVersion>true</AllowExplicitVersion>
</PackageReference>
 NETSDK1073: No se ha reconocido el valor de
FrameworkReference
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1.100 y versiones posteriores
Normalmente este error significa que hay una versión de un elemento FrameworkReference concreto que el SDK
no puede encontrar. Intente eliminar las carpetas obj y bin, y ejecute dotnet restore para volver a descargar los
paquetes de destino más recientes.
Como alternativa, es posible que haya un problema con la instalación, por lo que debe asegurarse de tener las
versiones más recientes de .NET y Visual Studio.
 NETSDK1079: El paquete Microsoft.AspNetCore.All
no se admite cuando el destino es .NET Core 3.0 o
posterior.
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.100 y versiones posteriores
Es posible que reciba este mensaje de error en los siguientes casos:
Puede redestinar un proyecto de ASP.NET Core de .NET Core 2.2 o anterior a .NET Core 3.0 o posterior.
El proyecto usa el paquete Microsoft.AspNetCore.All.
Quite PackageReference para Microsoft.AspNetCore.All. También es posible que deba agregar referencias para los
paquetes a los que se hace referencia desde Microsoft.AspNetCore.All, pero que no se incluyen en el marco
compartido de ASP.NET Core. Estos paquetes se enumeran aquí: Migración desde Microsoft.AspNetCore.All a
Microsoft.AspNetCore.App.
Vea también Migración desde ASP.NET Core 2.2 a 3.0
 NETSDK1145: Falta el paquete de destino o de
apphost
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET 5.0.100 y versiones posteriores
Cuando el SDK de .NET emite el error NETSDK1145, no se instalan el paquete de destino o apphost, y no se admite
la restauración de paquetes NuGet. Normalmente esto se debe a la presencia de un SDK más reciente que el que se
incluye en los proyectos de Visual Studio para C++/CLI. Actualice Visual Studio, quite global.json si especifica una
versión concreta del SDK y desinstale el SDK más reciente. También puede invalidar la versión de destino o de
apphost. Busque la versión que existe en el directorio pack del mensaje de error y que coincida con la plataforma
de destino del proyecto. Agregue lo siguiente al proyecto:
Para el paquete de apphost

<ItemGroup>
<KnownAppHostPack Update="@(KnownAppHostPack)">
<AppHostPackVersion Condition="'%(TargetFramework)' ==
'TARGETFRAMEWORK'">EXISTINGVERSION</AppHostPackVersion>
</KnownAppHostPack>
</ItemGroup>

Para el paquete de destino

<ItemGroup>
<KnownAppHostPack Update="@(KnownAppHostPack)">
<AppHostPackVersion Condition="'%(TargetFramework)' ==
'TARGETFRAMEWORK'">EXISTINGVERSION</AppHostPackVersion>
</KnownAppHostPack>
</ItemGroup>
 Información general sobre la CLI de .NET
18/12/2020 • 5 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores
La interfaz de la línea de comandos (CLI) de .NET es una cadena de herramientas multiplataforma que
sirve para desarrollar, compilar, ejecutar y publicar aplicaciones .NET.
La CLI de .NET se incluye con el SDK de .NET. Para obtener más información sobre cómo instalar el SDK
de .NET, vea Instalación de .NET Core.

Comandos de la CLI
De forma predeterminada, se instalan los siguientes comandos:
Comandos básicos
new
restore
build
publish
run
test
vstest
pack
migrate
clean
sln
help
store

Comandos de modificación del proyecto

add package
add reference
remove package
remove reference
list reference

Comandos avanzados
nuget delete
nuget locals
nuget push
msbuild
dotnet install script

Comandos de administración de herramientas

tool install
tool list
 tool update
tool restore Disponible a partir del SDK de .NET Core 3.0.
tool run Disponible a partir del SDK de .NET Core 3.0.
tool uninstall

Las herramientas son aplicaciones de consola que se instalan mediante paquetes NuGet y se invocan
desde el símbolo del sistema. Puede encargarse de escribir las herramientas o instalar las escritas por
terceros. Las herramientas también se denominan herramientas globales, herramientas de ruta de acceso
de herramientas y herramientas locales. Para obtener más información, vea la información general sobre
las herramientas de .NET.

Estructura de comandos
La estructura de comandos de la CLI consta del controlador ("dotnet"), el comando y posiblemente de los
argumentos de comandos y otras opciones. Este patrón se puede ver en la mayoría de las operaciones de
la CLI, como la creación de una nueva aplicación de consola y su ejecución desde la línea de comandos,
como muestran los siguientes comandos cuando se ejecutan desde un directorio denominado my_app:

dotnet new console

dotnet build --output /build_output
dotnet /build_output/my_app.dll

Controlador
El controlador se denomina dotnet y tiene dos responsabilidades, ejecutar una aplicación dependiente del
marco o ejecutar un comando.
Para ejecutar una aplicación dependiente del marco, especifique la aplicación después del controlador, por
ejemplo, dotnet /path/to/my_app.dll . Cuando ejecute el comando desde la carpeta donde reside la DLL
de la aplicación, simplemente ejecute dotnet my_app.dll . Si quiere usar una versión específica del
entorno de ejecución .NET, use la opción --fx-version <VERSION> (consulte la referencia del comando
dotnet).
Cuando se proporciona un comando para el controlador, dotnet.exe inicia el proceso de ejecución del
comando de la CLI. Por ejemplo:

dotnet build

En primer lugar, el controlador determina la versión de SDK que se debe usar. Si no hay ningún archivo
global.json, se usa la última versión del SDK disponible. Podría tratarse de una versión preliminar o de
una versión estable, en función de lo último que esté disponible en el equipo. Una vez determinada la
versión del SDK, se ejecutará el comando.
Comando
El comando realiza una acción. Por ejemplo, dotnet build compila código. dotnet publish publica el
código. Los comandos se implementan como una aplicación de consola usando una convención
dotnet {command} .

Argumentos
Los argumentos que se pasan en la línea de comandos son los argumentos para el comando invocado.
Por ejemplo, cuando ejecuta dotnet publish my_app.csproj , el argumento my_app.csproj indica el
proyecto que se publicará y se pasa al comando publish .
Opciones
Las opciones que se pasan en la línea de comandos son las opciones para el comando que se invoca. Por
ejemplo, cuando ejecuta dotnet publish --output /build_output , la opción --output y su valor se pasan
al comando publish .

Vea también
Repositorio de GitHub dotnet/sdk
Guía de instalación de .NET
 comando dotnet
18/12/2020 • 23 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet : controlador genérico de la CLI de .NET.

Sinopsis
Para obtener información sobre los comandos disponibles y el entorno:

dotnet [--version] [--info] [--list-runtimes] [--list-sdks]

dotnet -h|--help

Para ejecutar un comando (se requiere la instalación de un SDK):

dotnet <COMMAND> [-d|--diagnostics] [-h|--help] [--verbosity <LEVEL>]

[command-options] [arguments]

Para ejecutar una aplicación:

dotnet [--additionalprobingpath <PATH>] [--additional-deps <PATH>]

[--fx-version <VERSION>] [--roll-forward <SETTING>]
<PATH_TO_APPLICATION> [arguments]

dotnet exec [--additionalprobingpath] [--additional-deps <PATH>]

[--fx-version <VERSION>] [--roll-forward <SETTING>]
<PATH_TO_APPLICATION> [arguments]

--roll-forward está disponible a partir de .NET Core 3.x. En .NET Core 2.x, use
--roll-forward-on-no-candidate-fx .

Descripción
El comando dotnet tiene dos funciones:
Proporciona comandos para trabajar con proyectos de .NET.
Por ejemplo, dotnet build compila un proyecto. Cada comando define sus propias opciones y
argumentos. Todos los comandos admiten la opción --help para ver una breve documentación sobre
cómo usar el comando.
Ejecuta aplicaciones de .NET.
Hay que especificar la ruta de acceso al archivo .dll de una aplicación para poder ejecutarla. Ejecutar la
aplicación significa buscar y ejecutar el punto de entrada, que en el caso de las aplicaciones de consola es
el método Main . Por ejemplo, dotnet myapp.dll ejecuta la aplicación myapp . Vea Implementación de
aplicaciones de .NET para obtener información sobre las opciones de implementación.
Opciones
Existen distintas opciones disponibles para usar dotnet por sí mismo, para ejecutar un comando y para ejecutar
una aplicación.
Opciones de dotnet por sí mismo
Las siguientes opciones son para usar dotnet por sí mismo. Por ejemplo: dotnet --info . Muestran información
sobre el entorno.
--info

Imprime información detallada sobre una instalación de .NET y el entorno del equipo, por ejemplo, el
sistema operativo actual y el SHA de confirmación de la versión de .NET.
--version

Imprime la versión del SDK de .NET en uso.

--list-runtimes

Imprime una lista de los entornos de ejecución de .NET instalados. Una versión x86 del SDK muestra solo
los runtime x86 y una versión x64 solo los runtime x64.
--list-sdks

Imprime una lista de los SDK de .NET instalados.

-h|--help

Muestra una lista de los comandos disponibles.

Opciones de SDK para ejecutar un comando
Las siguientes opciones son para usar dotnet con un comando. Por ejemplo: dotnet build --help .
-d|--diagnostics

Habilita la salida de diagnóstico.

-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] . Estos no se admiten en todos los comandos. Vea la página específica de cada
comando para asegurarse de que la opción está disponible.
-h|--help

Imprime la documentación de un comando determinado, como dotnet build --help .

command options

Cada comando define opciones específicas de ese comando. Vea la página de comandos específica para
obtener una lista de las opciones disponibles.
Definición de tiempo de ejecución
Las siguientes opciones están disponibles cuando dotnet ejecuta una aplicación. Por ejemplo:
dotnet myapp.dll --roll-forward Major .

--additionalprobingpath <PATH>

Ruta de acceso que contiene directivas de sondeo y ensamblados para sondear.

--additional-deps <PATH>

Ruta de acceso a un archivo .deps.json adicional. Un archivo deps.json contiene una lista de dependencias,
dependencias de compilación e información de versión que se usa para resolver conflictos de ensamblado.
Para más información, vea Runtime Configuration Files (Archivos de configuración en tiempo de
ejecución) en GitHub.
--depsfile <PATH_TO_DEPSFILE>

Ruta de acceso al archivo deps.json. Un archivo deps.json es un archivo de configuración que contiene
información sobre las dependencias necesarias para ejecutar la aplicación. El SDK de .NET genera este
archivo.
--runtimeconfig

Ruta de acceso a un archivo runtimeconfig.json. Un archivo runtimeconfig.json es un archivo de

configuración que contiene opciones de configuración en tiempo de ejecución. Para obtener más
información, vea Opciones de configuración en tiempo de ejecución de .NET Core.
--roll-forward <SETTING> Disponible a par tir del SDK de .NET Core 3.0.
Controla cómo se aplica la puesta al día en la aplicación. SETTING puede tener uno de los valores
siguientes. Si no se especifica, el valor predeterminado es Minor .
LatestPatch : la aplicación se pone al día con la última versión de revisión. Se deshabilita la puesta al
día de versiones secundarias.
Minor : la aplicación se pone al día con la versión secundaria mínima superior, si no se encuentra la
versión secundaria solicitada. Si se encuentra la versión secundaria solicitada, se utiliza la directiva
LatestPatch.
Major : la aplicación se pone al día con la versión secundaria mínima superior, y con la versión
secundaria mínima si no se encuentra la versión secundaria solicitada. Si se encuentra la versión
principal solicitada, se utiliza la directiva Minor.
LatestMinor : la aplicación e pone al día con la última versión secundaria, aunque la versión secundaria
solicitada esté presente. Se destina a escenarios de hospedaje de componentes.
LatestMajor : la aplicación se pone al día con la última versión principal y la última versión secundaria,
aunque la versión principal solicitada esté presente. Se destina a escenarios de hospedaje de
componentes.
Disable : la aplicación no se pone al día. Solo se enlaza a la versión especificada. No se recomienda
esta directiva para uso general, ya que deshabilita la capacidad de puesta al día con las revisiones más
recientes. Este valor solo se recomienda a efectos de pruebas.
A excepción de Disable , todos los valores usarán la última versión de revisión disponible.
El comportamiento de puesta al día también se puede configurar en una propiedad de archivo de
proyecto, en una propiedad de archivo de configuración de runtime y en una variable de entorno. Para
obtener más información, vea Puesta al día del runtime de versiones principales.
--roll-forward-on-no-candidate-fx <N> Disponible en el SDK de .NET Core 2.x.
Define el comportamiento cuando el marco de trabajo compartido necesario no está disponible. N puede
ser:
0 : se deshabilita la puesta al día incluso de las versiones secundarias.
1 : puesta al día de la versión secundaria, pero no de la versión principal. Éste es el comportamiento
predeterminado.
2 : puesta al día de las versiones principales y secundarias.
 Para obtener más información, vea Roll forward (Puesta al día).
A partir de .NET Core 3.0, esta opción se sustituye por --roll-forward y es la que debe usarse.
--fx-version <VERSION>

Versión del entorno de ejecución de .NET que se va a usar para ejecutar la aplicación.
Esta opción reemplaza la versión de la primera referencia de marco en el archivo .runtimeconfig.json de
la aplicación. Esto significa que solo funciona según lo esperado si solo hay una referencia de marco. Si la
aplicación tiene más de una referencia de marco, el uso de esta opción puede hacer que se produzcan
errores.

comandos de dotnet
General
C O M A N DO F UN C IÓ N

dotnet build Compila una aplicación de .NET.

dotnet build-server Interactúa con servidores iniciados por una compilación.

dotnet clean Limpia las salidas de la compilación.

dotnet help Muestra documentación más detallada en línea sobre el

comando.

dotnet migrate Migra un proyecto de Preview 2 válido a un proyecto del SDK

1.0 de .NET Core.

dotnet msbuild Proporciona acceso a la línea de comandos de MSBuild.

dotnet new Inicializa un proyecto de C# o F# para una plantilla

determinada.

dotnet pack Crea un paquete de NuGet de su código.

dotnet publish Publica una aplicación dependiente del maco .NET o

autocontenida.

dotnet restore Restaura las dependencias de una aplicación determinada.

dotnet run Ejecuta la aplicación desde el origen.

dotnet sln Opciones para agregar, quitar y mostrar proyectos en un

archivo de solución.

dotnet store Almacena ensamblados en el almacenamiento de paquetes

en tiempo de ejecución.

dotnet test Ejecuta pruebas usando un ejecutor de pruebas.

Referencias de proyecto
 C O M A N DO F UN C IÓ N

dotnet add reference Agrega una referencia de proyecto.

dotnet list reference Enumera referencias de proyecto.

dotnet remove reference Quita una referencia de proyecto.

Paquetes NuGet
C O M A N DO F UN C IÓ N

dotnet add package Agrega un paquete NuGet.

dotnet remove package Quita un paquete NuGet.

Comandos NuGet
C O M A N DO F UN C IÓ N

dotnet nuget delete Elimina o quita de la lista un paquete del servidor.

dotnet nuget push Inserta un paquete en el servidor y lo publica.

dotnet nuget locals Borra o muestra los recursos de NuGet locales, como la caché
de solicitudes http, la caché temporal o la carpeta de
paquetes global de toda la máquina.

dotnet nuget add source Agrega un origen de NuGet.

dotnet nuget disable source Deshabilita un origen de NuGet.

dotnet nuget enable source Habilita un origen de NuGet.

dotnet nuget list source Enumera todos los orígenes de NuGet configurados.

dotnet nuget remove source Quita un origen de NuGet.

dotnet nuget update source Actualiza un origen de NuGet.

Comandos de herramientas locales, globales y de ruta de acceso de herramientas

Las herramientas son aplicaciones de consola que se instalan mediante paquetes NuGet y se invocan desde el
símbolo del sistema. Puede encargarse de escribir las herramientas o instalar las escritas por terceros. Las
herramientas también se denominan herramientas globales, herramientas de ruta de acceso de herramientas y
herramientas locales. Para obtener más información, vea la información general sobre las herramientas de .NET.
Las herramientas globales y de ruta de acceso de herramientas están disponibles a partir del SDK de
.NET Core 2.1. Las herramientas locales están disponibles a partir del SDK de .NET Core 3.0.

C O M A N DO F UN C IÓ N

dotnet tool install Instala una herramienta en el equipo.

 C O M A N DO F UN C IÓ N

dotnet tool list Muestra todas las herramientas globales, de ruta de acceso
de herramientas o locales instaladas actualmente en el
equipo.

dotnet tool search Busca en NuGet.org herramientas que tengan el término de

búsqueda especificado en el nombre o los metadatos.

dotnet tool uninstall Desinstala una herramienta del equipo.

dotnet tool update Actualiza una herramienta que está instalada en el equipo.

Herramientas adicionales
A partir del SDK de .NET Core 2.1.300, una serie de herramientas que estaban disponibles solo en función del
proyecto mediante DotnetCliToolReference ahora están disponibles como parte del SDK de .NET. Estas
herramientas se muestran en la tabla siguiente:

H ERRA M IEN TA F UN C IÓ N

dev-certs Crea y administra certificados de desarrollo.

ef Herramientas de línea de comandos de Entity Framework

Core.

sql-cache Herramientas de línea de comandos de la caché de SQL

Server.

user-secrets Administra los secretos del usuario de desarrollo.

watch Inicia un monitor de archivos que ejecuta un comando

cuando cambian los archivos.

Para obtener más información sobre cada herramienta, escriba dotnet <tool-name> --help .

Ejemplos
Creación de una aplicación de consola de .NET:

dotnet new console

Compilación de un proyecto y sus dependencias en un directorio determinado:

dotnet build

Ejecute una aplicación:

dotnet myapp.dll

Variables de entorno
DOTNET_ROOT , DOTNET_ROOT(x86)
Especifica la ubicación de los entornos de ejecución de .NET, si no están instalados en la ubicación
predeterminada. La ubicación predeterminada en Windows es C:\Program Files\dotnet . La ubicación
predeterminada en Linux y macOS es /usr/share/dotnet . Esta variable de entorno solo se usa cuando se
ejecutan aplicaciones a través de archivos ejecutables generados (hosts de aplicaciones).
DOTNET_ROOT(x86) se usa en su lugar cuando se ejecuta un archivo ejecutable de 32 bits en un sistema
operativo de 64 bits.
NUGET_PACKAGES

La carpeta de paquetes globales. Si no se establece, el valor predeterminado es ~/.nuget/packages en Unix

o %userprofile%\.nuget\packages en Windows.
DOTNET_SERVICING

Especifica la ubicación del índice de mantenimiento que usará el host compartido al cargar el entorno de
tiempo de ejecución.
DOTNET_NOLOGO

Especifica si los mensajes de bienvenida y telemetría de .NET se muestran en la primera ejecución.

Establézcala en true para silenciar estos mensajes (valores true , 1 o yes aceptados) o en false para
permitirlos (valores false , 0 o no aceptados). Si no se establece, el valor predeterminado es false y
los mensajes se mostrarán en la primera ejecución. Esta marca no tiene ningún efecto en la telemetría
(consulte DOTNET_CLI_TELEMETRY_OPTOUT para excluirse del envío de telemetría).
DOTNET_CLI_TELEMETRY_OPTOUT

Especifica si se recopilan datos sobre el uso de herramientas de .NET y se envían a Microsoft. Establézcalo
en true para no participar de la característica de la telemetría (se aceptan los valores true , 1 o yes ).
De lo contrario, establézcalo en false para participar de la característica de la telemetría (se aceptan los
valores false , 0 o no ). Si no se establece, el valor predeterminado es false , y la característica de
telemetría está activa.
DOTNET_MULTILEVEL_LOOKUP

Especifica si desde la ubicación global se resuelve el entorno de ejecución de .NET, el marco compartido o
el SDK. Si no se define, establece el valor predeterminado de 1 ( true lógico). Establézcalo en 0 ( false
lógico) para no resolver desde la ubicación global y tener instalaciones de .NET aisladas. Para más
información sobre las búsquedas de varios niveles, vea Multi-level SharedFX Lookup (Búsqueda SharedFX
de varios niveles).
DOTNET_ROLL_FORWARD Disponible a par tir de .NET Core 3.x.
Determina el comportamiento de puesta al día. Para obtener más información, vea la opción
--roll-forward más arriba en este mismo artículo.

DOTNET_ROLL_FORWARD_TO_PRERELEASE Disponible a par tir de .NET Core 3.x.

Si se establece en 1 (habilitado), permite la puesta al día a una versión preliminar desde una versión de
lanzamiento. De forma predeterminada ( 0 : deshabilitado), cuando se solicita una versión de lanzamiento
del entorno de ejecución de .NET, la puesta al día solo tendrá en cuenta las versiones de lanzamiento
instaladas.
Para obtener más información, vea Roll forward (Puesta al día).
DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX Disponible en .NET Core 2.x.
Deshabilita la puesta al día de versiones secundarias, si está establecido en 0 . Para obtener más
información, vea Roll forward (Puesta al día).
Este valor se ha sustituido en .NET Core 3.0 por DOTNET_ROLL_FORWARD , y esta es la configuración que debe
usarse.
DOTNET_CLI_UI_LANGUAGE

Establece el idioma de la interfaz de usuario de la CLI mediante un valor de configuración regional como
en-us . Los valores admitidos son los mismos que en Visual Studio. Para obtener más información, vea la
sección sobre cómo cambiar el idioma del instalador en la documentación de instalación de Visual Studio.
Se aplican las reglas del administrador de recursos de .NET, por lo que no hay que elegir una coincidencia
exacta—(también se pueden elegir descendientes en el árbol CultureInfo ). Por ejemplo, si se establece en
fr-CA , la CLI buscará y usará las traducciones de fr . Si se establece en un idioma que no se admite, la
CLI revertirá al inglés.
DOTNET_DISABLE_GUI_ERRORS

En el caso de los archivos ejecutables generados habilitados para GUI, se deshabilita el cuadro de diálogo
emergente que suele aparecer con ciertos tipos de errores. Solo escribe en stderr y se cierra en esos
casos.
DOTNET_ADDITIONAL_DEPS

Equivale a la opción --additional-deps de la CLI.

DOTNET_RUNTIME_ID

Invalida el RID detectado.

DOTNET_SHARED_STORE

Ubicación del "almacén compartido" a la que la resolución de ensamblado revierte en algunos casos.
DOTNET_STARTUP_HOOKS

Lista de ensamblados de los que cargar y ejecutar enlaces de inicio.

DOTNET_BUNDLE_EXTRACT_BASE_DIR Disponible a par tir de .NET Core 3.x.
Especifica un directorio en el que se extrae una aplicación de un solo archivo antes de ejecutarse.
Para más información, consulte Archivos ejecutables de único archivo.
COREHOST_TRACE , COREHOST_TRACEFILE , COREHOST_TRACE_VERBOSITY

Controla el seguimiento de diagnósticos de los componentes de hospedaje, como dotnet.exe , hostfxr y

hostpolicy .

COREHOST_TRACE=[0/1] : el valor predeterminado es 0 (el seguimiento está deshabilitado). Si se

establece en 1 , se habilita el seguimiento de diagnósticos.
COREHOST_TRACEFILE=<file path> : solo tiene efecto si el seguimiento se habilita a través de
COREHOST_TRACE=1 . Cuando se establece, la información de seguimiento se escribe en el archivo
especificado; en caso contrario, la información de seguimiento se escribe en stderr . Disponible a
par tir de .NET Core 3.x.
COREHOST_TRACE_VERBOSITY=[1/2/3/4] : el valor predeterminado es 4 . La configuración solo se usa
cuando el seguimiento está habilitado a través de COREHOST_TRACE=1 . Disponible a par tir de .NET
Core 3.x.
4 : se escribe toda la información de seguimiento.
3 : solo se escriben mensajes informativos, de advertencia y de error.
 2 : solo se escriben mensajes de advertencia y de error.
1 : solo se escriben mensajes de error.
La forma habitual de obtener información de seguimiento detallada sobre el inicio de la aplicación es
establecer COREHOST_TRACE=1 y COREHOST_TRACEFILE=host_trace.txt y, luego, ejecutar la aplicación. Se
creará un nuevo archivo host_trace.txt en el directorio actual con la información detallada.

Vea también
Runtime Configuration Files (Archivos de configuración en tiempo de ejecución)
Opciones de configuración en tiempo de ejecución de .NET Core
 dotnet build
18/12/2020 • 10 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet build : compila un proyecto y todas sus dependencias.

Sinopsis
dotnet build [<PROJECT>|<SOLUTION>] [-c|--configuration <CONFIGURATION>]
[-f|--framework <FRAMEWORK>] [--force] [--interactive] [--no-dependencies]
[--no-incremental] [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
[-r|--runtime <RUNTIME_IDENTIFIER>] [--source <SOURCE>]
[-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet build -h|--help

Descripción
El comando dotnet build crea el proyecto y sus dependencias en un conjunto de archivos binarios. Los
archivos binarios incluyen el código del proyecto en archivos de lenguaje intermedio (IL) con una extensión .dll.
Según el tipo de proyecto y la configuración, se pueden incluir otros archivos, como los siguientes:
Un archivo ejecutable que se pueda usar para ejecutar la aplicación, si el tipo de proyecto es un archivo
ejecutable que tiene como destino .NET Core 3.0 o versiones posteriores.
Archivos de símbolos usados para la depuración con una extensión .pdb.
Un archivo .deps.json, que muestra las dependencias de la aplicación o la biblioteca.
Un archivo .runtimeconfig.json, que especifica el runtime compartido y su versión de una aplicación.
Otras bibliotecas de las que depende el proyecto (a través de referencias de proyecto o referencias de
paquetes NuGet).
En el caso de los proyectos ejecutables que tienen como destino versiones anteriores a .NET Core 3.0, las
dependencias de biblioteca de NuGet normalmente no se copian en la carpeta de salida. Se resuelven desde la
carpeta de paquetes globales NuGet en tiempo de ejecución. Teniendo eso en cuenta, el producto de
dotnet build no está listo para transferirse a otra máquina para ejecutarse. Para crear una versión de la
aplicación que se pueda implementar, se debe publicar (por ejemplo, con el comando dotnet publish). Para
obtener más información, vea Implementación de aplicaciones de .NET.
En el caso de los proyectos ejecutables que tienen como destino .NET Core 3.0 y versiones posteriores, las
dependencias de biblioteca se copian en la carpeta de salida. Esto significa que, si no hay ninguna otra lógica
específica de la publicación (como los proyectos web), se debería poder implementar la salida de la compilación.
Restauración implícita
La compilación requiere el archivo project.assets.json, que muestra las dependencias de la aplicación. El archivo
se crea cuando se ejecuta dotnet restore . Sin el archivo de recursos en su lugar, las herramientas no pueden
resolver los ensamblados de referencia, lo que se traduce en errores.
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan
que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test , dotnet publish
y dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .
El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los
sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore .
Este comando admite las opciones de dotnet restore cuando se pasan con el formato largo (por ejemplo,
--source ). No se admiten las opciones de formato corto, como -s .

Salida de biblioteca o ejecutable

Si el proyecto es ejecutable o no viene determinado por la propiedad <OutputType> en el archivo del proyecto.
En el ejemplo siguiente se muestra un proyecto en el que se genera código ejecutable:

<PropertyGroup>
<OutputType>Exe</OutputType>
</PropertyGroup>

Para generar una biblioteca, omita la propiedad <OutputType> o cambie su valor a Library . La DLL de IL para
una biblioteca no contiene puntos de entrada y no se puede ejecutar.
MSBuild
dotnet build usa MSBuild para compilar el proyecto, por lo que admite las compilaciones en paralelo e
incrementales. Para obtener más información, consulte Compilaciones incrementales.
Además de sus opciones, el comando dotnet build acepta opciones de MSBuild, como -p para establecer
propiedades o -l para definir un registrador. Para obtener más información sobre estas opciones, vea la
Referencia de la línea de comandos de MSBuild. O también puede usar el comando dotnet msbuild.
Ejecutar dotnet build es equivalente a ejecutar dotnet msbuild -restore ; sin embargo, el nivel de detalle
predeterminado de la salida es distinto.

Argumentos
PROJECT | SOLUTION

El archivo de proyecto o solución para compilar. Si no se especifica un archivo de proyecto o solución, MSBuild
busca en el directorio de trabajo actual un archivo que tiene una extensión de archivo que termina por proj o sln
y usa ese archivo.

Opciones
-c|--configuration <CONFIGURATION>

Define la configuración de compilación. El valor predeterminado para la mayoría de los proyectos es

Debug , pero puede invalidar los valores de configuración de compilación en el proyecto.

-f|--framework <FRAMEWORK>

Compila para un marco de trabajo específico. El marco se debe definir en el archivo de proyecto.
--force

Fuerza la resolución de todas las dependencias, incluso si la última restauración se realizó correctamente.
Especificar esta marca es lo mismo que eliminar el archivo project.assets.json.
 -h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se detenga y espere una entrada o una acción del usuario. Por ejemplo, para
completar la autenticación. Disponible desde el SDK de .NET Core 3.0.
--no-dependencies

Omite las referencias de proyecto a proyecto (P2P) y solo compila el proyecto raíz especificado.
--no-incremental

Marca la compilación como no segura para la compilación incremental. Esta marca desactiva la
compilación incremental y fuerza una recompilación limpia del gráfico de dependencias del proyecto.
--no-restore

No ejecuta una restauración implícita durante la compilación.

--nologo

No se muestra la pancarta de inicio ni el mensaje de copyright. Disponible desde el SDK de .NET Core 3.0.
-o|--output <OUTPUT_DIRECTORY>

Directorio donde se colocan los archivos binarios compilados. Si no se especifica la ruta de acceso
predeterminada es ./bin/<configuration>/<framework>/ . En el caso de los proyectos con varias
plataformas de destino (a través de la propiedad TargetFrameworks ), también debe definir --framework al
especificar esta opción.
-r|--runtime <RUNTIME_IDENTIFIER>

Especifica el tiempo de ejecución de destino. Para obtener una lista de identificadores de tiempo de
ejecución (RID), consulte el catálogo de RID.
--source <SOURCE>

URI del origen del paquete NuGet que se usará durante la operación de restauración.
-v|--verbosity <LEVEL>

Establece el nivel de detalle de MSBuild. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] . De manera predeterminada, es minimal .

--version-suffix <VERSION_SUFFIX>

Establece el valor de la propiedad $(VersionSuffix) que se va a usar al compilar el proyecto. Solo

funciona si no se establece la propiedad $(Version) . A continuación, $(Version) se establece en
$(VersionPrefix) combinada con $(VersionSuffix) , separadas por un guion.

Ejemplos
Creación de un proyecto y sus dependencias:

dotnet build

Creación de un proyecto y sus dependencias mediante la configuración de lanzamiento:

 dotnet build --configuration Release

Compilación de un proyecto y sus dependencias para un tiempo de ejecución concreto (en este ejemplo,
Ubuntu 18.04):

dotnet build --runtime ubuntu.18.04-x64

Compile el proyecto y use el origen del paquete NuGet especificado durante la operación de restauración:

dotnet build --source c:\packages\mypackages

Compile el proyecto y establezca la versión 1.2.3.4 como un parámetro de compilación mediante la

opción de MSBuild -p :

dotnet build -p:Version=1.2.3.4

 dotnet build-server
20/04/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

Name
dotnet build-server : interactúa con servidores iniciados por una compilación.

Sinopsis
dotnet build-server shutdown [--msbuild] [--razor] [--vbcscompiler]

dotnet build-server shutdown -h|--help

dotnet build-server -h|--help

Comandos
shutdown

Cierra los servidores de la compilación que se inician desde dotnet. De forma predeterminada, se cierran
todos los servidores.

Opciones
-h|--help

Imprime una corta ayuda para el comando.

--msbuild

Cierra el servidor de compilación de MSBuild.

--razor

Cierra el servidor de compilación de Razor.

--vbcscompiler

Cierra el servidor de compilación del compilador de VB/C#.

 dotnet clean
20/04/2020 • 3 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

Name
dotnet clean : limpia la salida de un proyecto.

Sinopsis
dotnet clean [<PROJECT>|<SOLUTION>] [-c|--configuration <CONFIGURATION>]
[-f|--framework <FRAMEWORK>] [--interactive]
[--nologo] [-o|--output <OUTPUT_DIRECTORY>]
[-r|--runtime <RUNTIME_IDENTIFIER>] [-v|--verbosity <LEVEL>]

dotnet clean -h|--help

Description
El comando dotnet clean limpia la salida de la compilación anterior. Se implementa como un destino MSBuild,
por lo que el proyecto se evalúa cuando se ejecuta el comando. Solo se limpian las salidas que se crearon durante
la compilación. Se limpian las carpetas intermedias (obj) y de la salida final (bin).

Argumentos
PROJECT | SOLUTION

Proyecto o solución de MSBuild que se va a limpiar. Si no se especifica un archivo de proyecto o solución, MSBuild
busca en el directorio de trabajo actual un archivo que tenga una extensión de archivo que termine en proj o sln y
lo usa.

Opciones
-c|--configuration <CONFIGURATION>

Define la configuración de compilación. El valor predeterminado para la mayoría de los proyectos es Debug ,
pero puede invalidar los valores de configuración de compilación en el proyecto. Esta opción solo es
necesaria al realizar la limpieza si la especificó durante el tiempo de compilación.
-f|--framework <FRAMEWORK>

El marco que se especificó en tiempo de compilación. El marco se debe definir en el archivo de proyecto. Si
especificó el marco en tiempo de compilación, debe especificar el marco al realizar la limpieza.
-h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se detenga y espere una entrada o una acción del usuario. Por ejemplo, para
 completar la autenticación. Disponible desde el SDK de .NET Core 3.0.
--nologo

No se muestra la pancarta de inicio ni el mensaje de copyright. Disponible desde el SDK de .NET Core 3.0.
-o|--output <OUTPUT_DIRECTORY>

Directorio que contiene los artefactos compilados que se van a limpiar. Especifique el modificador
-f|--framework <FRAMEWORK> con el modificador del directorio de salida si especificó el marco cuando se
compiló el proyecto.
-r|--runtime <RUNTIME_IDENTIFIER>

Limpia la carpeta de salida del tiempo de ejecución especificado. Esto se usa si se ha creado una
implementación autocontenida.
-v|--verbosity <LEVEL>

Establece el nivel de detalle de MSBuild. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] . El valor predeterminado es normal .

Ejemplos
Limpie una compilación predeterminada del proyecto:

dotnet clean

Limpie un proyecto creado con la configuración de lanzamiento:

dotnet clean --configuration Release

 Referencia de dotnet help
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.0 y versiones posteriores

Name
dotnet help : muestra documentación más detallada en línea para el comando especificado.

Sinopsis
dotnet help <COMMAND_NAME> [-h|--help]

Description
El comando dotnet help abre la página de referencia para obtener información más detallada sobre el comando
especificado en docs.microsoft.com.

Argumentos
COMMAND_NAME

Nombre del comando de la CLI de .NET. Para obtener una lista de los comandos de la CLI válidos, vea
Comandos de la CLI.

Opciones
-h|--help

Imprime una corta ayuda para el comando.

Ejemplos
Se abre la página de documentación del comando dotnet new:

dotnet help new

 dotnet migrate
02/11/2020 • 5 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x

NOMBRE
dotnet migrate : migra un proyecto .NET Core de la versión preliminar 2 a un proyecto del estilo de SDK de .NET
Core.

Sinopsis
dotnet migrate [<SOLUTION_FILE|PROJECT_DIR>] [--format-report-file-json <REPORT_FILE>]
[-r|--report-file <REPORT_FILE>] [-s|--skip-project-references [Debug|Release]]
[--skip-backup] [-t|--template-file <TEMPLATE_FILE>] [-v|--sdk-package-version]
[-x|--xproj-file]

dotnet migrate -h|--help

Descripción
Este comando está en desuso. El comando dotnet migrate ya no está disponible a partir del SDK de .NET Core 3.0.
Solo puede migrar un proyecto de .NET Core de la versión preliminar 2 a un proyecto de .NET Core 1.x, para el que
no hay soporte técnico.
De forma predeterminada, el comando migra el proyecto raíz y todas las referencias de proyecto que contiene.
Este comportamiento se deshabilita mediante la opción --skip-project-references en tiempo de ejecución.
La migración se puede realizar en los recursos siguientes:
Un único proyecto mediante la especificación del archivo project.json que quiere migrar.
Todos los directorios especificados en el archivo global.json pasando una ruta al archivo global.json.
Un archivo solution.sln, donde se migran los proyectos a los que se hace referencia en la solución.
Todos los subdirectorios del directorio dado de manera recursiva.
El comando dotnet migrate mantiene el archivo project.json migrado dentro de un directorio backup , que se crea
en caso de que no exista. Este comportamiento se invalida con la opción --skip-backup .
De forma predeterminada, la operación de migración genera el estado del proceso de migración a la salida
estándar (STDOUT). Si usa la opción --report-file <REPORT_FILE> , la salida se guarda en el archivo especificado.
El comando dotnet migrate solo admite proyectos válidos basados en project.json de la versión preliminar 2. Esto
significa que no se puede usar para migrar DNX o los proyectos basados en project.json de la versión preliminar 1
directamente a proyectos de MSBuild/csproj. Primero debe migrar manualmente el proyecto a un proyecto
basado en project.json de la versión preliminar 2 y luego usar el comando dotnet migrate para migrar el
proyecto.

Argumentos
PROJECT_JSON/GLOBAL_JSON/SOLUTION_FILE/PROJECT_DIR
La ruta de acceso a uno de los siguientes elementos:
Un archivo project.json para migrar.
Un archivo global.json: se migran las carpetas especificadas en global.json.
Un archivo solution.sln: se migran los proyectos a los que se hace referencia en la solución.
Un directorio para migrar: se buscan de forma recursiva los archivos project.json que se van a migrar dentro
del directorio especificado.
Si no se especifica nada, se toma como valor predeterminado el directorio actual.

Opciones
--format-report-file-json <REPORT_FILE>

Salida del archivo de informe de migración como JSON en lugar de mensajes de usuario.
-h|--help

Imprime una corta ayuda para el comando.

-r|--report-file <REPORT_FILE>

Salida del informe de migración a un archivo además de a la consola.

-s|--skip-project-references [Debug|Release]

Omite la migración de referencias de proyecto. De forma predeterminada, las referencias de proyecto se migran
de forma recursiva.
--skip-backup

Omite el traslado de project.json, global.json y *.xproj a un directorio backup tras la realización correcta de la
migración.
-t|--template-file <TEMPLATE_FILE>

Archivo csproj de plantilla que se utilizará para la migración. De forma predeterminada, se usa la misma plantilla
que la descartada por dotnet new console .
-v|--sdk-package-version <VERSION>

La versión del paquete sdk a la que se hace referencia en la aplicación migrada. El valor predeterminado es la
versión del SDK en dotnet new .
-x|--xproj-file <FILE>

La ruta de acceso al archivo xproj que se usará. Necesario cuando hay más de un archivo xproj en un directorio de
proyecto.

Ejemplos
Migrar un proyecto del directorio actual y todas sus dependencias de proyecto a proyecto:
dotnet migrate

Migrar todos los proyectos que incluyen el archivo global.json:

dotnet migrate path/to/global.json

Migrar solo el proyecto actual y ninguna dependencia de proyecto a proyecto (P2P). Además, usar una versión
específica de SDK:
dotnet migrate -s -v 1.0.0-preview4
 dotnet msbuild
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet msbuild : compila un proyecto y todas sus dependencias. Nota: Si hay varios, es posible que sea necesario
especificar una solución o un archivo de proyecto.

Sinopsis
dotnet msbuild <MSBUILD_ARGUMENTS>

dotnet msbuild -h

Descripción
El comando dotnet msbuild permite el acceso a una instancia de MSBuild completamente funcional.
El comando tiene exactamente las mismas funcionalidades que el cliente de línea de comandos de MSBuild
existente solo para proyectos de estilo SDK. Las opciones son las mismas. Para obtener más información sobre
las opciones disponibles, vea Referencia de la línea de comandos de MSBuild.
El comando dotnet build es equivalente al comando dotnet msbuild -restore . Si no quiere compilar el proyecto
y hay un destino concreto que quiere ejecutar, use dotnet build o dotnet msbuild y especifique el destino.

Ejemplos
Creación de un proyecto y sus dependencias:

dotnet msbuild

Creación de un proyecto y sus dependencias mediante la configuración de lanzamiento:

dotnet msbuild -property:Configuration=Release

Ejecuta el destino de publicación y publica para el RID osx.10.11-x64 :

dotnet msbuild -target:Publish -property:RuntimeIdentifiers=osx.10.11-x64

Visualización del proyecto completo con todos los destinos incluidos en el SDK:

dotnet msbuild -preprocess

dotnet msbuild -preprocess:<fileName>.xml
 dotnet new
18/12/2020 • 35 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.0 y versiones posteriores

NOMBRE
dotnet new : crea un nuevo proyecto, archivo de configuración o solución según la plantilla especificada.

Sinopsis
dotnet new <TEMPLATE> [--dry-run] [--force] [-i|--install {PATH|NUGET_ID}]
[-lang|--language {"C#"|"F#"|VB}] [-n|--name <OUTPUT_NAME>]
[--nuget-source <SOURCE>] [-o|--output <OUTPUT_DIRECTORY>]
[-u|--uninstall] [--update-apply] [--update-check] [Template options]

dotnet new <TEMPLATE> [-l|--list] [--type <TYPE>]

dotnet new -h|--help

Descripción
El comando dotnet new crea un proyecto de .NET u otros artefactos basados en una plantilla.
El comando llama al motor de plantillas para crear los artefactos en el disco basándose en las opciones y
la plantilla especificadas.
Restauración implícita
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que
necesitan que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test ,
dotnet publish y dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en
los sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de
dotnet restore .

Argumentos
TEMPLATE

La plantilla de la que se va a crear una instancia cuando se invoca el comando. Cada plantilla
puede tener opciones específicas que puede pasar. Para obtener más información, vea Opciones
de plantilla.
Puede ejecutar dotnet new --list o dotnet new -l para ver una lista de todas las plantillas
instaladas. Si el valor TEMPLATE no es una coincidencia exacta con el texto de la columna
Plantillas o Nombre cor to de la tabla devuelta, se realiza una coincidencia de subcadena con
esas dos columnas.
 A partir del SDK de .NET Core 3.0, la CLI busca plantillas en NuGet.org al invocar el comando
dotnet new en las siguientes condiciones:

Si la CLI no encuentra ninguna coincidencia de plantilla al invocar dotnet new , ni siquiera

parcial.
Si hay disponible una versión más reciente de la plantilla. En este caso, se crea el proyecto o el
artefacto, pero la CLI le advierte de que hay una versión actualizada de la plantilla.
En la tabla siguiente se muestran las plantillas que vienen preinstaladas con el SDK de .NET. El
lenguaje predeterminado de la plantilla se muestra entre corchetes. Haga clic en el vínculo del
nombre corto para ver las opciones específicas de la plantilla.

P L A N T IL L A S N O M B RE C O RTO L EN GUA JE ET IQ UETA S IN C L USIÓ N

Aplicación de console [C#], F#, VB Común/Consola 1.0

consola

Biblioteca de clases classlib [C#], F#, VB Común/Biblioteca 1.0

Aplicación WPF wpf [C#], VB Común/WPF 3.0 (5.0 para VB)

Biblioteca de clases wpflib [C#], VB Común/WPF 3.0 (5.0 para VB)

de WPF

Biblioteca de wpfcustomcontrolli [C#], VB Común/WPF 3.0 (5.0 para VB)

controles b
personalizados WPF

Biblioteca de wpfusercontrollib [C#], VB Común/WPF 3.0 (5.0 para VB)

controles de
usuario de WPF

Aplicación de winforms [C#], VB Común/WinForms 3.0 (5.0 para VB)

Windows Forms
(WinForms)

Biblioteca de clases winformslib [C#], VB Común/WinForms 3.0 (5.0 para VB)

de Windows Forms
(WinForms)

Servicio Worker worker [C#] Común/Worker/We 3.0

b

Proyecto de prueba mstest [C#], F#, VB Prueba/MSTest 1.0

unitaria

Proyecto de prueba nunit [C#], F#, VB Prueba/NUnit 2.1.400

de NUnit 3

Elemento de nunit-test [C#], F#, VB Prueba/NUnit 2.2

prueba de NUnit 3

Proyecto de prueba xunit [C#], F#, VB Prueba/xUnit 1.0

de xUnit

Componente Razor razorcomponent [C#] Web/ASP.NET 3.0

P L A N T IL L A S N O M B RE C O RTO L EN GUA JE ET IQ UETA S IN C L USIÓ N

Página de Razor page [C#] Web/ASP.NET 2.0

MVC ViewImports viewimports [C#] Web/ASP.NET 2.0

MVC ViewStart viewstart [C#] Web/ASP.NET 2.0

Blazor Aplicación de blazorserver [C#] Web/Blazor 3.0

servidor

Aplicación de Blazor blazorwasm [C#] Web/Blazor/WebAs 3.1.300

WebAssembly sembly

Vacío de ASP.NET web [C#], F# Web/Vacío 1.0

Core

Aplicación web de mvc [C#], F# Web/MVC 1.0

ASP.NET Core
(Model-View-
Controller)

Aplicación web de webapp, razor [C#] Web/MVC/Razor 2.2, 2.0

ASP.NET Core Pages

ASP.NET Core con angular [C#] Web/MVC/SPA 2.0

Angular

ASP.NET Core con react [C#] Web/MVC/SPA 2.0

React.js

ASP.NET Core con reactredux [C#] Web/MVC/SPA 2.0

React.js y Redux

Biblioteca de clases razorclasslib [C#] Web/Razor/Bibliote 2.1

de Razor ca/Biblioteca de
clases de Razor

API web de ASP.NET webapi [C#], F# Web/WebAPI 1.0

Core

Servicio gRPC de grpc [C#] Web/gRPC 3.0

ASP.NET Core

Archivo dotnet gitignore Configuración 3.0

gitignore

archivo global.json globaljson Configuración 2.0

Configuración de nugetconfig Configuración 1.0

NuGet

Archivo de tool-manifest Configuración 3.0

manifiesto de la
herramienta local
dotnet
 P L A N T IL L A S N O M B RE C O RTO L EN GUA JE ET IQ UETA S IN C L USIÓ N

Configuración web webconfig Configuración 1.0

Archivo de solución sln Soluciones 1.0

Archivo de búfer de proto Web/gRPC 3.0

protocolo

Opciones
--dry-run

Muestra un resumen de lo que sucedería si se ejecutara el comando determinado y el resultado

fuera la creación de una plantilla. Disponible a partir del SDK de .NET Core 2.2.
--force

Fuerza la generación de contenido incluso aunque se vayan a cambiar los archivos existentes. Es
necesario si la plantilla elegida invalidará los archivos existentes en el directorio de salida.
-h|--help

Imprime la ayuda para el comando. Puede invocarse para el propio comando dotnet new o para
cualquier plantilla. Por ejemplo: dotnet new mvc --help .
-i|--install <PATH|NUGET_ID>

Instala un paquete de plantillas desde los parámetros PATH o NUGET_ID proporcionados. Si quiere
instalar una versión preliminar de un paquete de plantilla, tendrá que especificar la versión en el
formato de <package-name>::<package-version> . De forma predeterminada, dotnet new pasa *
para la versión, que representa la última versión estable del paquete. Vea un ejemplo en la sección
Ejemplos.
Si ya hay instalada una versión de la plantilla al ejecutar este comando, la plantilla se actualizará a
la versión especificada o a la versión estable más reciente si no se ha especificado ninguna
versión.
Para obtener información sobre cómo crear plantillas personalizadas, consulte Plantillas
personalizadas para dotnet new.
-l|--list

Muestra las plantillas que contienen el nombre especificado. Si no se especifica ningún nombre,
enumera todas las plantillas.
-lang|--language {C#|F#|VB}

El lenguaje de la plantilla que se va a crear. El lenguaje aceptado cambia según la plantilla (vea los
valores predeterminados en la sección argumentos). No es válido para algunas plantillas.
 NOTE
Algunos shells interpretan # como un carácter especial. En esos casos, incluya el valor del parámetro de
lenguaje entre comillas. Por ejemplo: dotnet new console -lang "F#" .

-n|--name <OUTPUT_NAME>

El nombre de la salida creada. Si no se especifica ningún nombre, se usa el nombre del directorio
actual.
--nuget-source <SOURCE>

Especifica un origen de NuGet para usarlo durante la instalación.

-o|--output <OUTPUT_DIRECTORY>

La ubicación para colocar la salida generada. El valor predeterminado es el directorio actual.

--type <TYPE>

Filtra plantillas en función de los tipos disponibles. Los valores predefinidos son project e item .
-u|--uninstall [PATH|NUGET_ID]

Desinstala un paquete de plantillas en los parámetros PATH o NUGET_ID proporcionados. Si no se

especifica el valor <PATH|NUGET_ID> , se muestran todos los paquetes de plantillas instalados
actualmente y sus plantillas asociadas. Al especificar NUGET_ID , no incluya el número de versión.
Si no especifica un parámetro en esta opción, el comando muestra las plantillas instaladas y
detalles sobre ellas.

NOTE
Para desinstalar una plantilla mediante PATH , debe usar el nombre completo de la ruta de acceso. Por
ejemplo, C:/Users/<USER>/Documents/Templates/GarciaSoftware.ConsoleTemplate.CSharp funcionará,
pero ./GarciaSoftware.ConsoleTemplate.CSharp desde la carpeta contenedora no lo hará. No incluya
ninguna barra diagonal para finalizar el directorio en la ruta de acceso a la plantilla.

--update-apply

Comprueba si hay actualizaciones disponibles de los paquetes de plantillas instalados

actualmente y las instala. Disponible desde el SDK de .NET Core 3.0.
--update-check

Comprueba si hay actualizaciones disponibles de los paquetes de plantillas instalados

actualmente. Disponible desde el SDK de .NET Core 3.0.

Opciones de plantilla
Cada plantilla de proyecto puede tener opciones adicionales disponibles. Las plantillas principales tienen
las siguientes opciones adicionales:
consola
-f|--framework <FRAMEWORK>

Especifica el marco de destino. Disponible desde el SDK de .NET Core 3.0.

 En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

--langVersion <VERSION_NUMBER>

Establece la propiedad LangVersion en el archivo del proyecto creado. Por ejemplo, use
--langVersion 7.3 para emplear C# 7.3. No es compatible con F#. Disponible a partir del SDK de
.NET Core 2.2.
Para obtener una lista de las versiones predeterminadas de C#, vea Valores predeterminados.
--no-restore

Si se especifica, no se ejecuta ninguna restauración implícita durante la creación del proyecto.

Disponible a partir del SDK de .NET Core 2.2.
**
classlib
_ -f|--framework <FRAMEWORK> *
Especifica el marco de destino. Valores: net5.0 o netcoreapp<version> para crear una biblioteca
de clases de .NET, o bien netstandard<version> para crear una de .NET Standard. El valor
predeterminado para el SDK de .NET 5.0 es net5.0 .
--langVersion <VERSION_NUMBER>

Establece la propiedad LangVersion en el archivo del proyecto creado. Por ejemplo, use
--langVersion 7.3 para emplear C# 7.3. No es compatible con F#. Disponible a partir del SDK de
.NET Core 2.2.
Para obtener una lista de las versiones predeterminadas de C#, vea Valores predeterminados.
--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
wpf, wpflib, wpfcustomcontrollib, wpfusercontrollib
_ -f|--framework <FRAMEWORK> *
Especifica el marco de destino. El valor predeterminado es net5.0 . Disponible a partir del SDK de
.NET Core 3.1.
--langVersion <VERSION_NUMBER>

Establece la propiedad LangVersion en el archivo del proyecto creado. Por ejemplo, use
--langVersion 7.3 para emplear C# 7.3.

Para obtener una lista de las versiones predeterminadas de C#, vea Valores predeterminados.
 --no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
winforms, winformslib
_ --langVersion <VERSION_NUMBER> *
Establece la propiedad LangVersion en el archivo del proyecto creado. Por ejemplo, use
--langVersion 7.3 para emplear C# 7.3.

Para obtener una lista de las versiones predeterminadas de C#, vea Valores predeterminados.
--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
worker, grpc
_ -f|--framework <FRAMEWORK> *
Especifica el marco de destino. El valor predeterminado es netcoreapp3.1 . Disponible a partir del
SDK de .NET Core 3.1.
--exclude-launch-settings

Excluye launchSettings.json de la plantilla generada.

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
mstest, xunit
_ -f|--framework <FRAMEWORK> *
Especifica el marco de destino. Opción disponible a partir del SDK de .NET Core 3.0.
En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

-p|--enable-pack

Habilita el empaquetado del proyecto mediante dotnet pack.

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
nunit
_ -f|--framework <FRAMEWORK> *
Especifica el marco de destino.
En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

2.2 netcoreapp2.2

2.1 netcoreapp2.1

-p|--enable-pack

Habilita el empaquetado del proyecto mediante dotnet pack.

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
página
_ -na|--namespace <NAMESPACE_NAME> *
Espacio de nombres del código generado. El valor predeterminado es MyApp.Namespace .
-np|--no-pagemodel

Crea la página sin PageModel.

**
viewimports, proto
_ -na|--namespace <NAMESPACE_NAME> *
Espacio de nombres del código generado. El valor predeterminado es MyApp.Namespace .

**
blazorserver
_ -au|--auth <AUTHENTICATION_TYPE> *
Tipo de autenticación que se va a usar. Los valores posibles son:
None : sin autenticación (valor predeterminado).
Individual : autenticación individual.
IndividualB2C : autenticación individual con Azure AD B2C.
 SingleOrg : autenticación organizativa para un solo inquilino.
MultiOrg : autenticación organizativa para varios inquilinos.
Windows : autenticación de Windows.
--aad-b2c-instance <INSTANCE>

Instancia de Azure Active Directory B2C con la que se realiza la conexión. Úsela con la
autenticación IndividualB2C . El valor predeterminado es https://login.microsoftonline.com/tfp/ .
-ssp|--susi-policy-id <ID>

Identificador de la directiva de registro e inicio de sesión de este proyecto. Úsela con la

autenticación IndividualB2C .
-rp|--reset-password-policy-id <ID>

Identificador de la directiva de restablecimiento de contraseñas de este proyecto. Úsela con la

autenticación IndividualB2C .
-ep|--edit-profile-policy-id <ID>

Identificador de la directiva de edición de perfiles de este proyecto. Úsela con la autenticación

IndividualB2C .

--aad-instance <INSTANCE>

Instancia de Azure Active Directory con la que se realiza la conexión. Úsela con las autenticaciones
SingleOrg o MultiOrg . El valor predeterminado es https://login.microsoftonline.com/ .

--client-id <ID>

Identificador de cliente de este proyecto. Úsela con las autenticaciones IndividualB2C , SingleOrg
o MultiOrg . El valor predeterminado es 11111111-1111-1111-11111111111111111 .
--domain <DOMAIN>

Dominio del inquilino del directorio. Úsela con las autenticaciones SingleOrg o IndividualB2C . El
valor predeterminado es qualified.domain.name .
--tenant-id <ID>

Identificador de inquilino del directorio con el que se realiza la conexión. Úsela con la
autenticación SingleOrg . El valor predeterminado es 22222222-2222-2222-2222-222222222222 .
--callback-path <PATH>

Ruta de acceso de solicitud de la ruta de acceso de la base de la aplicación del URI de redirección.
Úsela con las autenticaciones SingleOrg o IndividualB2C . El valor predeterminado es
/signin-oidc .

-r|--org-read-access

Concede a esta aplicación acceso de lectura al directorio. Solo se aplica a las autenticaciones
SingleOrg y MultiOrg .

--exclude-launch-settings

Excluye launchSettings.json de la plantilla generada.

--no-https
 Desactiva HTTPS. Esta opción solo se aplica si no se usan Individual , IndividualB2C , SingleOrg
o MultiOrg en --auth .
-uld|--use-local-db

Especifica que se debería usar LocalDB en vez de SQLite. Solo se aplica a las autenticaciones
Individual y IndividualB2C .

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
blazorwasm
_ -f|--framework <FRAMEWORK> *
Especifica el marco de destino.
En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

-ho|--hosted

Incluye un host de ASP.NET Core para la aplicación Blazor WebAssembly.

-au|--auth <AUTHENTICATION_TYPE>

Tipo de autenticación que se va a usar. Los valores posibles son:

None : sin autenticación (valor predeterminado).
Individual : autenticación individual.
IndividualB2C : autenticación individual con Azure AD B2C.
SingleOrg : autenticación organizativa para un solo inquilino.
--authority <AUTHORITY>

La autoridad del proveedor de OIDC. Úsela con la autenticación Individual . El valor

predeterminado es https://login.microsoftonline.com/ .
--aad-b2c-instance <INSTANCE>

Instancia de Azure Active Directory B2C con la que se realiza la conexión. Úsela con la
autenticación IndividualB2C . El valor predeterminado es https://aadB2CInstance.b2clogin.com/ .
-ssp|--susi-policy-id <ID>

Identificador de la directiva de registro e inicio de sesión de este proyecto. Úsela con la

autenticación IndividualB2C .
--aad-instance <INSTANCE>

Instancia de Azure Active Directory con la que se realiza la conexión. Úsela con la autenticación
SingleOrg . El valor predeterminado es https://login.microsoftonline.com/ .

--client-id <ID>

Identificador de cliente de este proyecto. Úselo con la autenticación IndividualB2C , SingleOrg o

Individual en escenarios independientes. El valor predeterminado es
33333333-3333-3333-33333333333333333 .

--domain <DOMAIN>

Dominio del inquilino del directorio. Úsela con las autenticaciones SingleOrg o IndividualB2C . El
valor predeterminado es qualified.domain.name .
--app-id-uri <URI>

El URI del id. de la aplicación de la API de servidor a la que quiere llamar. Úsela con las
autenticaciones SingleOrg o IndividualB2C . El valor predeterminado es api.id.uri .
--api-client-id <ID>

El id. de cliente de la API que el servidor hospeda. Úsela con las autenticaciones SingleOrg o
IndividualB2C . El valor predeterminado es 11111111-1111-1111-11111111111111111 .

-s|--default-scope <SCOPE>

El ámbito de la API que el cliente debe solicitar para aprovisionar un token de acceso. Úsela con
las autenticaciones SingleOrg o IndividualB2C . El valor predeterminado es user_impersonation .
--tenant-id <ID>

Identificador de inquilino del directorio con el que se realiza la conexión. Úsela con la
autenticación SingleOrg . El valor predeterminado es 22222222-2222-2222-2222-222222222222 .
-r|--org-read-access

Concede a esta aplicación acceso de lectura al directorio. Solo se aplica a la autenticación

SingleOrg .

--exclude-launch-settings

Excluye launchSettings.json de la plantilla generada.

-p|--pwa

Genera una aplicación web progresiva (PWA) que admite la instalación y el uso sin conexión.
--no-https

Desactiva HTTPS. Esta opción solo se aplica si no se usan Individual , IndividualB2C o SingleOrg
en --auth .
-uld|--use-local-db

Especifica que se debería usar LocalDB en vez de SQLite. Solo se aplica a las autenticaciones
Individual y IndividualB2C .

--called-api-url <URL>

Dirección URL de la API que se va a llamar desde la aplicación web. Solo se aplica a la
 autenticación SingleOrg o IndividualB2C sin un host especificado de ASP.NET Core. El valor
predeterminado es https://graph.microsoft.com/v1.0/me .
--calls-graph

Especifica si la aplicación web llama a Microsoft Graph. Solo se aplica a la autenticación

SingleOrg .

--called-api-scopes <SCOPES>

Ámbitos para solicitar llamar a la API desde la aplicación web. Solo se aplica a la autenticación
SingleOrg o IndividualB2C sin un host especificado de ASP.NET Core. De manera
predeterminada, es user.read .

**
web
_ --exclude-launch-settings *
Excluye launchSettings.json de la plantilla generada.
-f|--framework <FRAMEWORK>

Especifica el marco de destino. Opción no disponible en el SDK de .NET Core 2.2.

En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

2.1 netcoreapp2.1

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

--no-https

Desactiva HTTPS.
**
mvc, webapp
_ -au|--auth <AUTHENTICATION_TYPE> *
Tipo de autenticación que se va a usar. Los valores posibles son:
None : sin autenticación (valor predeterminado).
Individual : autenticación individual.
IndividualB2C : autenticación individual con Azure AD B2C.
SingleOrg : autenticación organizativa para un solo inquilino.
MultiOrg : autenticación organizativa para varios inquilinos.
 Windows : autenticación de Windows.
--aad-b2c-instance <INSTANCE>

Instancia de Azure Active Directory B2C con la que se realiza la conexión. Úsela con la
autenticación IndividualB2C . El valor predeterminado es https://login.microsoftonline.com/tfp/ .
-ssp|--susi-policy-id <ID>

Identificador de la directiva de registro e inicio de sesión de este proyecto. Úsela con la

autenticación IndividualB2C .
-rp|--reset-password-policy-id <ID>

Identificador de la directiva de restablecimiento de contraseñas de este proyecto. Úsela con la

autenticación IndividualB2C .
-ep|--edit-profile-policy-id <ID>

Identificador de la directiva de edición de perfiles de este proyecto. Úsela con la autenticación

IndividualB2C .

--aad-instance <INSTANCE>

Instancia de Azure Active Directory con la que se realiza la conexión. Úsela con las autenticaciones
SingleOrg o MultiOrg . El valor predeterminado es https://login.microsoftonline.com/ .

--client-id <ID>

Identificador de cliente de este proyecto. Úsela con las autenticaciones IndividualB2C , SingleOrg
o MultiOrg . El valor predeterminado es 11111111-1111-1111-11111111111111111 .
--domain <DOMAIN>

Dominio del inquilino del directorio. Úsela con las autenticaciones SingleOrg o IndividualB2C . El
valor predeterminado es qualified.domain.name .
--tenant-id <ID>

Identificador de inquilino del directorio con el que se realiza la conexión. Úsela con la
autenticación SingleOrg . El valor predeterminado es 22222222-2222-2222-2222-222222222222 .
--callback-path <PATH>

Ruta de acceso de solicitud de la ruta de acceso de la base de la aplicación del URI de redirección.
Úsela con las autenticaciones SingleOrg o IndividualB2C . El valor predeterminado es
/signin-oidc .

-r|--org-read-access

Concede a esta aplicación acceso de lectura al directorio. Solo se aplica a las autenticaciones
SingleOrg y MultiOrg .

--exclude-launch-settings

Excluye launchSettings.json de la plantilla generada.

--no-https

Desactiva HTTPS. Esta opción solo se aplica si no se usan Individual , IndividualB2C , SingleOrg
o MultiOrg .
 -uld|--use-local-db

Especifica que se debería usar LocalDB en vez de SQLite. Solo se aplica a las autenticaciones
Individual y IndividualB2C .

-f|--framework <FRAMEWORK>

Especifica el marco de destino. Opción disponible a partir del SDK de .NET Core 3.0.
En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

--use-browserlink

Incluye BrowserLink en el proyecto. Opción no disponible en el SDK de .NET Core 2.2 y 3.1.
-rrc|--razor-runtime-compilation

Determina si el proyecto está configurado para usar la compilación en tiempo de ejecución de

Razor en las compilaciones de depuración. Opción disponible a partir del SDK de
.NET Core 3.1.201.
**
angular, react
_ -au|--auth <AUTHENTICATION_TYPE> *
Tipo de autenticación que se va a usar. Disponible desde el SDK de .NET Core 3.0.
Los valores posibles son:
None : sin autenticación (valor predeterminado).
Individual : autenticación individual.
--exclude-launch-settings

Excluye launchSettings.json de la plantilla generada.

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

--no-https

Desactiva HTTPS. Esta opción solo se aplica si la autenticación es None .

-uld|--use-local-db

Especifica que se debería usar LocalDB en vez de SQLite. Solo se aplica a las autenticaciones
 Individual y IndividualB2C . Disponible desde el SDK de .NET Core 3.0.
-f|--framework <FRAMEWORK>

Especifica el marco de destino. Opción no disponible en el SDK de .NET Core 2.2.

En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

2.1 netcoreapp2.0

**
reactredux
_ --exclude-launch-settings *
Excluye launchSettings.json de la plantilla generada.
-f|--framework <FRAMEWORK>

Especifica el marco de destino. Opción no disponible en el SDK de .NET Core 2.2.

En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

2.1 netcoreapp2.0

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

--no-https

Desactiva HTTPS.
**
razorclasslib
_ --no-restore *
No se ejecuta ninguna restauración implícita durante la creación del proyecto.
 -s|--support-pages-and-views

Permite agregar vistas y páginas de Razor tradicionales además de los componentes a esta
biblioteca. Disponible desde el SDK de .NET Core 3.0.
**
webapi
_ -au|--auth <AUTHENTICATION_TYPE> *
Tipo de autenticación que se va a usar. Los valores posibles son:
None : sin autenticación (valor predeterminado).
IndividualB2C : autenticación individual con Azure AD B2C.
SingleOrg : autenticación organizativa para un solo inquilino.
Windows : autenticación de Windows.
--aad-b2c-instance <INSTANCE>

Instancia de Azure Active Directory B2C con la que se realiza la conexión. Úsela con la
autenticación IndividualB2C . El valor predeterminado es https://login.microsoftonline.com/tfp/ .
-ssp|--susi-policy-id <ID>

Identificador de la directiva de registro e inicio de sesión de este proyecto. Úsela con la

autenticación IndividualB2C .
--aad-instance <INSTANCE>

Instancia de Azure Active Directory con la que se realiza la conexión. Úsela con la autenticación
SingleOrg . El valor predeterminado es https://login.microsoftonline.com/ .

--client-id <ID>

Identificador de cliente de este proyecto. Úsela con las autenticaciones IndividualB2C o

SingleOrg . El valor predeterminado es 11111111-1111-1111-11111111111111111 .

--domain <DOMAIN>

Dominio del inquilino del directorio. Úsela con las autenticaciones IndividualB2C o SingleOrg . El
valor predeterminado es qualified.domain.name .
--tenant-id <ID>

Identificador de inquilino del directorio con el que se realiza la conexión. Úsela con la
autenticación SingleOrg . El valor predeterminado es 22222222-2222-2222-2222-222222222222 .
-r|--org-read-access

Concede a esta aplicación acceso de lectura al directorio. Solo se aplica a la autenticación

SingleOrg .

--exclude-launch-settings

Excluye launchSettings.json de la plantilla generada.

--no-https

Desactiva HTTPS. app.UseHsts y app.UseHttpsRedirection no se agregan a Startup.Configure .

Esta opción solo se aplica si no se usan IndividualB2C o SingleOrg en la autenticación.
 -uld|--use-local-db

Especifica que se debería usar LocalDB en vez de SQLite. Solo se aplica a la autenticación
IndividualB2C .

-f|--framework <FRAMEWORK>

Especifica el marco de destino. Opción no disponible en el SDK de .NET Core 2.2.

En la tabla siguiente se enumeran los valores predeterminados según el número de versión del
SDK que esté usando:

VERSIÓ N DEL SDK VA LO R P REDET ERM IN A DO

5.0 net5.0

3.1 netcoreapp3.1

3.0 netcoreapp3.0

2.1 netcoreapp2.1

--no-restore

No se ejecuta ninguna restauración implícita durante la creación del proyecto.

**
globaljson
_ --sdk-version <VERSION_NUMBER> *
Especifica la versión del SDK de .NET que se va a usar en el archivo global.json.

Ejemplos
Creación de un proyecto de aplicación de consola de C# mediante la especificación del nombre de
plantilla:

dotnet new "Console Application"

Creación de un proyecto de aplicación de consola con F# en el directorio actual:

dotnet new console -lang "F#"

Creación de un proyecto de biblioteca de clases de .NET Standard en el directorio especificado:

dotnet new classlib -lang VB -o MyLibrary

Creación de un proyecto MVC de ASP.NET Core C# en el directorio actual sin autenticación:

dotnet new mvc -au None

Creación de un proyecto de xUnit:

 dotnet new xunit

Enumeración de todas las plantillas disponibles en las plantillas de aplicación de página única
(SPA):

dotnet new spa -l

Enumeración de todas las plantillas que coinciden con la subcadena we. No se encuentra ninguna
coincidencia exacta, por lo que se ejecuta la coincidencia de subcadena con las columnas de
nombre corto y de nombre.

dotnet new we -l

Intento de invocar a la plantilla que coincide con ng. Si no se puede determinar una única
coincidencia, se enumeran las plantillas que son coincidencias parciales.

dotnet new ng

Instalación de la versión 2.0 de las plantillas de SPA de ASP.NET Core:

dotnet new -i Microsoft.DotNet.Web.Spa.ProjectTemplates::2.0.0

Enumeración de las plantillas instaladas y detalles sobre ellas, incluido cómo desinstalarlas:

dotnet new -u

Creación de un archivo global.json en el directorio actual al establecer la versión del SDK en

3.1.101:

dotnet new globaljson --sdk-version 3.1.101

Vea también
Plantillas personalizadas para dotnet new
Creación de una plantilla personalizada para dotnet new
Repositorio de GitHub dotnet/dotnet-template-samples
Available templates for dotnet new (Plantillas disponibles para dotnet new)
 dotnet nuget delete
20/04/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 1.x y versiones posteriores

Name
dotnet nuget delete : elimina o quita de la lista un paquete del servidor.

Sinopsis
dotnet nuget delete [<PACKAGE_NAME> <PACKAGE_VERSION>] [--force-english-output]
[--interactive] [-k|--api-key <API_KEY>] [--no-service-endpoint]
[--non-interactive] [-s|--source <SOURCE>]

dotnet nuget delete -h|--help

Description
El comando dotnet nuget delete elimina o quita de la lista un paquete del servidor. Para nuget.org, la acción es
quitar de la lista el paquete.

Argumentos
PACKAGE_NAME

Nombre o id. del paquete que se va a eliminar.

PACKAGE_VERSION

Versión del paquete que se va a eliminar.

Opciones
--force-english-output

Fuerza la ejecución de la aplicación mediante una referencia cultural en inglés invariable.

-h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se bloquee y requiere una acción manual para operaciones tales como la
autenticación. Opción disponible a partir del SDK de .NET Core 2.2.
-k|--api-key <API_KEY>

La clave de API para el servidor.

--no-service-endpoint

No agrega "api/v2/paquete" a la dirección URL de origen. Opción disponible a partir del SDK de .NET Core
 2.1.
--non-interactive

No pide confirmaciones o entradas de usuario.

-s|--source <SOURCE>

Especifica la dirección URL del servidor. Las direcciones URL admitidas para nuget.org incluyen
https://www.nuget.org , https://www.nuget.org/api/v3 y https://www.nuget.org/api/v2/package . Para fuentes
privadas, reemplace el nombre de host (por ejemplo, %hostname%/api/v3 ).

Ejemplos
Elimina la versión 1.0 del paquete Microsoft.AspNetCore.Mvc :

dotnet nuget delete Microsoft.AspNetCore.Mvc 1.0

Elimina la versión 1.0 del paquete Microsoft.AspNetCore.Mvc , sin pedir al usuario credenciales u otra
información:

dotnet nuget delete Microsoft.AspNetCore.Mvc 1.0 --non-interactive

 dotnet nuget locals
20/04/2020 • 3 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

Name
dotnet nuget locals : borra o enumera recursos locales de NuGet.

Sinopsis
dotnet nuget locals <CACHE_LOCATION> [(-c|--clear)|(-l|--list)] [--force-english-output]

dotnet nuget locals -h|--help

Description
El comando dotnet nuget locals borra o enumera los recursos locales de NuGet en la caché de solicitudes http, la
caché temporal o la carpeta de paquetes globales de toda la máquina.

Argumentos
CACHE_LOCATION

La ubicación de caché que se va a mostrar o borrar. Acepta uno de los valores siguientes:
all : indica que la operación especificada se debe aplicar a todos los tipos de caché: caché de solicitudes
http, caché de paquetes globales y caché temporal.
http-cache : indica que la operación especificada se aplica solo a la caché de solicitudes http. Las otras
ubicaciones de caché no se ven afectadas.
global-packages : indica que la operación especificada se aplica solo a la caché de paquetes globales. Las
otras ubicaciones de caché no se ven afectadas.
temp : indica que la operación especificada se aplica solo a la caché temporal. Las otras ubicaciones de
caché no se ven afectadas.

Opciones
--force-english-output

Fuerza la ejecución de la aplicación mediante una referencia cultural en inglés invariable.

-h|--help

Imprime una corta ayuda para el comando.

-c|--clear

La opción de borrado ejecuta una operación de borrado sobre el tipo de caché especificado. El contenido de
los directorios de caché se elimina de forma recursiva. El usuario o grupo de ejecución deben tener permiso
para los archivos en los directorios de la caché. En caso contrario, se muestra un error para indicar los
archivos o las carpetas que no se han borrado.
 -l|--list

La opción de lista se usa para mostrar la ubicación del tipo de caché especificado.

Ejemplos
Muestra las rutas de acceso de todos los directorios de caché locales (el directorio de caché http, el
directorio de caché de paquetes globales y el directorio de caché temporal):

dotnet nuget locals all –l

Muestra la ruta de acceso del directorio de la caché de solicitudes http:

dotnet nuget locals http-cache --list

Borra todos los archivos de todos los directorios de caché locales (directorio de caché http, directorio de
caché de paquetes globales y directorio de caché temporal):

dotnet nuget locals all --clear

Borra todos los archivos del directorio local de la caché de paquetes globales:

dotnet nuget locals global-packages -c

Borra todos los archivos del directorio local de la caché temporal:

dotnet nuget locals temp -c

Solución de problemas
Para más información sobre problemas y errores comunes encontrados al usar el comando dotnet nuget locals ,
consulte Managing the NuGet cache (Administración de la caché de NuGet).
 dotnet nuget push
02/11/2020 • 5 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet nuget push : inserta un paquete en el servidor y lo publica.

Sinopsis
dotnet nuget push [<ROOT>] [-d|--disable-buffering] [--force-english-output]
[--interactive] [-k|--api-key <API_KEY>] [-n|--no-symbols true]
[--no-service-endpoint] [-s|--source <SOURCE>] [--skip-duplicate]
[-sk|--symbol-api-key <API_KEY>] [-ss|--symbol-source <SOURCE>]
[-t|--timeout <TIMEOUT>]

dotnet nuget push -h|--help

Descripción
El comando dotnet nuget push inserta un paquete en el servidor y lo publica. El comando push usa los detalles del
servidor y de las credenciales encontrados en el archivo de configuración NuGet del sistema o en la cadena de
archivos de configuración. Para más información sobre los archivos de configuración, consulte Configuring NuGet
Behavior (Configuración del comportamiento de NuGet). La configuración predeterminada de NuGet se obtiene
mediante la carga de %AppData%\NuGet\NuGet.config (Windows) o $HOME/.local/share (Linux/macOS), y luego
la carga de cualquier archivo nuget.config o .nuget\nuget.config comenzando desde la raíz de la unidad y
finalizando en el directorio actual.
El comando inserta un paquete existente. No crea un paquete. Para crear un paquete, use dotnet pack .

Argumentos
ROOT

Especifica la ruta de acceso al archivo en la que se debe insertar el paquete.

Opciones
-d|--disable-buffering

Deshabilita el almacenamiento en búfer al realizar inserciones en un servidor HTTP(S) para reducir el uso de
memoria.
--force-english-output

Fuerza la ejecución de la aplicación mediante una referencia cultural en inglés invariable.

-h|--help

Imprime una corta ayuda para el comando.

--interactive
 Permite que el comando se bloquee y requiere una acción manual para operaciones tales como la
autenticación. Opción disponible a partir del SDK de .NET Core 2.2.
-k|--api-key <API_KEY>

La clave de API para el servidor.

-n|--no-symbols true

No inserta símbolos (incluso si está presente).

--no-service-endpoint

No agrega "api/v2/paquete" a la dirección URL de origen. Opción disponible desde el SDK de .NET Core 2.1.
-s|--source <SOURCE>

Especifica la dirección URL del servidor. Esta opción es necesaria a menos que el valor de configuración
DefaultPushSource esté establecido en el archivo de configuración de NuGet.

--skip-duplicate

Al insertar varios paquetes en un servidor HTTP(S), trata cualquier respuesta de conflicto 409 como una
advertencia para que la inserción pueda continuar. Disponible a partir del SDK de .NET Core 3.1.
-sk|--symbol-api-key <API_KEY>

La clave de API para el servidor de símbolos.

-ss|--symbol-source <SOURCE>

Especifica la dirección URL del servidor de símbolos.

-t|--timeout <TIMEOUT>

Especifica el tiempo de espera para la inserción en un servidor en segundos. El valor predeterminado es 300
segundos (5 minutos). Si se especifica 0 (cero segundos), se aplica el valor predeterminado.

Ejemplos
Inserte foo.nupkg en el origen de inserción predeterminado y especifique una clave de API:

dotnet nuget push foo.nupkg -k 4003d786-cc37-4004-bfdf-c4f3e8ef9b3a

Inserte foo.nupkg en el servidor de NuGet oficial y especifique una clave de API:

dotnet nuget push foo.nupkg -k 4003d786-cc37-4004-bfdf-c4f3e8ef9b3a -s

https://api.nuget.org/v3/index.json

Inserta foo.nupkg en el origen de inserción personalizado https://customsource , y especifica una clave

de API:

dotnet nuget push foo.nupkg -k 4003d786-cc37-4004-bfdf-c4f3e8ef9b3a -s https://customsource/

Inserte foo.nupkg en el origen de inserción predeterminado:

dotnet nuget push foo.nupkg

Inserte foo.symbols.nupkp en el origen de símbolos predeterminado:

dotnet nuget push foo.symbols.nupkg

Inserte foo.nupkg en el origen de inserción predeterminado y especifique un tiempo de espera de

360 segundos:

dotnet nuget push foo.nupkg --timeout 360

Inserte todos los archivos .nupkg del directorio actual en el origen de inserción predeterminado:

dotnet nuget push "*.nupkg"

NOTE
Si este comando no funciona, es posible que se deba a un error presente en versiones anteriores del SDK (SDK de
.NET Core 2.1 y versiones anteriores). Para solucionar este problema, actualice la versión de su SDK o ejecute el
siguiente comando en su lugar: dotnet nuget push "**/*.nupkg"

NOTE
Las comillas de inclusión son necesarias para los shells como bash que usan comodines de archivo. Para obtener más
información, vea NuGet/Home#4393.

Inserte todos los archivos .nupkg, aunque un servidor HTTP(S) devuelva una respuesta de conflicto 409:

dotnet nuget push "*.nupkg" --skip-duplicate

Inserte todos los archivos .nupkg del directorio actual en un directorio de fuente local:

dotnet nuget push "*.nupkg" -s c:\mydir

Este comando no almacena paquetes en una estructura de carpetas jerárquica, lo que se recomienda para
optimizar el rendimiento. Para obtener más información, vea Fuentes locales.
 dotnet nuget add source
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.200 y versiones posteriores

NOMBRE
dotnet nuget add source : agrega un origen de NuGet.

Sinopsis
dotnet nuget add source <PACKAGE_SOURCE_PATH> [--name <SOURCE_NAME>] [--username <USER>]
[--password <PASSWORD>] [--store-password-in-clear-text]
[--valid-authentication-types <TYPES>] [--configfile <FILE>]

dotnet nuget add source -h|--help

Descripción
El comando dotnet nuget add source agrega un nuevo origen de paquete a los archivos de configuración de
NuGet.

Argumentos
PACKAGE_SOURCE_PATH

Ruta de acceso al origen del paquete.

Opciones
--configfile <FILE>

Archivo de configuración de NuGet. Si se especifica, solo se usará la configuración de este archivo. Si no se

especifica, se utilizará la jerarquía de archivos de configuración del directorio actual. Para más información,
consulte Configuraciones comunes de NuGet.
-n|--name <SOURCE_NAME>

Nombre del origen.

-p|--password <PASSWORD>

Contraseña que se debe usar al conectarse a un origen autenticado.

--store-password-in-clear-text

Deshabilita el cifrado de la contraseña para permitir el almacenamiento de las credenciales de origen del
paquete portátil.
-u|--username <USER>

Nombre de usuario que se usará al conectarse a un origen autenticado.

 --valid-authentication-types <TYPES>

Lista separada por comas de tipos de autenticación válidos para este origen. Establézcalo en basic si el
servidor anuncia NTLM o Negotiate y las credenciales deben enviarse mediante el mecanismo básico, por
ejemplo, cuando se usa una instancia de PAT con Azure DevOps Server local. Otros valores válidos son
negotiate , kerberos , ntlm y digest , pero es poco probable que estos valores sean útiles.

Ejemplos
Agregue nuget.org como origen:

dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org

Agregue c:\packages como origen local:

dotnet nuget add source c:\packages

Agregue un origen que necesite autenticación:

dotnet nuget add source https://someServer/myTeam -n myTeam -u myUsername -p myPassword --store-

password-in-clear-text

Agregue un origen que necesite autenticación (luego, pase a la instalación del proveedor de credenciales):

dotnet nuget add source https://azureartifacts.microsoft.com/myTeam -n myTeam

Vea también
Secciones de origen del paquete en archivos NuGet.config
Comando sources (nuget.exe)
 dotnet nuget disable source
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.200 y versiones posteriores

NOMBRE
dotnet nuget disable source : deshabilita un origen de NuGet.

Sinopsis
dotnet nuget disable source <NAME> [--configfile <FILE>]

dotnet nuget disable source -h|--help

Descripción
El comando dotnet nuget disable source deshabilita un origen existente en los archivos de configuración de
NuGet.

Argumentos
NAME

Nombre del origen.

Opciones
--configfile <FILE>

Archivo de configuración de NuGet. Si se especifica, solo se usará la configuración de este archivo. Si no se

especifica, se utilizará la jerarquía de archivos de configuración del directorio actual. Para más información,
consulte Configuraciones comunes de NuGet.

Ejemplos
Deshabilite un origen con el nombre de mySource :

dotnet nuget disable source mySource

Vea también
Secciones de origen del paquete en archivos NuGet.config
Comando sources (nuget.exe)
 dotnet nuget enable source
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.200 y versiones posteriores

NOMBRE
dotnet nuget enable source : habilita un origen de NuGet.

Sinopsis
dotnet nuget enable source <NAME> [--configfile <FILE>]

dotnet nuget enable source -h|--help

Descripción
El comando dotnet nuget enable source habilita un origen existente en los archivos de configuración de NuGet.

Argumentos
NAME

Nombre del origen.

Opciones
--configfile <FILE>

Archivo de configuración de NuGet. Si se especifica, solo se usará la configuración de este archivo. Si no se

especifica, se utilizará la jerarquía de archivos de configuración del directorio actual. Para más información,
consulte Configuraciones comunes de NuGet.

Ejemplos
Habilite un origen con el nombre de mySource :

dotnet nuget enable source mySource

Vea también
Secciones de origen del paquete en archivos NuGet.config
Comando sources (nuget.exe)
 dotnet nuget list source
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.200 y versiones posteriores

NOMBRE
dotnet nuget list source : enumera todos los orígenes de NuGet configurados.

Sinopsis
dotnet nuget list source [--format [Detailed|Short]] [--configfile <FILE>]

dotnet nuget list source -h|--help

Descripción
El comando dotnet nuget list source muestra todos los orígenes existentes de los archivos de configuración de
NuGet.

Opciones
--configfile <FILE>

Archivo de configuración de NuGet. Si se especifica, solo se usará la configuración de este archivo. Si no se

especifica, se utilizará la jerarquía de archivos de configuración del directorio actual. Para más información,
consulte Configuraciones comunes de NuGet.
--format [Detailed|Short]

Formato de la salida del comando de lista: Detailed (valor predeterminado) y Short .

Ejemplos
Enumeración de los orígenes configurados del directorio actual:

dotnet nuget list source

Vea también
Secciones de origen del paquete en archivos NuGet.config
Comando sources (nuget.exe)
 dotnet nuget remove source
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.200 y versiones posteriores

NOMBRE
dotnet nuget remove source : quita un origen de NuGet.

Sinopsis
dotnet nuget remove source <NAME> [--configfile <FILE>]

dotnet nuget remove source -h|--help

Descripción
El comando dotnet nuget remove source quita un origen existente de los archivos de configuración de NuGet.

Argumentos
NAME

Nombre del origen.

Opciones
--configfile

Archivo de configuración de NuGet. Si se especifica, solo se usará la configuración de este archivo. Si no se

especifica, se utilizará la jerarquía de archivos de configuración del directorio actual. Para más información,
consulte Configuraciones comunes de NuGet.

Ejemplos
Quite un origen con el nombre de mySource :

dotnet nuget remove source mySource

Vea también
Secciones de origen del paquete en archivos NuGet.config
Comando sources (nuget.exe)
 dotnet nuget update source
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1.200 y versiones posteriores

NOMBRE
dotnet nuget update source : actualiza un origen de NuGet.

Sinopsis
dotnet nuget update source <NAME> [--source <SOURCE>] [--username <USER>]
[--password <PASSWORD>] [--store-password-in-clear-text]
[--valid-authentication-types <TYPES>] [--configfile <FILE>]

dotnet nuget update source -h|--help

Descripción
El comando dotnet nuget update source actualiza un origen existente en los archivos de configuración de NuGet.

Argumentos
NAME

Nombre del origen.

Opciones
--configfile <FILE>

Archivo de configuración de NuGet. Si se especifica, solo se usará la configuración de este archivo. Si no se

especifica, se utilizará la jerarquía de archivos de configuración del directorio actual. Para más información,
consulte Configuraciones comunes de NuGet.
-p|--password <PASSWORD>

Contraseña que se debe usar al conectarse a un origen autenticado.

-s|--source <SOURCE>

Ruta de acceso al origen del paquete.

--store-password-in-clear-text

Deshabilita el cifrado de la contraseña para permitir el almacenamiento de las credenciales de origen del
paquete portátil.
-u|--username <USER>

Nombre de usuario que se usará al conectarse a un origen autenticado.

--valid-authentication-types <TYPES>
 Lista separada por comas de tipos de autenticación válidos para este origen. Establézcalo en basic si el
servidor anuncia NTLM o Negotiate y las credenciales deben enviarse mediante el mecanismo básico, por
ejemplo, cuando se usa una instancia de PAT con Azure DevOps Server local. Otros valores válidos son
negotiate , kerberos , ntlm y digest , pero es poco probable que estos valores sean útiles.

Ejemplos
Actualice un origen con el nombre de mySource :

dotnet nuget update source mySource --source c:\packages

Vea también
Secciones de origen del paquete en archivos NuGet.config
Comando sources (nuget.exe)
 dotnet nuget verify
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET 5.0.100-rc.2.x y versiones posteriores

Nombre
dotnet nuget verify : comprueba un paquete NuGet firmado.

Sinopsis
dotnet nuget verify [<package-path(s)>]
[--all]
[--certificate-fingerprint <FINGERPRINT>]
[-v|--verbosity <LEVEL>]

dotnet nuget verify -h|--help

Descripción
El comando dotnet nuget verify comprueba un paquete NuGet firmado.

Argumentos
package-path(s)

Especifica la ruta de acceso al paquete que se va a comprobar. Se pueden pasar varios argumentos de
posición para comprobar varios paquetes.

Opciones
--all

Especifica que en los paquetes se deben realizar todas las comprobaciones posibles. De forma
predeterminada, solo se comprueban signatures .

NOTE
En la actualidad, este comando solo admite la comprobación de signature .

--certificate-fingerprint <FINGERPRINT>

Compruebe que el certificado del firmante coincide con una de las huellas digitales SHA256 especificadas.
Esta opción se puede incluir varias veces para proporcionar varias huellas digitales.
-v|--verbosity <LEVEL>

Establece el nivel de detalle de MSBuild. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] . De manera predeterminada, es normal .

-h|--help
 Imprime una corta ayuda para el comando.

Ejemplos
Comprobación de foo.nupkg:

dotnet nuget verify foo.nupkg

Comprobación de varios paquetes NuGet: foo.nupkg y todos los archivos .nupkg en el directorio
especificado:

dotnet nuget verify foo.nupkg c:\mydir\*.nupkg

Comprobación de que la signatura de foo.nupkg coincide con la huella digital de certificado especificada:

dotnet nuget verify foo.nupkg --certificate-fingerprint

CE40881FF5F0AD3E58965DA20A9F571EF1651A56933748E1BF1C99E537C4E039

Comprobación de que la signatura de foo.nupkg coincide con una de las huellas digitales de certificado
especificadas:

dotnet nuget verify foo.nupkg --certificate-fingerprint

CE40881FF5F0AD3E58965DA20A9F571EF1651A56933748E1BF1C99E537C4E039 --certificate-fingerprint
EC10992GG5F0AD3E58965DA20A9F571EF1651A56933748E1BF1C99E537C4E027
 dotnet pack
18/12/2020 • 9 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet pack : empaqueta el código en un paquete de NuGet.

Sinopsis
dotnet pack [<PROJECT>|<SOLUTION>] [-c|--configuration <CONFIGURATION>]
[--force] [--include-source] [--include-symbols] [--interactive]
[--no-build] [--no-dependencies] [--no-restore] [--nologo]
[-o|--output <OUTPUT_DIRECTORY>] [--runtime <RUNTIME_IDENTIFIER>]
[-s|--serviceable] [-v|--verbosity <LEVEL>]
[--version-suffix <VERSION_SUFFIX>]

dotnet pack -h|--help

Descripción
El comando dotnet pack compila el proyecto y crea paquetes de NuGet. El resultado de este comando es un
paquete de NuGet (es decir, un archivo .nupkg).
Si quiere generar un paquete que contenga los símbolos de depuración, tiene dos opciones a su disposición:
--include-symbols : crea el paquete de símbolos.
--include-source : crea el paquete de símbolos con una carpeta src dentro que contiene los archivos de
origen.
Las dependencias de NuGet del proyecto empaquetado se agregan al archivo .nuspec, por lo que se pueden
resolver adecuadamente cuando se instala el paquete. Las referencias de proyecto a proyecto no se empaquetan
dentro del proyecto. Actualmente, debe disponer de un paquete por proyecto si tiene dependencias de proyecto
a proyecto.
De forma predeterminada, dotnet pack compila primero el proyecto. Si desea evitar este comportamiento, pase
la opción --no-build . Esta opción a menudo resulta útil en escenarios de compilación de integración continua
(CI) donde se conoce el código que se compiló anteriormente.

NOTE
En algunos casos, no se puede realizar la compilación implícita. Esto puede ocurrir cuando se establece
GeneratePackageOnBuild , para evitar una dependencia cíclica entre los destinos de compilación y de paquete. La
compilación también puede producir un error si hay un archivo bloqueado u otro problema.

Puede proporcionar propiedades de MSBuild en el comando dotnet pack para el proceso de empaquetado.
Para obtener más información, vea Propiedades de metadatos de NuGet y la Referencia de la línea de comandos
de MSBuild. La sección Ejemplos muestra cómo utilizar el modificador -p de MSBuild en un par de escenarios
diferentes.
Los proyectos web no están empaquetados de forma predeterminada. Para invalidar el comportamiento
predeterminado, agregue la siguiente propiedad a su archivo .csproj:

<PropertyGroup>
<IsPackable>true</IsPackable>
</PropertyGroup>

Restauración implícita
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan
que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test , dotnet publish
y dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .
El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los
sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore .
Este comando admite las opciones de dotnet restore cuando se pasan con el formato largo (por ejemplo,
--source ). No se admiten las opciones de formato corto, como -s .

Argumentos
PROJECT | SOLUTION

El archivo de proyecto o solución para empaquetar. Es una ruta de acceso a un archivo csproj, un archivo vbproj,
un archivo fsproj, un archivo de solución o un directorio. Si no se especifica, el comando busca un archivo del
proyecto o de la solución en el directorio actual.

Opciones
-c|--configuration <CONFIGURATION>

Define la configuración de compilación. El valor predeterminado para la mayoría de los proyectos es

Debug , pero puede invalidar los valores de configuración de compilación en el proyecto.

--force

Fuerza la resolución de todas las dependencias, incluso si la última restauración se realizó correctamente.
Especificar esta marca es lo mismo que eliminar el archivo project.assets.json.
-h|--help

Imprime una corta ayuda para el comando.

--include-source

Incluye los paquetes NuGet de símbolos de depuración, además de los paquetes NuGet normales en el
directorio de salida. Los archivos de origen se incluyen en la carpeta src dentro del paquete de
símbolos.
--include-symbols

Incluye los paquetes NuGet de símbolos de depuración, además de los paquetes NuGet normales en el
directorio de salida.
--interactive
 Permite que el comando se detenga y espere la entrada o acción del usuario (por ejemplo, completar la
autenticación). Disponible desde el SDK de .NET Core 3.0.
--no-build

No compila el proyecto antes de empaquetarlo. También establece la marca --no-restore de forma

implícita.
--no-dependencies

Omite las referencias de proyecto a proyecto y solo restaura el proyecto raíz.

--no-restore

No ejecuta una restauración implícita al ejecutar el comando.

--nologo

No se muestra la pancarta de inicio ni el mensaje de copyright. Disponible desde el SDK de .NET Core 3.0.
-o|--output <OUTPUT_DIRECTORY>

Coloca los paquetes compilados en el directorio especificado.

--runtime <RUNTIME_IDENTIFIER>

Especifica el tiempo de ejecución de destino para el que restaurar los paquetes. Para obtener una lista de
identificadores de tiempo de ejecución (RID), consulte el catálogo de RID.
-s|--serviceable

Establece la marca de servicio en el paquete. Para obtener más información, vea .NET Blog:
.NET Framework 4.5.1 Supports Microsoft Security Updates for .NET NuGet Libraries (Blog de .NET:
.NET Framework 4.5.1 admite actualizaciones de seguridad de Microsoft para bibliotecas NuGet de .NET).
--version-suffix <VERSION_SUFFIX>

Define el valor de la propiedad de $(VersionSuffix) en el proyecto.

-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] .

Ejemplos
Empaquetado del proyecto en el directorio actual:

dotnet pack

Empaquetar el proyecto app1 :

dotnet pack ~/projects/app1/project.csproj

Empaquetar el proyecto en el directorio actual y colocar los paquetes resultantes en la carpeta nupkgs :

dotnet pack --output nupkgs

Empaquetar el proyecto en el directorio actual en la carpeta nupkgs y omitir del paso de compilación:

dotnet pack --no-build --output nupkgs

Con el sufijo de la versión del proyecto configurado como

<VersionSuffix>$(VersionSuffix)</VersionSuffix> en el archivo .csproj, empaquetar el proyecto actual y
actualizar la versión del paquete resultante con el sufijo dado:

dotnet pack --version-suffix "ci-1234"

Establecer la versión del paquete en 2.1.0 con la propiedad de MSBuild PackageVersion :

dotnet pack -p:PackageVersion=2.1.0

Empaquete el proyecto para un determinado marco de destino:

dotnet pack -p:TargetFrameworks=net45

Empaquete el proyecto y use un entorno de ejecución específico (Windows 10) para la operación de
restauración:

dotnet pack --runtime win10-x64

Empaquete el proyecto mediante un archivo .nuspec:

dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -

p:NuspecBasePath=~/projects/app1/nuget

Para obtener información sobre cómo usar NuspecFile , NuspecBasePath y NuspecProperties , vea los
siguientes recursos:
Empaquetado mediante un archivo .nuspec
Puntos de extensión avanzados para crear un paquete personalizado
Propiedades globales
 dotnet publish
18/12/2020 • 18 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet publish : publica la aplicación y sus dependencias en una carpeta para la implementación en un
sistema de hospedaje.

Sinopsis
dotnet publish [<PROJECT>|<SOLUTION>] [-c|--configuration <CONFIGURATION>]
[-f|--framework <FRAMEWORK>] [--force] [--interactive]
[--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
[--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
[-p:PublishReadyToRun=true] [-p:PublishSingleFile=true] [-p:PublishTrimmed=true]
[-r|--runtime <RUNTIME_IDENTIFIER>] [--self-contained [true|false]]
[--no-self-contained] [-v|--verbosity <LEVEL>]
[--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Descripción
dotnet publish : compila la aplicación, lee sus dependencias especificadas en el archivo de proyecto y
publica el conjunto resultante de archivos en un directorio. La salida incluye los recursos siguientes:
Código de lenguaje intermedio (IL) en un ensamblado con una extensión dll.
Un archivo .deps.json que incluye todas las dependencias del proyecto.
Un archivo .runtime.config.json en el que se especifica el tiempo de ejecución compartido que espera la
aplicación, así como otras opciones de configuración para el tiempo de ejecución (por ejemplo, el tipo de
recolección de elementos no utilizados).
Las dependencias de la aplicación, que se copian de la caché de NuGet a la carpeta de salida.
La salida del comando dotnet publish está lista para la implementación en un sistema de hospedaje (por
ejemplo, un servidor, un equipo PC o Mac, un portátil) para la ejecución. Es la única manera admitida
oficialmente para preparar la aplicación para la implementación. En función del tipo de implementación que
especifique el proyecto, el sistema de hospedaje puede o no tener instalado el entorno de ejecución
compartido de .NET. Para obtener más información, vea Publicación de aplicaciones de .NET con la CLI de
.NET.
Restauración implícita
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que
necesitan que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test ,
dotnet publish y dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los
sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de
dotnet restore .

MSBuild
Con el comando dotnet publish se llama a MSBuild, lo que invoca el destino Publish . Todos los
parámetros pasados a dotnet publish se pasan a MSBuild. Los parámetros -c y -o se asignan
respectivamente a las propiedades Configuration y PublishDir de MSBuild.
El comando dotnet publish acepta opciones de MSBuild, como -p para establecer propiedades y -l para
definir un registrador. Por ejemplo, se puede establecer una propiedad de MSBuild mediante el uso del
formato: -p:<NAME>=<VALUE> .
También se pueden establecer las propiedades relacionadas con la publicación si se hace referencia a un
archivo .pubxml (disponible a partir del SDK de .NET Core 3.1). Por ejemplo:

dotnet publish -p:PublishProfile=FolderProfile

En el ejemplo anterior se usa el archivo FolderProfile.pubxml que se encuentra en la carpeta

<project_folder>/Properties/PublishProfiles. Si especifica una ruta de acceso y una extensión de archivo al
establecer la propiedad PublishProfile , estas se omiten. De forma predeterminada, MSBuild busca en la
carpeta Properties/PublishProfiles y da por hecho la extensión de archivo pubxml. Para especificar la ruta de
acceso y el nombre de archivo, incluida la extensión, establezca la propiedad PublishProfileFullPath en
lugar de la propiedad PublishProfile .
Para obtener más información, vea los siguientes recursos:
Referencia de la línea de comandos de MSBuild
Perfiles de publicación (.pubxml) de Visual Studio para la implementación de aplicaciones ASP.NET Core
dotnet msbuild

Argumentos
PROJECT|SOLUTION

El archivo de proyecto o solución que se va a publicar.

PROJECT es la ruta de acceso y el nombre de archivo de un archivo de proyecto de C#, F# o
Visual Basic, o bien la ruta de acceso a un directorio que contiene un archivo de proyecto de
C#, F# o Visual Basic. Si no se especifica el directorio, se toma como predeterminado el actual.
SOLUTION es la ruta de acceso y el nombre de archivo de un archivo de solución (extensión
.sln), o bien la ruta de acceso a un directorio que contiene un archivo de solución. Si no se
especifica el directorio, se toma como predeterminado el actual. Disponible desde el SDK de
.NET Core 3.0.

Opciones
-c|--configuration <CONFIGURATION>

Define la configuración de compilación. El valor predeterminado para la mayoría de los proyectos es

Debug , pero puede invalidar los valores de configuración de compilación en el proyecto.

-f|--framework <FRAMEWORK>

Publica la aplicación para el marco de trabajo de destino especificado. Debe especificar el marco de
trabajo de destino en el archivo de proyecto.
--force

Fuerza la resolución de todas las dependencias, incluso si la última restauración se realizó

correctamente. Especificar esta marca es lo mismo que eliminar el archivo project.assets.json.
-h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se detenga y espere una entrada o una acción del usuario. Por ejemplo, para
completar la autenticación. Disponible desde el SDK de .NET Core 3.0.
--manifest <PATH_TO_MANIFEST_FILE>

Especifica uno o varios manifiestos de destino que se usarán para recortar el conjunto de paquetes
publicados con la aplicación. El archivo de manifiesto es parte de la salida del comando
dotnet store . Para especificar varios manifiestos, agregue la opción --manifest para cada
manifiesto.
--no-build

No compila el proyecto antes de publicarlo. También establece la marca --no-restore de forma

implícita.
--no-dependencies

Omite las referencias de proyecto a proyecto y solo restaura el proyecto raíz.

--nologo

No se muestra la pancarta de inicio ni el mensaje de copyright. Disponible desde el SDK de

.NET Core 3.0.
--no-restore

No ejecuta una restauración implícita al ejecutar el comando.

-o|--output <OUTPUT_DIRECTORY>

Especifica la ruta de acceso del directorio de salida.

Si no se especifica, el valor predeterminado es [carpeta_de_archivo_de-
_proyecto]./bin/[configuración]/[marco]/publish/ para un archivo ejecutable dependiente del marco y
archivos binarios multiplataforma. El valor predeterminado es
[project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ para un archivo ejecutable
autocontenido.
En un proyecto web, si la carpeta de salida se encuentra en la carpeta del proyecto, los comandos
dotnet publish posteriores dan como resultado carpetas de salida anidadas. Por ejemplo, si la
carpeta del proyecto es myproject y la carpeta de salida de la publicación es myproject/publish, y
ejecuta dotnet publish dos veces, la segunda ejecución coloca los archivos de contenido, como
.config y .json, en myproject/publish/publish. Para evitar el anidamiento de carpetas de publicación,
especifique una que no esté directamente en la carpeta del proyecto, o bien excluya la carpeta de
publicación del proyecto. Para excluir una carpeta de publicación denominada publishoutput,
agregue el elemento siguiente a un elemento PropertyGroup en el archivo .csproj:

<DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
 SDK de .NET Core 3.x y versiones posteriores
Si se especifica una ruta de acceso relativa al publicar un proyecto, el directorio de salida
generado es relativo al directorio de trabajo actual, no a la ubicación del archivo del proyecto.
Si se especifica una ruta de acceso relativa al publicar una solución, todas las salidas de todos
los proyectos van en la carpeta especificada relativa al directorio de trabajo actual. A fin de que
la salida de la publicación vaya a carpetas independientes para cada proyecto, especifique una
ruta de acceso relativa mediante el uso de la propiedad PublishDir de MSBuild en lugar de la
opción --output . Por ejemplo, dotnet publish -p:PublishDir=.\publish envía la salida de
publicación de cada proyecto a una carpeta publish en la carpeta que contiene el archivo del
proyecto.
SDK de .NET Core 2.x
Si se especifica una ruta de acceso relativa al publicar un proyecto, el directorio de salida
generado es relativo a la ubicación del archivo del proyecto, no al directorio de trabajo actual.
Si se especifica una ruta de acceso relativa al publicar una solución, la salida de cada proyecto
va a una carpeta independiente relativa a la ubicación del archivo del proyecto. Si se especifica
una ruta de acceso absoluta al publicar una solución, la salida de las publicaciones de todos
los proyectos van a la carpeta especificada.
-p:PublishReadyToRun=true

Compila los ensamblados de aplicación con el formato ReadyToRun (R2R). R2R es una forma de
compilación Ahead Of Time (AOT). Para obtener más información, vea Imágenes ReadyToRun.
Disponible desde el SDK de .NET Core 3.0.
Se recomienda especificar esta opción en un perfil de publicación en lugar de hacerlo en la línea de
comandos. Para obtener más información, vea MSBuild.
-p:PublishSingleFile=true

Empaqueta la aplicación en un ejecutable de archivo único específico de la plataforma. El archivo

ejecutable es autoextraíble y contiene todas las dependencias (incluidas las nativas) necesarias para
ejecutar la aplicación. Cuando la aplicación se ejecuta por primera vez, se extrae en un directorio que
se basa en el nombre de la aplicación y el identificador de compilación. El inicio es más rápido
cuando se vuelve a ejecutar la aplicación. No es necesario extraer la aplicación por segunda vez a
menos que se haya usado una versión nueva. Disponible desde el SDK de .NET Core 3.0.
Para obtener más información sobre la publicación de archivos únicos, vea el documento de diseño
del programa de instalación de conjunto de archivos únicos.
Se recomienda especificar esta opción en un perfil de publicación en lugar de hacerlo en la línea de
comandos. Para obtener más información, vea MSBuild.
-p:PublishTrimmed=true

Recorta las bibliotecas no utilizadas para reducir el tamaño de implementación de una aplicación
cuando se publica un ejecutable independiente. Para obtener más información, vea Recorte de
implementaciones autocontenidas y ejecutables. Disponible a partir del SDK de .NET Core 3.0 como
una característica en versión preliminar.
Se recomienda especificar esta opción en un perfil de publicación en lugar de hacerlo en la línea de
comandos. Para obtener más información, vea MSBuild.
--self-contained [true|false]
 Publica el entorno de ejecución de .NET con la aplicación para que no sea necesario instalarlo en el
equipo de destino. El valor predeterminado es true si se especifica un identificador en tiempo de
ejecución y el proyecto es de tipo ejecutable (no un proyecto de biblioteca). Para obtener más
información, vea Publicación de aplicaciones de .NET y Publicación de aplicaciones de .NET con la CLI
de .NET.
Si se usa esta opción sin especificar true o false , el valor predeterminado es true . En ese caso,
no coloque el argumento de la solución o el proyecto inmediatamente después de --self-contained ,
porque se espera que true o false estén en esa posición.
--no-self-contained

Equivalente a --self-contained false . Disponible desde el SDK de .NET Core 3.0.

-r|--runtime <RUNTIME_IDENTIFIER>

Publica la aplicación para un determinado entorno de tiempo de ejecución. Para obtener una lista de
identificadores de tiempo de ejecución (RID), consulte el catálogo de RID. Para obtener más
información, vea Publicación de aplicaciones de .NET y Publicación de aplicaciones de .NET con la CLI
de .NET.
-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal]
, d[etailed] y diag[nostic] . El valor predeterminado es minimal .
--version-suffix <VERSION_SUFFIX>

Define el sufijo de versión para reemplazar el asterisco ( * ) en el campo de versión del archivo de
proyecto.

Ejemplos
Cree un archivo binario multiplataforma dependiente del marco para el proyecto en el directorio
actual:

dotnet publish

A partir del SDK de .NET Core 3.0, en este ejemplo también se crea un ejecutable dependiente del
marco para la plataforma actual.
Cree un ejecutable independiente para el proyecto en el directorio actual, para un tiempo de
ejecución específico:

dotnet publish --runtime osx.10.11-x64

El RID debe estar en el archivo del proyecto.

Cree un ejecutable dependiente del marco para el proyecto en el directorio actual, para una
plataforma específica:

dotnet publish --runtime osx.10.11-x64 --self-contained false

El RID debe estar en el archivo del proyecto. Este ejemplo se aplica al SDK de .NET Core 3.0 y
versiones posteriores.
 Publique el proyecto en el directorio actual, para un tiempo de ejecución específico y una plataforma
de destino:

dotnet publish --framework netcoreapp3.1 --runtime osx.10.11-x64

Publique el archivo del proyecto especificado:

dotnet publish ~/projects/app1/app1.csproj

Publique la aplicación actual pero sin restaurar las referencias de proyecto a proyecto (P2P), solo el
proyecto raíz, durante la operación de restauración:

dotnet publish --no-dependencies

Vea también
Información general sobre la publicación de aplicaciones de .NET
Publicación de aplicaciones de .NET con la CLI de .NET
Marcos de trabajo de destino
Catálogo de identificadores de tiempo de ejecución (RID)
Trabajo con la certificación de macOS Catalina
Estructura de directorios de una aplicación publicada
Referencia de la línea de comandos de MSBuild
Perfiles de publicación (.pubxml) de Visual Studio para la implementación de aplicaciones ASP.NET Core
dotnet msbuild
ILLInk.Tasks
 dotnet restore
18/12/2020 • 8 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet restore : restaura las dependencias y las herramientas de un proyecto.

Sinopsis
dotnet restore [<ROOT>] [--configfile <FILE>] [--disable-parallel]
[-f|--force] [--force-evaluate] [--ignore-failed-sources]
[--interactive] [--lock-file-path <LOCK_FILE_PATH>] [--locked-mode]
[--no-cache] [--no-dependencies] [--packages <PACKAGES_DIRECTORY>]
[-r|--runtime <RUNTIME_IDENTIFIER>] [-s|--source <SOURCE>]
[--use-lock-file] [-v|--verbosity <LEVEL>]

dotnet restore -h|--help

Descripción
El comando dotnet restore usa NuGet para restaurar las dependencias, así como las herramientas
específicas del proyecto que se especifican en el archivo project.json. En la mayoría de los casos, no es
necesario usar explícitamente el comando dotnet restore , ya que una restauración de NuGet se
ejecuta implícitamente si es necesario al ejecutar los siguientes comandos:
dotnet new
dotnet build
dotnet build-server
dotnet run
dotnet test
dotnet publish
dotnet pack

A veces, puede que no sea conveniente ejecutar la restauración de NuGet implícita con estos
comandos. Por ejemplo, algunos sistemas automatizados, como los sistemas de compilación, deben
llamar a dotnet restore explícitamente para controlar cuándo se produce la restauración a fin de
controlar el uso de la red. Para evitar la restauración de NuGet implícita, puede usar la marca
--no-restore con cualquiera de estos comandos para deshabilitar la restauración implícita.

Especificación de fuentes
Para restaurar las dependencias, NuGet necesita las fuentes donde se encuentran los paquetes. Las
fuente se proporcionan normalmente mediante el archivo de configuración nuget.config. Cuando se
instala el SDK de .NET, se proporciona un archivo de configuración predeterminado. Para especificar
fuentes adicionales, realice una de las acciones siguientes:
Cree su propio archivo nuget.config en el directorio del proyecto. Para obtener más información,
vea Configuraciones comunes de NuGet y Diferencias de nuget.config más adelante en este
artículo.
 Use comandos de dotnet nuget como dotnet nuget add source .
Puede invalidar las fuentes nuget.config con la opción -s .
Para obtener información sobre cómo usar las fuentes autenticadas, vea Consumir paquetes desde
fuentes autenticadas.
Carpeta de paquetes globales
Para las dependencias, puede especificar dónde se colocan los paquetes restaurados durante la
operación de restauración mediante el argumento --packages . Si no se especifica, se usa la caché de
paquetes NuGet predeterminada, que se encuentra en el directorio .nuget/packages del directorio de
inicio del usuario en todos los sistemas operativos. Por ejemplo, /home/usuario1 en Linux o
C:\Usuarios\usuario1 en Windows.
Herramientas específicas del proyecto
Para herramientas específicas del proyecto, dotnet restore restaura primero el paquete en el que se
empaqueta la herramienta y, a continuación, continúa con la restauración de las dependencias de la
herramienta especificadas en su project.json.
Diferencias de nuget.config
El comportamiento del comando dotnet restore depende de las opciones de configuración del
archivo nuget.config, si existe. Por ejemplo, establecer globalPackagesFolder en nuget.config coloca los
paquetes NuGet restaurados en la carpeta especificada. Esta es una alternativa para especificar la
opción --packages en el comando dotnet restore . Para más información, consulte la referencia de
nuget.config.
Hay tres configuraciones específicas que dotnet restore omite:
bindingRedirects
Los redireccionamientos de enlace no funcionan con elementos de <PackageReference> y .NET
solo admite elementos de <PackageReference> para los paquetes NuGet.
solution
Esta configuración es específica para Visual Studio y no se aplica a .NET. .NET no usa un archivo
packages.config y, en su lugar, usa elementos de <PackageReference> para los paquetes NuGet.

trustedSigners
Esta configuración no es aplicable porque NuGet ya no admite la comprobación
multiplataforma de los paquetes de confianza.

Argumentos
ROOT

Ruta de acceso opcional del archivo de proyecto para restaurar.

Opciones
--configfile <FILE>

El archivo de configuración de NuGet (nuget.config) que se usa para la operación de

restauración.
--disable-parallel
Deshabilita la restauración de varios proyectos en paralelo.
--force

Fuerza la resolución de todas las dependencias, incluso si la última restauración se realizó

correctamente. Especificar esta marca es lo mismo que eliminar el archivo project.assets.json.
--force-evaluate

Fuerza la restauración para volver a evaluar todas las dependencias aunque ya exista un archivo
de bloqueo.
-h|--help

Imprime una corta ayuda para el comando.

--ignore-failed-sources

Solo se advierte sobre los orígenes con error si hay paquetes que satisfagan el requisito de
versión.
--interactive

Permite que el comando se detenga y espere la entrada o acción del usuario (por ejemplo,
completar la autenticación). Desde .NET Core 2.1.400.
--lock-file-path <LOCK_FILE_PATH>

Ubicación de salida donde se escribe el archivo de bloqueo del proyecto. De forma

predeterminada es PROJECT_ROOT\packages.lock.json.
--locked-mode

No permite actualizar el archivo de bloqueo del proyecto.

--no-cache

Especifica que no se almacenen en caché las solicitudes HTTP.

--no-dependencies

Al restaurar un proyecto con referencias de proyecto a proyecto (P2P), se restaura el proyecto

raíz y no las referencias.
--packages <PACKAGES_DIRECTORY>

Especifica el directorio de los paquetes restaurados.

-r|--runtime <RUNTIME_IDENTIFIER>

Especifica un tiempo de ejecución para la restauración del paquete. Se usa para restaurar los
paquetes con tiempos de ejecución que no se enumeran explícitamente en la etiqueta
<RuntimeIdentifiers> del archivo .csproj. Para obtener una lista de identificadores de tiempo de
ejecución (RID), consulte el catálogo de RID. Para proporcionar varios RID; especifique esta
opción varias veces.
-s|--source <SOURCE>

Especifica el URI del origen del paquete NuGet que se usará durante la operación de
restauración. Este valor invalida todos los orígenes especificados en los archivos nuget.config.
Al especificar esta opción varias veces, se pueden proporcionar varios orígenes.
 --use-lock-file

Habilita la generación del archivo de bloqueo del proyecto y su uso con la restauración.
-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] ,
n[ormal] , d[etailed] y diag[nostic] . El valor predeterminado es minimal .

Ejemplos
Restauración de dependencias y herramientas para el proyecto en el directorio actual:

dotnet restore

Restauración de dependencias y herramientas para el proyecto app1 encontrado en la ruta de

acceso dada:

dotnet restore ./projects/app1/app1.csproj

Restauración de dependencias y herramientas para el proyecto en el directorio actual con la

ruta de acceso de archivo proporcionada como origen:

dotnet restore -s c:\packages\mypackages

Restauración de dependencias y herramientas para el proyecto en el directorio actual mediante

las dos rutas de acceso de archivo proporcionadas como orígenes:

dotnet restore -s c:\packages\mypackages -s c:\packages\myotherpackages

Restauración de dependencias y herramientas para el proyecto en el directorio actual que

muestra una salida detallada:

dotnet restore --verbosity detailed

 dotnet run
18/12/2020 • 8 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet run : ejecuta el código fuente sin comandos explícitos de compilación o inicio.

Sinopsis
dotnet run [-c|--configuration <CONFIGURATION>] [-f|--framework <FRAMEWORK>]
[--force] [--interactive] [--launch-profile <NAME>] [--no-build]
[--no-dependencies] [--no-launch-profile] [--no-restore]
[-p|--project <PATH>] [-r|--runtime <RUNTIME_IDENTIFIER>]
[-v|--verbosity <LEVEL>] [[--] [application arguments]]

dotnet run -h|--help

Descripción
El comando dotnet run proporciona una opción conveniente para ejecutar la aplicación desde el código fuente
con un comando. Es útil para un desarrollo iterativo rápido desde la línea de comandos. El comando depende del
comando dotnet build para compilar el código. Los requisitos para la compilación, como que el cliente se deba
restaurar primero, también se aplican a dotnet run .
Los archivos de salida se escriben en la ubicación predeterminada, que es bin/<configuration>/<target> . Por
ejemplo, si tiene una aplicación netcoreapp2.1 y ejecuta dotnet run , la salida se colocará en
bin/Debug/netcoreapp2.1 . Los archivos se sobrescriben según sea necesario. Los archivos temporales se colocan
en el directorio obj .
Si el proyecto especifica varios marcos, al ejecutar dotnet run se produce un error a menos que se use la opción
-f|--framework <FRAMEWORK> para especificar el marco.

El comando dotnet run debe usarse en el contexto de proyectos, no de ensamblados compilados. Si, por el
contrario, está intentando ejecutar una DLL de aplicación dependiente del marco de trabajo, debe usar dotnet sin
un comando. Por ejemplo, para ejecutar myapp.dll , use:

dotnet myapp.dll

Para obtener más información sobre el controlador dotnet , vea el tema Herramientas de la interfaz de la línea
de comandos (CLI) de .NET.
Para ejecutar la aplicación, el comando dotnet run resuelve las dependencias de la aplicación que se encuentran
fuera del entorno de tiempo de ejecución compartido desde la caché de NuGet. Dado que se usan dependencias
almacenadas en caché, no se recomienda utilizar dotnet run para ejecutar aplicaciones en producción. En su
lugar, cree una implementación mediante el comando dotnet publish e implemente la salida publicada.
Restauración implícita
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan
que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test , dotnet publish
y dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .
El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los
sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore .
Este comando admite las opciones de dotnet restore cuando se pasan con el formato largo (por ejemplo,
--source ). No se admiten las opciones de formato corto, como -s .

Opciones
--

Delimita los argumentos a dotnet run a partir de argumentos de la aplicación que se va a ejecutar. Todos
los argumentos después de este delimitador se pasan a la aplicación que se ejecuta.
-c|--configuration <CONFIGURATION>

Define la configuración de compilación. El valor predeterminado para la mayoría de los proyectos es

Debug , pero puede invalidar los valores de configuración de compilación en el proyecto.

-f|--framework <FRAMEWORK>

Compila y ejecuta la aplicación con el marco especificado. El marco debe especificarse en el archivo de
proyecto.
--force

Fuerza la resolución de todas las dependencias, incluso si la última restauración se realizó correctamente.
Especificar esta marca es lo mismo que eliminar el archivo project.assets.json.
-h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se detenga y espere la entrada o acción del usuario (por ejemplo, completar la
autenticación). Disponible desde el SDK de .NET Core 3.0.
--launch-profile <NAME>

El nombre del perfil de inicio (si lo hay) que se usará al iniciar la aplicación. Los perfiles de inicio se
definen en el archivo launchSettings.json y se suelen denominar Development , Staging y Production .
Para obtener más información, consulte Working with multiple environments (Trabajo con varios
entornos).
--no-build

No compila el proyecto antes de ejecutarlo. También establece la marca --no-restore de forma implícita.
--no-dependencies

Al restaurar un proyecto con referencias de proyecto a proyecto (P2P), se restaura el proyecto raíz y no las
referencias.
--no-launch-profile
 No intenta usar launchSettings.json para configurar la aplicación.
--no-restore

No ejecuta una restauración implícita al ejecutar el comando.

-p|--project <PATH>

Especifica la ruta de acceso del archivo del proyecto que se va a ejecutar (nombre de la carpeta o ruta de
acceso completa). Si no se especifica, se toma como predeterminado el directorio actual.
-r|--runtime <RUNTIME_IDENTIFIER>

Especifica el tiempo de ejecución de destino para el que restaurar los paquetes. Para obtener una lista de
identificadores de tiempo de ejecución (RID), consulte el catálogo de RID. Opción corta -r disponible a
partir del SDK de .NET Core 3.0.
-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] . El valor predeterminado es m . Disponible a partir del SDK de .NET Core 2.1.

Ejemplos
Ejecución del proyecto en el directorio actual:

dotnet run

Ejecución del proyecto especificado:

dotnet run --project ./projects/proj1/proj1.csproj

Ejecute el proyecto en el directorio actual (el argumento --help en este ejemplo se pasa a la aplicación,
dado que se usa la opción -- en blanco):

dotnet run --configuration Release -- --help

Restaure las dependencias y herramientas del proyecto en el directorio actual para mostrar solo la salida
mínima y, después, ejecute el proyecto:

dotnet run --verbosity m

 dotnet sln
18/12/2020 • 6 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet sln : enumera o modifica los proyectos en un archivo de solución de .NET.

Sinopsis
dotnet sln [<SOLUTION_FILE>] [command]

dotnet sln [command] -h|--help

Descripción
El comando dotnet sln proporciona una opción conveniente para enumerar y modificar los proyectos en un
archivo de solución.
Para usar el comando dotnet sln , debe existir el archivo de solución. Si necesita crear uno, use el comando
dotnet new, como en el ejemplo siguiente:

dotnet new sln

Argumentos
SOLUTION_FILE

El archivo de solución que se va a usar. Si se omite este argumento, el comando busca uno en el directorio
actual. Si encuentra varios archivos de solución o no encuentra ninguno, se produce un error en el
comando.

Opciones
-h|--help

Imprime una descripción de cómo usar el comando.

Comandos
list

Enumera todos los proyectos en un archivo de solución.

Sinopsis

dotnet sln list [-h|--help]

Argumentos
 SOLUTION_FILE

El archivo de solución que se va a usar. Si se omite este argumento, el comando busca uno en el directorio
actual. Si encuentra varios archivos de solución o no encuentra ninguno, se produce un error en el
comando.
Opciones
-h|--help

Imprime una descripción de cómo usar el comando.

add

Agrega uno o varios proyectos al archivo de solución.

Sinopsis

dotnet sln [<SOLUTION_FILE>] add [--in-root] [-s|--solution-folder <PATH>] <PROJECT_PATH>

[<PROJECT_PATH>...]
dotnet sln add [-h|--help]

Argumentos
SOLUTION_FILE

El archivo de solución que se va a usar. Si no se especifica, el comando busca uno en el directorio actual y
produce un error si hay varios archivos de solución.
PROJECT_PATH

La ruta de acceso al proyecto o los proyectos que se van a agregar a la solución. Las expansiones del
patrón comodines de shell de Unix y Linux se procesan correctamente mediante el comando dotnet sln .
Opciones
-h|--help

Imprime una descripción de cómo usar el comando.

--in-root

Coloca el proyecto en la raíz de la solución, en lugar de crear una carpeta de la solución. Disponible desde
el SDK de .NET Core 3.0.
-s|--solution-folder <PATH>

La ruta de acceso de la carpeta de la solución de destino a la que se van a agregar los proyectos.
Disponible desde el SDK de .NET Core 3.0.
remove

Quita un proyecto o varios proyectos del archivo de solución.

Sinopsis

dotnet sln [<SOLUTION_FILE>] remove <PROJECT_PATH> [<PROJECT_PATH>...]

dotnet sln [<SOLUTION_FILE>] remove [-h|--help]

Argumentos
SOLUTION_FILE

El archivo de solución que se va a usar. Si se deja sin especificar, el comando busca uno en el directorio
actual y produce un error si hay varios archivos de solución.
 PROJECT_PATH

La ruta de acceso al proyecto o los proyectos que se van a agregar a la solución. Las expansiones del
patrón comodines de shell de Unix y Linux se procesan correctamente mediante el comando dotnet sln .
Opciones
-h|--help

Imprime una descripción de cómo usar el comando.

Ejemplos
Enumere los proyectos en una solución:

dotnet sln todo.sln list

Agregue un proyecto de C# a una solución:

dotnet sln add todo-app/todo-app.csproj

Quite un proyecto de C# de una solución:

dotnet sln remove todo-app/todo-app.csproj

Agregue varios proyectos de C# a la raíz de una solución:

dotnet sln todo.sln add todo-app/todo-app.csproj back-end/back-end.csproj --in-root

Agregue varios proyectos de C# a una solución:

dotnet sln todo.sln add todo-app/todo-app.csproj back-end/back-end.csproj

Quite varios proyectos de C# de una solución:

dotnet sln todo.sln remove todo-app/todo-app.csproj back-end/back-end.csproj

Agregue varios proyectos de C# a una solución mediante un patrón de comodines (solo para Unix y
Linux):

dotnet sln todo.sln add **/*.csproj

Agregue varios proyectos de C# a una solución mediante un patrón de comodines (solo

Windows PowerShell):

dotnet sln todo.sln add (ls -r **/*.csproj)

Quite varios proyectos de C# de una solución mediante un patrón de comodines (solo para Unix y Linux):

dotnet sln todo.sln remove **/*.csproj

Quite varios proyectos de C# a una solución mediante un patrón de comodines (solo
Windows PowerShell):

dotnet sln todo.sln remove (ls -r **/*.csproj)

Cree una solución, una aplicación de consola y dos bibliotecas de clases. Agregue los proyectos a la
solución y use la opción --solution-folder de dotnet sln para organizar las bibliotecas de clases en una
carpeta de soluciones.

dotnet new sln -n mysolution

dotnet new console -o myapp
dotnet new classlib -o mylib1
dotnet new classlib -o mylib2
dotnet sln mysolution.sln add myapp\myapp.csproj
dotnet sln mysolution.sln add mylib1\mylib1.csproj --solution-folder mylibs
dotnet sln mysolution.sln add mylib2\mylib2.csproj --solution-folder mylibs

En la captura de pantalla siguiente se muestra el resultado en el Explorador de soluciones de

Visual Studio 2019:
 dotnet store
18/12/2020 • 3 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

Name
dotnet store : almacena los ensamblados especificados en el almacenamiento de paquetes en tiempo de
ejecución.

Sinopsis
dotnet store -m|--manifest <PATH_TO_MANIFEST_FILE>
-f|--framework <FRAMEWORK_VERSION> -r|--runtime <RUNTIME_IDENTIFIER>
[--framework-version <FRAMEWORK_VERSION>] [--output <OUTPUT_DIRECTORY>]
[--skip-optimization] [--skip-symbols] [-v|--verbosity <LEVEL>]
[--working-dir <WORKING_DIRECTORY>]

dotnet store -h|--help

Description
dotnet store almacena los ensamblados especificados en el almacenamiento de paquetes en tiempo de
ejecución. De forma predeterminada, los ensamblados están optimizados para el tiempo de ejecución y el marco
de trabajo de destino. Para obtener más información, consulte el tema Almacenamiento de paquetes en tiempo de
ejecución.

Opciones necesarias
-f|--framework <FRAMEWORK>

Especifica la plataforma de destino. La plataforma de destino tiene que especificarse en el archivo del
proyecto.
-m|--manifest <PATH_TO_MANIFEST_FILE>

El archivo de manifiesto de almacenamiento de paquetes es un archivo XML que contiene la lista de

paquetes que se va a almacenar. El formato del archivo de manifiesto es compatible con el formato de
proyecto de estilo de SDK. Por tanto, se puede usar un archivo de proyecto que haga referencia a los
paquetes deseados con la opción -m|--manifest para almacenar los ensamblados en el almacenamiento
de paquetes en tiempo de ejecución. Para especificar varios archivos de manifiesto, repita la opción y la
ruta de acceso para cada archivo. Por ejemplo: --manifest packages1.csproj --manifest packages2.csproj .
-r|--runtime <RUNTIME_IDENTIFIER>

El identificador en tiempo de ejecución de destino.

Opciones no necesarias
--framework-version <FRAMEWORK_VERSION>

Especifica la versión del SDK de .NET. Esta opción le permite seleccionar una versión de un marco concreto
 más allá del marco de trabajo especificado en la opción -f|--framework .
-h|--help

Muestra información de ayuda.

-o|--output <OUTPUT_DIRECTORY>

Especifica la ruta de acceso al almacenamiento de paquetes en tiempo de ejecución. Si no se especifica, el

valor predeterminado es el subdirectorio store del directorio de instalación de .NET del perfil de usuario.
--skip-optimization

Omite la fase de optimización.

--skip-symbols

Omite la generación de símbolos. Actualmente, solo se pueden generar símbolos en Windows y Linux.
-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] .

-w|--working-dir <WORKING_DIRECTORY>

El directorio de trabajo que usa el comando. Si no se especifica, usa el subdirectorio obj del directorio
actual.

Ejemplos
Almacenamiento de los paquetes especificados en el archivo de proyecto packages.csproj para .NET Core
2.0.0:

dotnet store --manifest packages.csproj --framework-version 2.0.0

Almacenamiento de los paquetes especificados en packages.csproj sin optimización:

dotnet store --manifest packages.csproj --skip-optimization

Vea también
Runtime package store (Almacenamiento de paquetes en tiempo de ejecución)
 dotnet test
18/12/2020 • 19 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet test : controlador de prueba de .NET usado para ejecutar pruebas unitarias.

Sinopsis
dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL>]
[-a|--test-adapter-path <ADAPTER_PATH>] [--blame] [--blame-crash]
[--blame-crash-dump-type <DUMP_TYPE>] [--blame-crash-collect-always]
[--blame-hang] [--blame-hang-dump-type <DUMP_TYPE>]
[--blame-hang-timeout <TIMESPAN>]
[-c|--configuration <CONFIGURATION>]
[--collect <DATA_COLLECTOR_NAME>]
[-d|--diag <LOG_FILE>] [-f|--framework <FRAMEWORK>]
[--filter <EXPRESSION>] [--interactive]
[-l|--logger <LOGGER>] [--no-build]
[--nologo] [--no-restore] [-o|--output <OUTPUT_DIRECTORY>]
[-r|--results-directory <RESULTS_DIR>] [--runtime <RUNTIME_IDENTIFIER>]
[-s|--settings <SETTINGS_FILE>] [-t|--list-tests]
[-v|--verbosity <LEVEL>] [[--] <RunSettings arguments>]

dotnet test -h|--help

Descripción
El comando dotnet test se usa para ejecutar pruebas unitarias en una solución determinada. El comando
dotnet test compila la solución y ejecuta una aplicación host de prueba para cada proyecto de prueba de la
solución. El host de prueba ejecuta las pruebas en el proyecto especificado mediante un marco de pruebas (por
ejemplo, MSTest, NUnit o xUnit) e informa del éxito o el error de cada prueba. Si todas las pruebas son
correctas, el ejecutor de pruebas devuelve 0 como un código de salida; en caso contrario, si se produce algún
error en una prueba, devuelve 1.
En el caso de los proyectos con varios destinos, las pruebas se ejecutan para cada plataforma de destino. El
host de pruebas y el marco de pruebas unitarias se empaquetan como paquetes NuGet y se restauran como
dependencias ordinarias para el proyecto.
Los proyectos de prueba especifican el ejecutor de pruebas usando un elemento <PackageReference> ordinario,
como se puede ver en este archivo de proyecto de ejemplo:
 <Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.8.3" />
<PackageReference Include="xunit" Version="2.4.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.3" />
</ItemGroup>

</Project>

Donde Microsoft.NET.Test.Sdk es el host de prueba y xunit es el marco de pruebas. Y

xunit.runner.visualstudio es un adaptador de prueba, que permite que el marco xUnit funcione con el host de
prueba.
Restauración implícita
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan
que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test ,
dotnet publish y dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los
sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore .

Argumentos
PROJECT | SOLUTION | DIRECTORY | DLL

Ruta de acceso al proyecto de prueba.

Ruta de acceso a la solución.
Ruta de acceso a un directorio que contiene un proyecto o una solución.
Ruta de acceso a un archivo .dll del proyecto de prueba.
Si no se especifica, se busca un proyecto o una solución en el directorio actual.

Opciones
-a|--test-adapter-path <ADAPTER_PATH>

Ruta de acceso a un directorio en el que se van hacer búsquedas de adaptadores de prueba adicionales.
Solo se inspeccionan los archivos .dll con el sufijo .TestAdapter.dll . Si no se especifica, la búsqueda se
realiza en el directorio del archivo .dll de la prueba.
--blame

Ejecuta las pruebas en el modo de culpabilidad. Esta opción es útil para aislar las pruebas problemáticas
que hacen que el host de prueba se bloquee. Cuando se detecta un bloqueo, crea un archivo de
secuencia en TestResults/<Guid>/<Guid>_Sequence.xml que captura el orden de las pruebas ejecutadas
antes del bloqueo.
--blame-crash (Disponible desde el SDK de versión preliminar de .NET 5.0)
Ejecuta las pruebas en modo de culpa y recopila un volcado de memoria cuando el host de prueba se
cierra de forma inesperada. Esta opción depende de la versión de .NET que se use, del tipo de error y del
sistema operativo.
En el caso de las excepciones en el código administrado, se recopilará automáticamente un volcado de
memoria en .NET 5.0 y versiones posteriores. Generará un volcado de memoria para el host de prueba o
cualquier proceso secundario que también se haya ejecutado en .NET 5.0 y se haya bloqueado. Los
bloqueos en código nativo no generarán volcado de memoria. Esta opción funciona en Windows,
macOS y Linux.
Los volcados de memoria en código nativo o cuando se usa .NET Core 3.1 o versiones anteriores solo se
pueden recopilar en Windows, mediante Procdump. Un directorio que contenga procdump.exe y
procdump64.exe debe estar en la variable de entorno PATH o PROCDUMP_PATH. Descargue las
herramientas. Implica --blame .
Para recopilar un volcado de memoria de una aplicación nativa que se ejecuta en .NET 5.0 o una versión
posterior, se puede establecer la variable de entorno VSTEST_DUMP_FORCEPROCDUMP en 1 para forzar el uso
de Procdump.
--blame-crash-dump-type <DUMP_TYPE> (Disponible desde el SDK de versión preliminar de .NET 5.0)
El tipo de volcado de memoria que se va a recopilar. Implica --blame-crash .
--blame-crash-collect-always (Disponible desde el SDK de versión preliminar de .NET 5.0)
Recopila un volcado de memoria en la salida de host de prueba esperada e inesperada.
--blame-hang (Disponible desde el SDK de versión preliminar de .NET 5.0)
Ejecute las pruebas en modo de culpa y recopile un volcado de bloqueo cuando una prueba supere el
tiempo de espera especificado.
--blame-hang-dump-type <DUMP_TYPE> (Disponible desde el SDK de versión preliminar de .NET 5.0)
El tipo de volcado de memoria que se va a recopilar. Debe ser full , mini o none . Cuando se
especifica none , el host de prueba finaliza en el tiempo de espera, pero no se recopila ningún volcado.
Implica --blame-hang .
--blame-hang-timeout <TIMESPAN> (Disponible desde el SDK de versión preliminar de .NET 5.0)
Tiempo de espera por prueba, después del cual se desencadena un volcado de bloqueo y se genera un
volcado de memoria del proceso de host de prueba y todos sus procesos secundarios y se finalizan. El
valor de tiempo de espera se especifica en uno de los siguientes formatos:
1.5h, 1.5hour, 1.5hours
90m, 90min, 90minute, 90minutes
5400s, 5400sec, 5400second, 5400seconds
5400000ms, 5400000mil, 5400000millisecond, 5400000milliseconds
Cuando no se usa ninguna unidad (por ejemplo, 5 400 000), se supone que el valor está en
milisegundos. Cuando se usa junto con las pruebas basadas en datos, el comportamiento de tiempo de
espera depende del adaptador de prueba usado. En xUnit y NUnit, el tiempo de espera se renueva
después de cada caso de prueba. En MSTest, el tiempo de espera se usa en todos los casos de prueba.
Esta opción se admite en Windows con netcoreapp2.1 y versiones posteriores, en Linux con
netcoreapp3.1 y versiones posteriores y en macOS con net5.0 o versiones posteriores. Implica --blame
y --blame-hang .
-c|--configuration <CONFIGURATION>

Define la configuración de compilación. El valor predeterminado es Debug , pero la configuración del

proyecto podría invalidar esta configuración predeterminada del SDK.
--collect <DATA_COLLECTOR_NAME>

Habilita el recopilador de datos para la ejecución de pruebas. Para obtener más información, consulte
Monitor and analyze test run (Supervisar y analizar ejecuciones de pruebas).
Para recopilar la cobertura de código en cualquier plataforma compatible con .NET Core, instale Coverlet
y use la opción --collect:"XPlat Code Coverage" .
En Windows, puede recopilar la cobertura de código mediante la opción --collect "Code Coverage" .
Esta opción genera un archivo .coverage, que se puede abrir en Visual Studio 2019 Enterprise. Para más
información, vea Uso de cobertura de código y Personalización del análisis de cobertura de código.
-d|--diag <LOG_FILE>

Habilita el modo de diagnóstico de la plataforma de prueba y escribe mensajes de diagnóstico en el

archivo especificado y en los archivos que hay junto a él. El proceso que registra los mensajes determina
qué archivos se crean, como *.host_<date>.txt para el registro del host de prueba y
*.datacollector_<date>.txt para el registro del recopilador de datos.

-f|--framework <FRAMEWORK>

Fuerza el uso del host de prueba de dotnet o .NET Framework para los archivos binarios de prueba.
Esta opción solo determina el tipo de host que se va a usar. La versión de Framework real que se va a
usar viene determinada por runtimeConfig.json del proyecto de prueba. Si no se especifica, se usa el
atributo de ensamblado TargetFramework para determinar el tipo de host. Si ese atributo se quita de .dll,
se usa el host de .NET Framework.
--filter <EXPRESSION>

Filtra las pruebas del proyecto actual con la expresión dada. Para más información, consulte la sección
Detalles de la opción de filtro. Para obtener más información y ejemplos sobre cómo usar el filtrado de
pruebas unitarias selectivas, vea Ejecución de pruebas unitarias selectivas.
-h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se detenga y espere una entrada o una acción del usuario. Por ejemplo, para
completar la autenticación. Disponible desde el SDK de .NET Core 3.0.
-l|--logger <LOGGER>

Especifica un registrador para los resultados de pruebas. A diferencia de MSBuild, la prueba de dotnet
no acepta abreviaturas: en lugar de -l "console;v=d" use -l "console;verbosity=detailed" .
--no-build

No compila el proyecto de prueba antes de ejecutarlo. También establece la marca - --no-restore de

forma implícita.
--nologo

Ejecuta pruebas sin mostrar la pancarta de Microsoft TestPlatform. Disponible desde el SDK de
.NET Core 3.0.
--no-restore
 No ejecuta una restauración implícita al ejecutar el comando.
-o|--output <OUTPUT_DIRECTORY>

Directorio donde se encuentran los archivos binarios que se ejecutarán. Si no se especifica la ruta de
acceso predeterminada es ./bin/<configuration>/<framework>/ . En el caso de los proyectos con varias
plataformas de destino (a través de la propiedad TargetFrameworks ), también debe definir --framework
al especificar esta opción. dotnet test siempre ejecuta las pruebas desde el directorio de salida. Puede
usar AppDomain.BaseDirectory para consumir recursos de prueba en el directorio de salida.
-r|--results-directory <RESULTS_DIR>

El directorio donde se guardarán los resultados de pruebas. Si el directorio especificado no existe, se

crea. El valor predeterminado es TestResults en el directorio que contiene el archivo del proyecto.
--runtime <RUNTIME_IDENTIFIER>

Runtime de destino que probar.

-s|--settings <SETTINGS_FILE>

El archivo .runsettings que se usará para ejecutar las pruebas. El elemento TargetPlatform (x86|x64)
no tiene ningún efecto en dotnet test . Para ejecutar pruebas destinadas a x86, instale la versión x86 de
.NET Core. El valor de bits de dotnet.exe que se encuentra en la ruta de acceso es lo que se usará para
ejecutar las pruebas. Para obtener más información, vea los siguientes recursos:
Configuración de pruebas unitarias con un archivo .runsettings .
Configuración de una serie de pruebas
-t|--list-tests

Enumera las pruebas detectadas en vez de ejecutar las pruebas.

-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] . De manera predeterminada, es minimal . Para obtener más información,
vea LoggerVerbosity.
Argumentos de RunSettings

Los argumentos RunSettings insertados se pasan como los últimos argumentos en la línea de comandos
después de "-- " (fíjese en el espacio después de --). Los argumentos RunSettings insertados se especifican
como pares de [name]=[value] . Se usa un espacio para separar varios pares de [name]=[value] .
Ejemplo: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Para obtener más información, vea Paso de argumentos de RunSettings a través de la línea de comandos.

Ejemplos
Ejecución de las pruebas en el proyecto en el directorio actual:

dotnet test

Ejecute las pruebas en el proyecto test1 :

dotnet test ~/projects/test1/test1.csproj

 Ejecute las pruebas del proyecto en el directorio actual y genere un archivo de resultados de prueba en
formato trx:

dotnet test --logger trx

Ejecute las pruebas del proyecto en el directorio actual y genere un archivo de cobertura de código
(después de instalar la integración de recopiladores de Coverlet):

dotnet test --collect:"XPlat Code Coverage"

Ejecute las pruebas en el proyecto en el directorio actual y genere un archivo de cobertura de código
(solo en Windows):

dotnet test --collect "Code Coverage"

Ejecute las pruebas del proyecto en el directorio actual y regístrese con el nivel de detalle
pormenorizado en la consola:

dotnet test --logger "console;verbosity=detailed"

Ejecute las pruebas del proyecto en el directorio actual e informe de las pruebas que estaban en curso
cuando se bloqueó el host de prueba:

dotnet test --blame

Detalles de la opción de filtro

--filter <EXPRESSION>

<Expression> tiene el formato <property><operator><value>[|&<Expression>] .

<property> es un atributo del tipo Test Case . Las siguientes son las propiedades admitidas por los marcos de
pruebas unitarias populares:

M A RC O DE P RUEB A P RO P IEDA DES A DM IT IDA S

MSTest FullyQualifiedName
NOMBRE
ClassName
Prioridad
TestCategory

xUnit FullyQualifiedName
DisplayName
Rasgos
 M A RC O DE P RUEB A P RO P IEDA DES A DM IT IDA S

NUnit FullyQualifiedName
NOMBRE
TestCategory
Prioridad

<operator> describe la relación entre la propiedad y el valor:

O P ERA DO R F UN C IÓ N

= Coincidencia exacta

!= Coincidencia no exacta

~ Contiene

!~ No contiene

<value> es una cadena. Todas las búsquedas distinguen mayúsculas de minúsculas.

Una expresión sin <operator> automáticamente se considera un contains en la propiedad
FullyQualifiedName (por ejemplo, dotnet test --filter xyz es lo mismo que
dotnet test --filter FullyQualifiedName~xyz ).

Las expresiones se pueden combinar con operadores condicionales:

O P ERA DO R F UN C IÓ N

| O

& AND

Si usa operadores condicionales (por ejemplo, (Name~TestMethod1) | (Name~TestMethod2) ), puede incluir las
expresiones entre paréntesis.
Para obtener más información y ejemplos sobre cómo usar el filtrado de pruebas unitarias selectivas, vea
Ejecución de pruebas unitarias selectivas.

Vea también
Marcos y destinos
Catálogo de identificadores de entorno de ejecución (RID) de .NET Core
Paso de argumentos runsettings a través de la línea de comandos
 dotnet tool install
18/12/2020 • 4 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet tool install : instala la herramienta de .NET especificada en el equipo.

Sinopsis
dotnet tool install <PACKAGE_NAME> -g|--global
[--add-source <SOURCE>] [--configfile <FILE>]
[--framework <FRAMEWORK>] [-v|--verbosity <LEVEL>]
[--version <VERSION_NUMBER>]

dotnet tool install <PACKAGE_NAME> --tool-path <PATH>

[--add-source <SOURCE>] [--configfile <FILE>]
[--framework <FRAMEWORK>] [-v|--verbosity <LEVEL>]
[--version <VERSION_NUMBER>]

dotnet tool install <PACKAGE_NAME>

[--add-source <SOURCE>] [--configfile <FILE>]
[--framework <FRAMEWORK>] [-v|--verbosity <LEVEL>]
[--version <VERSION_NUMBER>]

dotnet tool install -h|--help

Descripción
El comando dotnet tool install permite instalar herramientas de .NET en el equipo. Para usar el comando,
especifique una de las siguientes opciones de instalación:
Para instalar una herramienta global en la ubicación predeterminada, use la opción --global .
Para instalar una herramienta global en una ubicación personalizada, use la opción --tool-path .
Para instalar una herramienta local, omita las opciones --global y --tool-path .

Las herramientas locales están disponibles a par tir del SDK de .NET Core 3.0.
Las herramientas globales se instalan en los siguientes directorios de forma predeterminada cuando se
especifica la opción -g o --global :

SO RUTA DE A C C ESO

Linux/macOS $HOME/.dotnet/tools

Windows %USERPROFILE%\.dotnet\tools

Las herramientas locales se agregan a un archivo dotnet-tools.json en un directorio .config en el directorio

actual. Si aún no existe un archivo de manifiesto, créelo ejecutando el siguiente comando:
 dotnet new tool-manifest

Para obtener más información, vea Instalación de una herramienta local.

Argumentos
PACKAGE_NAME

Nombre o identificador del paquete NuGet que contiene la herramienta de .NET que se va a instalar.

Opciones
add-source <SOURCE>

Agrega un origen de paquete NuGet adicional que se usará durante la instalación.

configfile <FILE>

El archivo de configuración de NuGet (nuget.config) que se usará.

framework <FRAMEWORK>

Especifica el marco de destino para instalar la herramienta. De forma predeterminada, el SDK de .NET
intenta elegir la plataforma de destino más apropiada.
-g|--global

Especifica que la instalación se realiza en todos los usuarios. No se puede combinar con la opción
--tool-path . Al omitir --global y --tool-path , se especifica la instalación de una herramienta local.

-h|--help

Imprime una corta ayuda para el comando.

tool-path <PATH>

Especifica la ubicación de donde se tiene que instalar la herramienta global. PATH puede ser una ruta
absoluta o relativa. Si la ruta no existe, el comando intenta crearla. Al omitir --global y --tool-path ,
se especifica la instalación de una herramienta local.
-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] .

--version <VERSION_NUMBER>

La versión de la herramienta que se va instalar. De forma predeterminada, se instala la versión estable

más reciente del paquete. Utilice esta opción para instalar la versión preliminar o versiones anteriores
de la herramienta.

Ejemplos
dotnet tool install -g dotnetsay

Instala dotnetsay como herramienta global en la ubicación predeterminada.

dotnet tool install dotnetsay --tool-path c:\global-tools
 Instala dotnetsay como herramienta global en un directorio específico de Windows.
dotnet tool install dotnetsay --tool-path ~/bin

Instala dotnetsay como herramienta global en un directorio específico de Linux/macOS.

dotnet tool install -g dotnetsay --version 2.0.0

Instala la versión 2.0.0 de dotnetsay como la herramienta global.

dotnet tool install dotnetsay

Instala dotnetsay como herramienta local del directorio actual.

Vea también
Herramientas de .NET
Tutorial: Instalación y uso de una herramienta global de .NET mediante la CLI de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 dotnet tool list
18/12/2020 • 3 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet tool list : enumera todas las herramientas de .NET del tipo especificado actualmente instalado en el
equipo.

Sinopsis
dotnet tool list -g|--global

dotnet tool list --tool-path <PATH>

dotnet tool list --local

dotnet tool list

dotnet tool list -h|--help

Descripción
El comando dotnet tool list permite enumerar todas las herramientas locales, de ruta de acceso de
herramienta y globales de .NET instaladas en el equipo. El comando enumera el nombre del paquete, la versión
instalada y el comando de la herramienta. Para usar el comando, especifique una de las siguientes opciones:
Para enumerar las herramientas globales instaladas en la ubicación predeterminada, use la opción --global .
Para enumerar las herramientas globales instaladas en la ubicación personalizada, use la opción --tool-path .
Para enumerar las herramientas locales, use la opción --local u omita las opciones --global , --tool-path
y --local .
Las herramientas locales están disponibles a par tir del SDK de .NET Core 3.0.

Opciones
-g|--global

Enumera las herramientas globales de los usuarios. No se puede combinar con la opción --tool-path . Al
omitir --global y --tool-path , se muestran las herramientas locales.
-h|--help

Imprime una corta ayuda para el comando.

--local

Enumera las herramientas locales del directorio actual. No se puede combinar con las opciones --global
o --tool-path . Al omitir --global y --tool-path , se enumeran las herramientas locales, aunque no se
haya especificado --local .
 --tool-path <PATH>

Especifica una ubicación personalizada para las herramientas globales. PATH puede ser una ruta absoluta o
relativa. No se puede combinar con la opción --global . Al omitir --global y --tool-path , se muestran
las herramientas locales.

Ejemplos
dotnet tool list -g

Enumera todas las herramientas globales instaladas para todos los usuarios en su equipo (perfil de
usuario actual).
dotnet tool list --tool-path c:\global-tools

Enumera las herramientas globales de un directorio específico de Windows.

dotnet tool list --tool-path ~/bin

Enumera las herramientas globales de un directorio específico de Linux/macOS.

dotnet tool list o dotnet tool list --local

Enumera todas las herramientas locales disponibles en el directorio actual.

Vea también
Herramientas de .NET
Tutorial: Instalación y uso de una herramienta global de .NET mediante la CLI de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 dotnet tool restore
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores

NOMBRE
dotnet tool restore : instala las herramientas locales de .NET que se encuentran en el ámbito del directorio actual.

Sinopsis
dotnet tool restore
[--configfile <FILE>] [--add-source <SOURCE>]
[tool-manifest <PATH_TO_MANIFEST_FILE>] [--disable-parallel]
[--ignore-failed-sources] [--no-cache] [--interactive]
[-v|--verbosity <LEVEL>]

dotnet tool restore -h|--help

Descripción
El comando dotnet tool restore busca el archivo de manifiesto de las herramientas que está en el ámbito del
directorio actual e instala las herramientas que se indican en él. Para obtener información sobre los archivos de
manifiesto, vea Instalación de una herramienta local e Invocación de una herramienta local.

Opciones
--configfile <FILE>

El archivo de configuración de NuGet (nuget.config) que se usará.

--add-source <SOURCE>

Agrega un origen de paquete NuGet adicional que se usará durante la instalación.

--tool-manifest <PATH>

Ruta de acceso al archivo de manifiesto.

--disable-parallel

Impide que se restauren varios proyectos en paralelo.

--ignore-failed-sources

Indica que los errores de origen de paquete se traten como advertencias.

--no-cache

Indica que no se almacenen en caché los paquetes ni las solicitudes HTTP.

--interactive

Permite que el comando se detenga y espere la entrada o acción del usuario (por ejemplo, completar la
autenticación).
 -h|--help

Imprime una corta ayuda para el comando.

-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] .

Ejemplo
dotnet tool restore

Restaura las herramientas locales del directorio actual.

Vea también
Herramientas de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 dotnet tool run
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores

NOMBRE
dotnet tool run : invoca una herramienta local.

Sinopsis
dotnet tool run <COMMAND NAME>

dotnet tool run -h|--help

Descripción
El comando dotnet tool run busca los archivos de manifiesto de las herramientas que se encuentran en el ámbito
del directorio actual. Cuando encuentra una referencia a la herramienta especificada, ejecuta la herramienta. Para
obtener más información, vea Invocación de una herramienta local.

Argumentos
COMMAND_NAME

El nombre del comando de la herramienta que se va a ejecutar.

Opciones
-h|--help

Imprime una corta ayuda para el comando.

Ejemplo
dotnet tool run dotnetsay

Ejecuta la herramienta local dotnetsay .

Vea también
Herramientas de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 dotnet tool search
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET 5.0 y versiones posteriores

Name
dotnet tool search : busca todas las herramientas de .NET publicadas en NuGet.

Sinopsis
dotnet tool search [--detail] [--prerelease]
[--skip <NUMBER>] [--take <NUMBER>] <SEARCH TERM>

dotnet tool search -h|--help

Descripción
El comando dotnet tool search proporciona una manera de buscar en NuGet las herramientas que se pueden
usar como herramientas globales, de ruta de acceso de herramientas o locales de .NET. El comando busca en los
nombres de herramienta y los metadatos, como títulos, descripciones y etiquetas.
El comando usa la API Search de NuGet. Filtra por packageType=dotnettool para seleccionar solo los paquetes de
herramientas de .NET.

Opciones
--detail

Muestra los resultados detallados de la consulta.

--prerelease

Incluye paquetes en versión preliminar.

--skip <NUMBER>

Especifica el número de resultados de la consulta que se omiten. Se usa para la paginación.

--take <NUMBER>

Especifica el número de resultados de la consulta que se muestran. Se usa para la paginación.

-h|--help

Muestra la ayuda de la línea de comandos.

Ejemplos
Busque herramientas de .NET en NuGet.org que incluyan "formato" en el nombre o la descripción del
paquete:
 dotnet tool search format

La salida se parece al ejemplo siguiente:

Package ID Latest Version Authors

Downloads Verified
--------------------------------------------------------------------------------------------------------
-------------------------------------------------------
dotnet-format 4.1.131201 Microsoft
496746
bsoa.generator 1.0.0 Microsoft
533

Busque herramientas de .NET en NuGet.org que incluyan "formato" en el nombre o los metadatos del
paquete, muestre solo el primer resultado y muestre una vista detallada.

dotnet tool search format --take 1 --detail

La salida se parece al ejemplo siguiente:

----------------
dotnet-format
Latest Version: 4.1.131201
Authors: Microsoft
Tags:
Downloads: 496746
Verified: False
Description: Command line tool for formatting C# and Visual Basic code files based on .editorconfig
settings.
Versions:
3.0.2 Downloads: 1973
3.0.4 Downloads: 9064
3.1.37601 Downloads: 114730
3.2.107702 Downloads: 13423
3.3.111304 Downloads: 131195
4.0.130203 Downloads: 78610
4.1.131201 Downloads: 145927

Consulte también
Herramientas de .NET
Tutorial: Instalación y uso de una herramienta global de .NET mediante la CLI de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 dotnet tool uninstall
18/12/2020 • 3 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet tool uninstall : desinstala la herramienta de .NET especificada del equipo.

Sinopsis
dotnet tool uninstall <PACKAGE_NAME> -g|--global

dotnet tool uninstall <PACKAGE_NAME> --tool-path <PATH>

dotnet tool uninstall <PACKAGE_NAME>

dotnet tool uninstall -h|--help

Descripción
El comando dotnet tool uninstall permite desinstalar del equipo herramientas de .NET. Para usar el comando,
especifique una de las siguientes opciones:
Para desinstalar una herramienta global que se instaló en la ubicación predeterminada, use la opción
--global .
Para desinstalar una herramienta global que se instaló en una ubicación personalizada, use la opción
--tool-path .
Para desinstalar una herramienta local, omita las opciones --global y --tool-path .
Las herramientas locales están disponibles a par tir del SDK de .NET Core 3.0.

Argumentos
PACKAGE_NAME

Nombre o identificador del paquete NuGet que contiene la herramienta de .NET que se va a desinstalar.
Para conocer el nombre el paquete, use el comando dotnet tool list.

Opciones
-g|--global

Especifica que la herramienta que se va a quitar es de una instalación en el ámbito de los usuarios. No se
puede combinar con la opción --tool-path . Al omitir --global y --tool-path , se especifica que la
herramienta que se va a quitar es una herramienta local.
-h|--help

Imprime una corta ayuda para el comando.

--tool-path <PATH>
 Especifica la ubicación de donde se tiene que desinstalar la herramienta. PATH puede ser una ruta absoluta
o relativa. No se puede combinar con la opción --global . Al omitir --global y --tool-path , se especifica
que la herramienta que se va a quitar es una herramienta local.

Ejemplos
dotnet tool uninstall -g dotnetsay

Desinstala la herramienta global dotnetsay.

dotnet tool uninstall dotnetsay --tool-path c:\global-tools

Desinstala la herramienta global dotnetsay de un directorio específico de Windows.

dotnet tool uninstall dotnetsay --tool-path ~/bin

Desinstala la herramienta global dotnetsay de un directorio específico de Linux/macOS.

dotnet tool uninstall dotnetsay

Desinstala la herramienta local dotnetsay del directorio actual.

Vea también
Herramientas de .NET
Tutorial: Instalación y uso de una herramienta global de .NET mediante la CLI de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 dotnet tool update
18/12/2020 • 5 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE
dotnet tool update : actualiza la herramienta de .NET especificada en el equipo.

Sinopsis
dotnet tool update <PACKAGE_ID> -g|--global
[--add-source <SOURCE>] [--configfile <FILE>]
[--disable-parallel] [--framework <FRAMEWORK>]
[--ignore-failed-sources] [--interactive] [--no-cache]
[-v|--verbosity <LEVEL>] [--version <VERSION>]

dotnet tool update <PACKAGE_ID> --tool-path <PATH>

[--add-source <SOURCE>] [--configfile <FILE>]
[--disable-parallel] [--framework <FRAMEWORK>]
[--ignore-failed-sources] [--interactive] [--no-cache]
[-v|--verbosity <LEVEL>] [--version <VERSION>]

dotnet tool update <PACKAGE_ID> --local

[--add-source <SOURCE>] [--configfile <FILE>]
[--disable-parallel] [--framework <FRAMEWORK>]
[--ignore-failed-sources] [--interactive] [--no-cache]
[--tool-manifest <PATH>]
[-v|--verbosity <LEVEL>] [--version <VERSION>]

dotnet tool update -h|--help

Descripción
El comando dotnet tool update permite actualizar las herramientas de .NET en el equipo a la versión estable más
reciente del paquete. El comando desinstala y vuelve a instalar una herramienta, actualizándola de facto. Para usar
el comando, especifique una de las siguientes opciones:
Para actualizar una herramienta global que se instaló en la ubicación predeterminada, use la opción --global .
Para actualizar una herramienta global que se instaló en una ubicación personalizada, use la opción
--tool-path .
Para actualizar una herramienta local, use la opción --local .
Las herramientas locales están disponibles a par tir del SDK de .NET Core 3.0.

Argumentos
PACKAGE_ID

Nombre o identificador del paquete NuGet que contiene la herramienta global de .NET que se va a
actualizar. Para conocer el nombre el paquete, use el comando dotnet tool list.

Opciones
--add-source <SOURCE>

Agrega un origen de paquete NuGet adicional que se usará durante la instalación.

--configfile <FILE>

El archivo de configuración de NuGet (nuget.config) que se usará.

--disable-parallel

Impide que se restauren varios proyectos en paralelo.

--framework <FRAMEWORK>

Especifica la plataforma de destino para la que se actualiza la herramienta.

--ignore-failed-sources

Indica que los errores de origen de paquete se traten como advertencias.

--interactive

Permite que el comando se detenga y espere la entrada o acción del usuario (por ejemplo, completar la
autenticación).
--local

Actualice la herramienta y el manifiesto de la herramienta local. No se puede combinar con las opciones
--global o --tool-path .

--no-cache

Indica que no se almacenen en caché los paquetes ni las solicitudes HTTP.

--tool-manifest <PATH>

Ruta de acceso al archivo de manifiesto.

--tool-path <PATH>

Especifica la ubicación en la que está instalada la herramienta global. PATH puede ser una ruta absoluta o
relativa. No se puede combinar con la opción --global . Al omitir --global y --tool-path , se especifica
que la herramienta que se va a actualizar es una herramienta local.
--version <VERSION>

El intervalo de versiones del paquete de herramientas al que se actualiza. Esto no se puede usar para
degradar versiones, primero debe uninstall versiones más recientes.
-g|--global

Especifica que la actualización es para una herramienta del ámbito de los usuarios. No se puede combinar
con la opción --tool-path . Al omitir --global y --tool-path , se especifica que la herramienta que se va a
actualizar es una herramienta local.
-h|--help

Imprime una corta ayuda para el comando.

-v|--verbosity <LEVEL>

Establece el nivel de detalle del comando. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] .
Ejemplos
dotnet tool update -g dotnetsay

Actualiza la herramienta global dotnetsay.

dotnet tool update dotnetsay --tool-path c:\global-tools

Actualiza la herramienta global dotnetsay ubicada en un directorio específico de Windows.

dotnet tool update dotnetsay --tool-path ~/bin

Actualiza la herramienta global dotnetsay ubicada en un directorio específico de Linux/macOS.

dotnet tool update dotnetsay

Actualiza la herramienta local dotnetsay instalada para el directorio actual.

dotnet tool update -g dotnetsay --version 2.0.*

Actualiza la herramienta global dotnetsay a la última versión de revisión, con una versión principal de 2 y
una versión secundaria de 0 .
dotnet tool update -g dotnetsay --version (2.0.*,2.1.4)

Actualiza la herramienta global dotnetsay a la versión más baja del intervalo especificado
(> 2.0.0 && < 2.1.4) ; se instalará la versión 2.1.0 . Para obtener más información sobre los intervalos de
versiones semánticas, consulte Intervalos de versiones de empaquetado de NuGet.

Vea también
Herramientas de .NET
Versionamiento semántico
Tutorial: Instalación y uso de una herramienta global de .NET mediante la CLI de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 dotnet vstest
12/05/2020 • 6 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores

IMPORTANT
El comando dotnet vstest se sustituye por dotnet test , que ahora se puede usar para ejecutar ensamblados. Vea
dotnet test .

NOMBRE
dotnet-vstest : permite ejecutar pruebas a partir de los ensamblados especificados.

Sinopsis
dotnet vstest [<TEST_FILE_NAMES>] [--Blame] [--Diag <PATH_TO_LOG_FILE>]
[--Framework <FRAMEWORK>] [--InIsolation] [-lt|--ListTests <FILE_NAME>]
[--logger <LOGGER_URI/FRIENDLY_NAME>] [--Parallel]
[--ParentProcessId <PROCESS_ID>] [--Platform] <PLATFORM_TYPE>
[--Port <PORT>] [--ResultsDirectory<PATH>] [--Settings <SETTINGS_FILE>]
[--TestAdapterPath <PATH>] [--TestCaseFilter <EXPRESSION>]
[--Tests <TEST_NAMES>] [[--] <args>...]]

dotnet vstest -?|--Help

Descripción
El comando dotnet-vstest ejecuta la aplicación de línea de comandos VSTest.Console para ejecutar pruebas
unitarias automatizadas.

Argumentos
TEST_FILE_NAMES

Ejecutar pruebas desde los ensamblados especificados. Separar varios nombres de ensamblado de prueba
con espacios. Se admite caracteres comodín.

Opciones
--Blame

Ejecuta las pruebas en el modo de culpabilidad. Esta opción es útil para aislar las pruebas problemáticas que
hacen que el host de prueba se bloquee. Crea un archivo de salida en el directorio actual como
Sequence.xml que captura el orden de ejecución de pruebas antes del bloqueo.
--Diag <PATH_TO_LOG_FILE>

Permite registros detallados para la plataforma de prueba. Los registros se escriben en el archivo
proporcionado.
--Framework <FRAMEWORK>

Identificar la versión de .NET Framework usada en la ejecución de pruebas. Ejemplos de valores válidos son
.NETFramework,Version=v4.6 o .NETCoreApp,Version=v1.0 . Otros valores admitidos son Framework40 ,
Framework45 , FrameworkCore10 y FrameworkUap10 .

--InIsolation

Ejecuta las pruebas en un proceso aislado. De este modo, es menos probable que el proceso
vstest.console.exe se detenga por un error de las pruebas, pero es posible que las pruebas se ejecuten más
despacio.
-lt|--ListTests <FILE_NAME>

Muestra todas las pruebas detectadas del contenedor de pruebas especificado.

--logger <LOGGER_URI/FRIENDLY_NAME>

Especifica un registrador para resultados de pruebas.

Para publicar resultados de pruebas en Team Foundation Server, use el proveedor de registrador
TfsPublisher :

/logger:TfsPublisher;
Collection=<team project collection url>;
BuildName=<build name>;
TeamProject=<team project name>
[;Platform=<Defaults to "Any CPU">]
[;Flavor=<Defaults to "Debug">]
[;RunTitle=<title>]

Para registrar los resultados en un archivo de resultados de pruebas (TRX) de Visual Studio, use el
proveedor de registrador trx . Este modificador, crea un archivo en el directorio de resultados de
pruebas con un nombre de archivo de registro dado. Si no se proporciona LogFileName , se crea un
nombre de archivo único para contener los resultados de las pruebas.

/logger:trx [;LogFileName=<Defaults to unique file name>]

--Parallel

Ejecuta pruebas en paralelo. De forma predeterminada, todos los núcleos disponibles en el equipo están
disponibles para su uso. Especifique un número explícito de núcleos mediante la configuración de la
propiedad MaxCpuCount en el nodo RunConfiguration del archivo runsettings.
--ParentProcessId <PROCESS_ID>

Id. de proceso del proceso principal responsable de iniciar el proceso actual.

--Platform <PLATFORM_TYPE>

Identificar la arquitectura de la plataforma usada en la ejecución de pruebas. Valores válidos son x86 , x64
y ARM .
--Port <PORT>

Especifica el puerto para la conexión de socket y la recepción de mensajes de eventos.

--ResultsDirectory:<PATH>
 Si no existe, el directorio de los resultados de la prueba se creará en la ruta de acceso especificada.
--Settings <SETTINGS_FILE>

Configuración que se usará al ejecutar las pruebas.

--TestAdapterPath <PATH>

Usar adaptadores de prueba personalizados desde una ruta de acceso especificada (si existe) en la serie de
pruebas.
--TestCaseFilter <EXPRESSION>

Ejecuta pruebas que coinciden con la expresión dada. <EXPRESSION> tiene el formato
<property>Operator<value>[|&<EXPRESSION>] , donde Operator es = , != o ~ . El operador ~ tiene
semántica "contains" y se aplica a las propiedades de cadena como DisplayName . Los paréntesis () se usan
para agrupar subexpresiones. Para obtener más información, vea Filtro TestCase.
--Tests <TEST_NAMES>

Ejecuta las pruebas con nombres que coinciden con los Separar varios valores con comas.
-?|--Help

Imprime una corta ayuda para el comando.

@<file>

Lee el archivo de respuesta para ver más opciones.

args

Especifica argumentos adicionales para pasar al adaptador. Los argumentos se especifican como pares de
nombre-valor en el formato <n>=<v> , donde <n> es el nombre del argumento y <v> es el valor del
argumento. Use un espacio para separar varios argumentos.

Ejemplos
Ejecución de pruebas en mytestproject.dll:

dotnet vstest mytestproject.dll

Ejecución de pruebas en mytestproject.dll, exportación a una carpeta personalizada con nombre personalizado:

dotnet vstest mytestproject.dll --logger:"trx;LogFileName=custom_file_name.trx" --

ResultsDirectory:custom/file/path

Ejecución de pruebas en mytestproject.dll y myothertestproject.exe:

dotnet vstest mytestproject.dll myothertestproject.exe

Ejecutar pruebas TestMethod1 :

dotnet vstest /Tests:TestMethod1

Ejecutar pruebas TestMethod1 y TestMethod2 :

 dotnet vstest /Tests:TestMethod1,TestMethod2

Vea también
Opciones de la línea de comandos para VSTest.Console.exe
 referencia de scripts de dotnet-install
18/12/2020 • 11 minutes to read • Edit Online

NOMBRE
dotnet-install.ps1 | dotnet-install.sh : script usado para instalar el SDK de .NET y el entorno de
ejecución compartido.

Sinopsis
Windows:

dotnet-install.ps1 [-Architecture <ARCHITECTURE>] [-AzureFeed]

[-Channel <CHANNEL>] [-DryRun] [-FeedCredential]
[-InstallDir <DIRECTORY>] [-JSonFile <JSONFILE>]
[-NoCdn] [-NoPath] [-ProxyAddress] [-ProxyBypassList <LIST_OF_URLS>]
[-ProxyUseDefaultCredentials] [-Runtime <RUNTIME>]
[-SkipNonVersionedFiles] [-UncachedFeed] [-Verbose]
[-Version <VERSION>]

Get-Help ./dotnet-install.ps1

Linux/macOS:

dotnet-install.sh [--architecture <ARCHITECTURE>] [--azure-feed]

[--channel <CHANNEL>] [--dry-run] [--feed-credential]
[--install-dir <DIRECTORY>] [--jsonfile <JSONFILE>]
[--no-cdn] [--no-path] [--runtime <RUNTIME>] [--runtime-id <RID>]
[--skip-non-versioned-files] [--uncached-feed] [--verbose]
[--version <VERSION>]

dotnet-install.sh --help

El script de bash también lee modificadores de PowerShell, por lo que puede usar modificadores de
PowerShell con el script en sistemas Linux y macOS.

Descripción
Los scripts dotnet-install realizan una instalación sin derechos administrativos del SDK de .NET, que
incluye la CLI de .NET y el entorno de ejecución compartido. Hay dos scripts:
un script de PowerShell que funciona en Windows;
un script de Bash que funciona en Linux y macOS.
Propósito
El uso previsto de los scripts es en escenarios de integración continua (CI), donde:
el SDK debe instalarse sin interacción del usuario y sin derechos de administrador;
no es necesario que la instalación del SDK se mantenga en varias ejecuciones de CI.
Esta es la secuencia típica de eventos:
Se desencadena la CI.
 CI instala el SDK mediante uno de estos scripts.
CI finaliza su trabajo y borra los datos temporales, incluida la instalación del SDK.
Para configurar un entorno de desarrollo o ejecutar aplicaciones, use los instaladores en lugar de estos
scripts.
Versión recomendada
Se recomienda usar la versión estable de los scripts:
Bash (Linux/macOS): https://dot.net/v1/dotnet-install.sh
PowerShell (Windows): https://dot.net/v1/dotnet-install.ps1
Comportamiento de los scripts
Ambos scripts tienen el mismo comportamiento. Descargan el archivo ZIP o tarball desde las entregas
de compilación de la CLI y proceden a instalarlo en la ubicación predeterminada o en una ubicación
especificada por -InstallDir|--install-dir .
De forma predeterminada, los scripts de instalación descargan el SDK y lo instalan. Si desea obtener
solo el tiempo de ejecución compartido, especifique el argumento -Runtime|--runtime .
De forma predeterminada, el script agrega la ubicación de instalación a $PATH para la sesión actual.
Para invalidar este comportamiento, especifique el argumento -NoPath|--no-path . El script no
establece la variable de entorno DOTNET_ROOT .
Antes de ejecutar el script, instale las dependencias necesarias.
Puede instalar una versión específica mediante el argumento -Version|--version . La versión debe
especificarse como un número de versión de tres partes, por ejemplo, 2.1.0 . Si no se especifica la
versión, el script instala la versión latest .
Los scripts de instalación no actualizan el Registro en Windows. Solo descargan los archivos binarios
comprimidos y los copian en una carpeta. Si quiere que se actualicen los valores de las claves del
Registro, use los instaladores de .NET.

Opciones
-Architecture|--architecture <ARCHITECTURE>

Arquitectura de los archivos binarios de .NET para instalar. Los valores posibles son <auto> ,
amd64 , x64 , x86 , arm64 y arm . El valor predeterminado es <auto> , que representa la
arquitectura de SO que se ejecuta en ese momento.
-AzureFeed|--azure-feed

Especifica la dirección URL de la fuente de Azure al instalador. Le recomendamos que no cambie

este valor. El valor predeterminado es https://dotnetcli.azureedge.net/dotnet .
-Channel|--channel <CHANNEL>

Especifica el canal de origen para la instalación. Los valores posibles son:

Current : versión más actual.
LTS : canal de soporte técnico a largo plazo (versión compatible más actual).
Versión de dos partes en formato X.Y que representa una versión específica (por ejemplo,
2.1 o 3.0 ).
Nombre de rama: por ejemplo, release/3.1.1xx o master (para versiones nocturnas). Use
esta opción para instalar una versión de un canal de versión preliminar. Use el nombre del
 canal como aparece en Instaladores y binarios.
El valor predeterminado es LTS . Para más información sobre los canales de soporte técnico de
.NET, vea la página .NET Support Policy (Directiva de soporte técnico de .NET Core).
-DryRun|--dry-run

Si se establece, el script no realizará la instalación. En su lugar, muestra qué línea de comandos

se va a usar para instalar de manera coherente la versión solicitada actualmente de la CLI de
.NET. Por ejemplo, si especifica la versión latest , se muestra un vínculo con la versión
específica, de manera que este comando puede usarse de manera determinista en un script de
compilación. También se muestra la ubicación de los archivos binarios si prefiere instalarla o
descargarla por su cuenta.
-FeedCredential|--feed-credential

Se utiliza como una cadena de consulta para anexar a la fuente de Azure. Permite cambiar la
dirección URL para usar cuentas de almacenamiento de blobs no público.
--help

Imprime la ayuda para el script. Solo se aplica al script de Bash. Para PowerShell, use
Get-Help ./dotnet-install.ps1 .

-InstallDir|--install-dir <DIRECTORY>

Especifica la ruta de instalación. Si no existe el directorio, se crea. El valor predeterminado es

%LocalAppData%\Microsoft\dotnet en Windows y /usr/share/dotnet en Linux/macOS. Los
archivos binarios se colocan directamente en el directorio.
-JSonFile|--jsonfile <JSONFILE>

Especifica una ruta de acceso a un archivo global.json que se va a usar para determinar la
versión del SDK. El archivo global.json debe tener un valor para sdk:version .
-NoCdn|--no-cdn

Deshabilita la descarga desde Azure Content Delivery Network (CDN) y usa la fuente no
almacenada en caché directamente.
-NoPath|--no-path

Si se establece, la carpeta de instalación no se exporta a la ruta de acceso para la sesión actual.

De manera predeterminada, el script modifica la variable de entorno PATH, que hace que la CLI
de .NET esté disponible inmediatamente después de la instalación.
-ProxyAddress

Si se establece, el instalador usa el proxy al realizar solicitudes web. (Solo es válido para
Windows).
-ProxyBypassList <LIST_OF_URLS>

Si se establece con ProxyAddress , proporciona una lista de direcciones URL separadas por
comas que omiten el proxy. (Solo es válido para Windows).
ProxyUseDefaultCredentials

Si se establece, el instalador usa las credenciales del usuario actual cuando se usa la dirección
del proxy. (Solo es válido para Windows).
 -Runtime|--runtime <RUNTIME>

Se instala simplemente el entorno de tiempo de ejecución compartido, no el SDK completo. Los

valores posibles son:
dotnet : el entorno de tiempo de ejecución compartido Microsoft.NETCore.App .
aspnetcore : el entorno de tiempo de ejecución compartido Microsoft.AspNetCore.App .
windowsdesktop : el entorno de tiempo de ejecución compartido
Microsoft.WindowsDesktop.App .

--runtime-id <RID>

Especifica el identificador de entorno de ejecución para el que se van a instalar las herramientas.
Use linux-x64 para Linux portátil. (Solo es válido para Linux/macOS).
-SharedRuntime|--shared-runtime

NOTE
Este parámetro está obsoleto y puede quitarse en una versión futura del script. La alternativa
recomendada es la opción -Runtime|--runtime .

Se instalan simplemente los bits del entorno de tiempo de ejecución compartido, no el SDK
completo. Esta opción equivale a especificar -Runtime|--runtime dotnet .
-SkipNonVersionedFiles|--skip-non-versioned-files

Omite la instalación de archivos sin control de versiones, como dotnet.exe, si ya existen.

-UncachedFeed|--uncached-feed

Permite cambiar la dirección URL de la fuente no almacenada en caché que este instalador
utiliza. Le recomendamos que no cambie este valor.
-Verbose|--verbose

Muestra la información de diagnóstico.

-Version|--version <VERSION>

Representa una versión de compilación concreta. Los valores posibles son:

latest : compilación más reciente en el canal (utilizado con la opción -Channel ).
Versión de tres partes en formato X.Y.Z que representa una determinada versión de
compilación; reemplaza a la opción -Channel . Por ejemplo: 2.0.0-preview2-006120 .
Si no se especifica, el valor predeterminado de -Version es latest .

Ejemplos
Instale la versión compatible a largo plazo más reciente en la ubicación predeterminada:
Windows:

./dotnet-install.ps1 -Channel LTS

macOS y Linux:
 ./dotnet-install.sh --channel LTS

Instale la versión más reciente del canal 3.1 en la ubicación especificada:

Windows:

./dotnet-install.ps1 -Channel 3.1 -InstallDir C:\cli

macOS y Linux:

./dotnet-install.sh --channel 3.1 --install-dir ~/cli

Instale la versión 3.0.0 del entorno de ejecución compartido:

Windows:

./dotnet-install.ps1 -Runtime dotnet -Version 3.0.0

macOS y Linux:

./dotnet-install.sh --runtime dotnet --version 3.0.0

Obtenga el script e instale la versión 2.1.2 detrás de un proxy corporativo (solo Windows):

Invoke-WebRequest 'https://dot.net/v1/dotnet-install.ps1' -Proxy $env:HTTP_PROXY -

ProxyUseDefaultCredentials -OutFile 'dotnet-install.ps1';
./dotnet-install.ps1 -InstallDir '~/.dotnet' -Version '2.1.2' -ProxyAddress $env:HTTP_PROXY
-ProxyUseDefaultCredentials;

Obtenga el script e instale ejemplos de una línea para la CLI de .NET:

Windows:

# Run a separate PowerShell process because the script calls exit, so it will end the
current PowerShell session.
&powershell -NoProfile -ExecutionPolicy unrestricted -Command "
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; &
([scriptblock]::Create((Invoke-WebRequest -UseBasicParsing 'https://dot.net/v1/dotnet-
install.ps1'))) <additional install-script args>"

macOS y Linux:

curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin <additional install-script

args>

Vea también
Versiones de .NET
Archivo de descarga del SDK y el entorno de ejecución de .NET
 dotnet add reference
04/05/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet add reference Agrega referencias entre proyectos (P2P) .

Sinopsis
dotnet add [<PROJECT>] reference [-f|--framework <FRAMEWORK>]
[--interactive] <PROJECT_REFERENCES>

dotnet add reference -h|--help

Descripción
El comando dotnet add reference constituye una opción práctica para agregar referencias de proyecto a un
proyecto. Después de ejecutar el comando, los elementos <ProjectReference> se agregan al archivo del
proyecto.

<ItemGroup>
<ProjectReference Include="app.csproj" />
<ProjectReference Include="..\lib2\lib2.csproj" />
<ProjectReference Include="..\lib1\lib1.csproj" />
</ItemGroup>

Argumentos
PROJECT

Especifica el archivo del proyecto. Si no se especifica, el comando busca uno en el directorio actual.
PROJECT_REFERENCES

Referencias entre proyectos (P2P) que se van a agregar. Especifique uno o más proyectos. El patrón glob
se admite en sistemas basados en Unix/Linux.

Opciones
-f|--framework <FRAMEWORK>

Agrega referencias de proyecto solo cuando apunta a un marco específico con el formato TFM.
-h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se detenga y espere la entrada o acción del usuario (se suele utilizar para
 completar la autenticación). Disponible desde el SDK de .NET Core 3.0.

Ejemplos
Agregar una referencia de proyecto:

dotnet add app/app.csproj reference lib/lib.csproj

Agregar varias referencias de proyecto al proyecto en el directorio actual:

dotnet add reference lib1/lib1.csproj lib2/lib2.csproj

Agregar varias referencias de proyecto usando el patrón global en Linux/Unix:

dotnet add app/app.csproj reference **/*.csproj

 dotnet list reference
02/11/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet list reference : enumera las referencias entre proyectos.

Sinopsis
dotnet list [<PROJECT>] reference

dotnet list -h|--help

Descripción
El comando dotnet list reference constituye una opción práctica para enumerar las referencias de proyecto de
un proyecto concreto.

Argumentos
PROJECT

El archivo del proyecto sobre el que actuar. Si no se especifica un archivo, el comando buscará uno en el
directorio actual.

Opciones
-h|--help

Imprime una corta ayuda para el comando.

Ejemplos
Enumerar las referencias del proyecto para el proyecto especificado:

dotnet list app/app.csproj reference

Enumerar las referencias del proyecto para el proyecto en el directorio actual:

dotnet list reference

 dotnet remove reference
04/05/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet remove reference : quita las referencias entre proyectos (P2P).

Sinopsis
dotnet remove [<PROJECT>] reference [-f|--framework <FRAMEWORK>]
<PROJECT_REFERENCES>

dotnet remove reference -h|--help

Descripción
El comando dotnet remove reference constituye una opción práctica para quitar referencias de proyecto de un
proyecto.

Argumentos
PROJECT

Archivo de proyecto de destino. Si no se especifica, el comando busca uno en el directorio actual.

PROJECT_REFERENCES

Referencias de proyecto a proyecto (P2P) que se van a quitar. Puede especificar uno o varios proyectos. Se admiten
patrones globales en terminales basados en Unix o Linux.

Opciones
-h|--help

Imprime una corta ayuda para el comando.

-f|--framework <FRAMEWORK>

Solo quita la referencia cuando el destino es un marco de trabajo específico con el formato TFM.

Ejemplos
Quitar una referencia de proyecto del proyecto especificado:

dotnet remove app/app.csproj reference lib/lib.csproj

Quitar varias referencias de proyecto del proyecto en el directorio actual:

 dotnet remove reference lib1/lib1.csproj lib2/lib2.csproj

Quitar varias referencias de proyecto con un patrón global en Unix/Linux:

dotnet remove app/app.csproj reference **/*.csproj`

 dotnet add package
18/12/2020 • 4 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

NOMBRE
dotnet add package : agrega una referencia de paquete a un archivo del proyecto.

Sinopsis
dotnet add [<PROJECT>] package <PACKAGE_NAME>
[-f|--framework <FRAMEWORK>] [--interactive]
[-n|--no-restore] [--package-directory <PACKAGE_DIRECTORY>]
[--prerelease] [-s|--source <SOURCE>] [-v|--version <VERSION>]

dotnet add package -h|--help

Descripción
El comando dotnet add package constituye una opción práctica para agregar una referencia de paquete a un
archivo del proyecto. Después de ejecutar el comando, existe una comprobación de compatibilidad para
garantizar que el paquete es compatible con los marcos del proyecto. Si se pasa la comprobación, un elemento
<PackageReference> se agrega al archivo del proyecto y dotnet restore se ejecuta.

Por ejemplo, si agrega Newtonsoft.Json a ToDo.csproj se producirá un resultado similar al del siguiente ejemplo:

Writing C:\Users\me\AppData\Local\Temp\tmp95A8.tmp
info : Adding PackageReference for package 'Newtonsoft.Json' into project 'C:\projects\ToDo\ToDo.csproj'.
log : Restoring packages for C:\Temp\projects\consoleproj\consoleproj.csproj...
info : GET https://api.nuget.org/v3-flatcontainer/newtonsoft.json/index.json
info : OK https://api.nuget.org/v3-flatcontainer/newtonsoft.json/index.json 79ms
info : GET https://api.nuget.org/v3-flatcontainer/newtonsoft.json/12.0.1/newtonsoft.json.12.0.1.nupkg
info : OK https://api.nuget.org/v3-flatcontainer/newtonsoft.json/12.0.1/newtonsoft.json.12.0.1.nupkg 232ms
log : Installing Newtonsoft.Json 12.0.1.
info : Package 'Newtonsoft.Json' is compatible with all the specified frameworks in project
'C:\projects\ToDo\ToDo.csproj'.
info : PackageReference for package 'Newtonsoft.Json' version '12.0.1' added to file
'C:\projects\ToDo\ToDo.csproj'.

El archivo ToDo.csproj contiene ahora un elemento <PackageReference> para el paquete al que hace referencia.

<PackageReference Include="Newtonsoft.Json" Version="12.0.1" />

Restauración implícita
No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan
que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test , dotnet publish y
dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los
sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore .

Argumentos
PROJECT

Especifica el archivo del proyecto. Si no se especifica, el comando busca uno en el directorio actual.
PACKAGE_NAME

La referencia de paquete que se va a agregar.

Opciones
-f|--framework <FRAMEWORK>

Agrega una referencia de paquete solo cuando se destina a un marco específico.

-h|--help

Imprime una corta ayuda para el comando.

--interactive

Permite que el comando se detenga y espere la entrada o acción del usuario (por ejemplo, completar la
autenticación). Disponible desde el SDK de .NET Core 2.1, versión 2.1.400 o posterior.
-n|--no-restore

Agrega una referencia de paquete sin realizar una vista previa de restauración y una comprobación de
compatibilidad.
--package-directory <PACKAGE_DIRECTORY>

Directorio donde quiere restaurar los paquetes. La ubicación predeterminada de restauración de paquetes
es %userprofile%\.nuget\packages en Windows y ~/.nuget/packages en macOS y Linux. Para obtener más
información, vea Administración de las carpetas de paquetes globales, de caché y temporales in NuGet.
--prerelease

Permite que se instalen paquetes de versión preliminar.

-s|--source <SOURCE>

URI del origen del paquete NuGet que se usará durante la operación de restauración.
-v|--version <VERSION>

Versión del paquete. Consulte NuGet package versioning (Control de versiones de paquetes NuGet).

Ejemplos
Agregar un paquete de NuGet Newtonsoft.Json a un proyecto:

dotnet add package Newtonsoft.Json

Agregar una versión específica de un paquete a un proyecto:

 dotnet add ToDo.csproj package Microsoft.Azure.DocumentDB.Core -v 1.0.0

Agregar un paquete con un origen de NuGet específico:

dotnet add package Microsoft.AspNetCore.StaticFiles -s https://dotnet.myget.org/F/dotnet-

core/api/v3/index.json

Vea también
Administración de las carpetas de paquetes globales, de caché y temporales en NuGet
Control de versiones de paquetes NuGet
 dotnet list package
18/12/2020 • 6 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.2 y versiones posteriores

NOMBRE
dotnet list package : muestra las referencias de paquete de un proyecto o una solución.

Sinopsis
dotnet list [<PROJECT>|<SOLUTION>] package [--config <SOURCE>]
[--deprecated]
[--framework <FRAMEWORK>] [--highest-minor] [--highest-patch]
[--include-prerelease] [--include-transitive] [--interactive]
[--outdated] [--source <SOURCE>] [-v|--verbosity <LEVEL>]

dotnet list package -h|--help

Descripción
El comando dotnet list package ofrece una opción práctica para mostrar todas las referencias de paquete de
NuGet de una solución o un proyecto específico. Primero deberá crear el proyecto para tener los recursos
necesarios para que este comando se procese. En el ejemplo siguiente se muestra la salida del comando
dotnet list package para el proyecto SentimentAnalysis:

Project 'SentimentAnalysis' has the following package references

[netcoreapp2.1]:
Top-level Package Requested Resolved
> Microsoft.ML 1.4.0 1.4.0
> Microsoft.NETCore.App (A) [2.1.0, ) 2.1.0

(A) : Auto-referenced package.

La columna Requested hace referencia a la versión de paquete especificada en el archivo del proyecto y puede ser
un intervalo. La columna Resolved muestra la versión que el proyecto usa actualmente y siempre se trata de un
valor único. Los paquetes que tienen (A) junto al nombre representan referencias implícitas de paquete que se
deducen de la configuración del proyecto (tipo de Sdk , propiedad <TargetFramework> o <TargetFrameworks> , etc.).
Use la opción --outdated para averiguar si hay disponibles más recientes de los paquetes que usa en los
proyectos. De manera predeterminada, --outdated muestra los paquetes estables más recientes, a menos que la
versión resuelta también sea una versión preliminar. Para incluir versiones preliminares cuando se muestren
versiones más recientes, especifique también la opción --include-prerelease . En los ejemplos siguientes se
muestra la salida del comando dotnet list package --outdated --include-prerelease para el mismo proyecto, tal
como en el ejemplo anterior:
 The following sources were used:
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Project `SentimentAnalysis` has the following updates to its packages

[netcoreapp2.1]:
Top-level Package Requested Resolved Latest
> Microsoft.ML 1.4.0 1.4.0 1.5.0-preview

Si tiene que averiguar si el proyecto tiene dependencias transitivas, use la opción --include-transitive . Las
dependencias transitivas se producen cuando se agrega un paquete al proyecto que, a su vez, se basa en otro
paquete. En el ejemplo siguiente se muestra la salida de la ejecución del comando
dotnet list package --include-transitive en el proyecto HelloPlugin, que muestra paquetes de nivel superior y los
paquetes de los que dependen:

Project 'HelloPlugin' has the following package references

[netcoreapp3.0]:
Transitive Package Resolved
> PluginBase 1.0.0

Argumentos
PROJECT | SOLUTION

El archivo de proyecto o solución donde se operará. Si no se especifica, el comando busca uno en el directorio
actual. Si se encuentra más de una solución o proyecto, se genera un error.

Opciones
--config <SOURCE>

Los orígenes de NuGet que se usarán al buscar paquetes más recientes. Requiere la opción --outdated .
--deprecated

Muestra los paquetes que han quedado en desuso.

--framework <FRAMEWORK>

Muestra solo los paquetes aplicables al marco de destino especificado. Para especificar varios marcos, repita
la opción varias veces. Por ejemplo: --framework netcoreapp2.2 --framework netstandard2.0 .
-h|--help

Imprime una corta ayuda para el comando.

--highest-minor

Considere solo los paquetes con un número de versión principal coincidente al buscar paquetes más
recientes. Requiere la opción --outdated o --deprecated .
--highest-patch

Considere solo los paquetes con número de versión principal y secundario coincidente al buscar paquetes
más recientes. Requiere la opción --outdated o --deprecated .
--include-prerelease

Considere los paquetes con versiones preliminares al buscar paquetes más recientes. Requiere la opción
 --outdated o --deprecated .
--include-transitive

Enumera los paquetes transitivos, además de los paquetes de nivel superior. Al especificar esta opción,
recibe una lista de paquetes de los que dependen los paquetes de nivel superior.
--interactive

Permite que el comando se detenga y espere una entrada o una acción del usuario. Por ejemplo, para
completar la autenticación. Disponible desde el SDK de .NET Core 3.0.
--outdated

Enumera los paquetes con versiones más recientes disponibles.

-s|--source <SOURCE>

Los orígenes de NuGet que se usarán al buscar paquetes más recientes. Requiere la opción --outdated o
--deprecated .

-v|--verbosity <LEVEL>

Establece el nivel de detalle de MSBuild. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] ,
d[etailed] y diag[nostic] . De manera predeterminada, es minimal .

Ejemplos
Muestre las referencias de paquete de un proyecto específico:

dotnet list SentimentAnalysis.csproj package

Muestre las referencias de paquete que tienen versiones más recientes disponibles, incluidas versiones
preliminares:

dotnet list package --outdated --include-prerelease

Muestre las referencias de paquete para un marco de destino específico:

dotnet list package --framework netcoreapp3.0

 dotnet remove package
18/12/2020 • 2 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.x y versiones posteriores

Name
dotnet remove package : quita la referencia de paquete de un archivo de proyecto.

Sinopsis
dotnet remove [<PROJECT>] package <PACKAGE_NAME>

dotnet remove package -h|--help

Description
El comando dotnet remove package constituye una opción práctica para quitar una referencia de paquete NuGet
de un proyecto.

Argumentos
PROJECT

Especifica el archivo del proyecto. Si no se especifica, el comando busca uno en el directorio actual.
PACKAGE_NAME

La referencia de paquete que hay que quitar.

Opciones
-h|--help

Imprime una corta ayuda para el comando.

Ejemplos
Quite el paquete NuGet Newtonsoft.Json de un proyecto en el directorio actual:

dotnet remove package Newtonsoft.Json

 Información general de global.json
18/12/2020 • 21 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.0 y versiones posteriores
El archivo global.json permite definir qué versión del SDK de .NET se usa al ejecutar comandos de la CLI de .NET.
La selección del SDK de .NET es independiente de especificar el entorno de ejecución al que está destinado el
proyecto. La versión del SDK de .NET indica qué versiones de la CLI de .NET se usan.
En general, se quiere usar la versión más reciente de las herramientas del SDK, por lo que no es necesario ningún
archivo global.json. En algunos escenarios avanzados, es posible que quiera controlar la versión de las
herramientas del SDK, así que en este artículo se explica cómo.
Para obtener más información sobre cómo especificar el runtime en su lugar, vea Plataformas de destino.
El SDK de .NET busca un archivo global.json en el directorio de trabajo actual (que no es necesariamente el
mismo que el directorio del proyecto) o en uno de sus directorios principales.

Esquema de global.JSON
sdk
Tipo: object

Especifica información sobre el SDK de .NET que se va a seleccionar.

version
Tipo: string

Disponible a partir del SDK de .NET Core 1.0.

La versión del SDK de .NET que se va a usar.
Este campo:
No admite caracteres comodín, es decir, se debe especificar el número de versión completo.
No admite intervalos de versiones.
allowPrerelease
Tipo: boolean

Disponible a partir del SDK de .NET Core 3.0.

Indica si la resolución del SDK debe tener en cuenta las versiones preliminares a la hora de seleccionar la versión
del SDK que se va a usar.
Si no se establece este valor de forma explícita, el valor predeterminado depende de si se está ejecutando desde
Visual Studio:
Si no se está en Visual Studio, el valor predeterminado es true .
Si se está en Visual Studio, se usa el estado de versión preliminar solicitado. Es decir, si se usa una versión
preliminar de Visual Studio o se establece la opción Usar versiones preliminares del SDK de .NET Core
(en Herramientas > Opciones > Entorno > Características en versión preliminar ), el valor
predeterminado es true ; de lo contrario, false .
rollForward
 Tipo: string

Disponible a partir del SDK de .NET Core 3.0.

Directiva de puesta al día que se va a usar al seleccionar una versión del SDK, ya sea como reserva si falta una
versión específica del SDK o como una directiva para usar una versión superior. Se debe especificar una versión
con un valor rollForward , a menos que se esté estableciendo en latestMajor . El comportamiento
predeterminado de puesta al día lo determinan las reglas de coincidencia.
Para comprender las directivas disponibles y su comportamiento, tenga en cuenta las siguientes definiciones de
una versión del SDK en el formato x.y.znn :
x es la versión principal.
y es la versión secundaria.
z es la banda de características.
nn es la versión de la revisión.

En la siguiente tabla se muestran los posibles valores de la clave rollForward :

VA LO R C O M P O RTA M IEN TO

patch Usa la versión especificada.

Si no se encuentra, se pone al día hasta el nivel de revisión
más reciente.
Si no se encuentra, se produce un error.

Este valor es el comportamiento heredado de las versiones

anteriores del SDK.

feature Usa el nivel de revisión más reciente para las versiones

principal y secundaria y la banda de características
especificadas.
Si no se encuentra, se pone al día hasta la siguiente banda de
características superior dentro de la misma versión
principal/secundaria y usa el nivel de revisión más reciente
para esa banda de características.
Si no se encuentra, se produce un error.

minor Usa el nivel de revisión más reciente para las versiones

principal y secundaria y la banda de características
especificadas.
Si no se encuentra, se pone al día hasta la siguiente banda de
características superior dentro de la misma versión
principal/secundaria y usa el nivel de revisión más reciente
para esa banda de características.
Si no se encuentra, se pone al día hasta la siguiente versión
secundaria y banda de características superiores dentro de la
misma versión principal y usa el nivel de revisión más reciente
para esa banda de características.
Si no se encuentra, se produce un error.
 VA LO R C O M P O RTA M IEN TO

major Usa el nivel de revisión más reciente para las versiones

principal y secundaria y la banda de características
especificadas.
Si no se encuentra, se pone al día hasta la siguiente banda de
características superior dentro de la misma versión
principal/secundaria y usa el nivel de revisión más reciente
para esa banda de características.
Si no se encuentra, se pone al día hasta la siguiente versión
secundaria y banda de características superiores dentro de la
misma versión principal y usa el nivel de revisión más reciente
para esa banda de características.
Si no se encuentra, se pone al día hasta la siguiente versión
principal, secundaria y banda de características superiores y
usa el nivel de revisión más reciente para esa banda de
características.
Si no se encuentra, se produce un error.

latestPatch Usa el nivel de revisión instalado más reciente que coincide

con la versión principal, secundaria y banda de características
solicitadas con un nivel de revisión y que es mayor o igual
que el valor especificado.
Si no se encuentra, se produce un error.

latestFeature Usa la banda de características instalada superior y el nivel de

revisión que coincide con la versión principal y secundaria
solicitados con una banda de características y un nivel de
revisión que es mayor o igual que el valor especificado.
Si no se encuentra, se produce un error.

latestMinor Usa la versión secundaria y la banda de características

instalados superiores y la versión de revisión que coincide con
la versión principal solicitada con una versión secundaria que
es mayor o igual que el valor especificado.
Si no se encuentra, se produce un error.

latestMajor Usa el SDK de .NET más reciente que haya instalado con una
versión que es mayor o igual que el valor especificado.
Si no se encuentra, se produce un error.

disable No se pone al día. Se requiere una coincidencia exacta.

msbuild-sdks
Tipo: object
Permite controlar la versión del SDK del proyecto en un lugar, en vez de hacerlo en cada proyecto individual. Para
más información, vea Resolución de los SDK de proyecto.

Ejemplos
En el ejemplo siguiente se muestra cómo no usar versiones preliminares:

{
"sdk": {
"allowPrerelease": false
}
}
En este ejemplo se muestra cómo usar la versión superior instalada que es mayor o igual que la versión
especificada. El JSON mostrado no permite ninguna versión del SDK anterior a 2.2.200 y permite 2.2.200 o
cualquier versión posterior, incluidos 3.0.xxx y 3.1.xxx.

{
"sdk": {
"version": "2.2.200",
"rollForward": "latestMajor"
}
}

En el ejemplo siguiente se muestra cómo usar la versión exacta especificada:

{
"sdk": {
"version": "3.1.100",
"rollForward": "disable"
}
}

En este ejemplo se muestra cómo usar la versión de revisión y banda de características más reciente instalada de
una versión principal y secundaria concreta. El JSON mostrado no permite ninguna versión del SDK anterior a
3.1.102 y permite 3.1.102 o cualquier versión 3.1.xxx posterior, como 3.1.103 o 3.1.200.

{
"sdk": {
"version": "3.1.102",
"rollForward": "latestFeature"
}
}

En este ejemplo se muestra cómo usar la versión de revisión superior instalada de una versión específica. El JSON
mostrado no permite ninguna versión del SDK anterior a 3.1.102 y permite 3.1.102 o cualquier versión 3.1.1xx
posterior, como 3.1.103 o 3.1.199.

{
"sdk": {
"version": "3.1.102",
"rollForward": "latestPatch"
}
}

global.json y la CLI de .NET

Resulta útil saber qué versiones del SDK están instaladas en el equipo con el fin de establecer una en el archivo
global.json. Para obtener más información sobre cómo hacerlo, vea Cómo comprobar que .NET Core ya está
instalado.
Para instalar otras versiones del SDK de .NET en el equipo, visite la página de descargas de .NET Core.
Puede crear un archivo global.json en el directorio actual mediante la ejecución del comando dotnet new, similar
al ejemplo siguiente:

dotnet new globaljson --sdk-version 3.0.100

Reglas de coincidencia
NOTE
Las reglas de coincidencia se rigen por el punto de entrada de dotnet.exe , que es común en todos los entornos de
ejecución instalados de .NET. Se usan las reglas de coincidencia de la última versión instalada del entorno de ejecución de
.NET cuando se tienen varios instalados en paralelo o si usa un archivo global.json.

.NET Core 3.x

.NET Core 2.x
A partir de .NET Core 3.0, se aplican las reglas siguientes al determinar qué versión del SDK se va a usar:
Si no se encuentra ningún archivo global.json o en global.json no se especifica una versión del SDK ni un
valor allowPrerelease , se usa la versión del SDK instalada más reciente (lo que equivale a establecer
rollForward en latestMajor ). El que se consideren o no las versiones preliminares del SDK depende de
cómo se invoque a dotnet .
Si no se está en Visual Studio, se tienen en cuenta las versiones preliminares.
Si se está en Visual Studio, se usa el estado de versión preliminar solicitado. Es decir, si se usa una
versión preliminar de Visual Studio o se establece la opción Usar versiones preliminares del SDK
de .NET Core (en Herramientas > Opciones > Entorno > Características en versión
preliminar ), se tienen en cuenta las versiones preliminares; de lo contrario, solo se consideran las
versiones publicadas.
Si se encuentra un archivo global.json que no especifica una versión del SDK pero sí un valor
allowPrerelease , se usa la versión del SDK instalada superior (lo que equivale a establecer rollForward
en latestMajor ). El que la versión más reciente del SDK pueda ser publicada o preliminar, depende del
valor de allowPrerelease . true indica que se tienen en cuenta las versiones preliminares; false indica
que solo se tienen en cuenta las versiones publicadas.
Si se encuentra un archivo global.json y especifica una versión del SDK:
Si no hay ningún valor rollForward establecido, se usa latestPatch como directiva de rollForward
predeterminada. De lo contrario, vea cada valor y su comportamiento en la sección rollForward.
En la sección allowPrerelease se explica si se tienen en cuenta las versiones preliminares y cuál es el
comportamiento predeterminado cuando allowPrerelease no está establecido.

Solución de problemas de advertencias de compilación

La advertencia siguiente indica que el proyecto se ha compilado con una versión preliminar del SDK de
.NET Core:

Trabaja con una versión preliminar del SDK de .NET Core. Puede definir la versión del SDK a través de
un archivo global.json en el proyecto actual. Más información en https://go.microsoft.com/fwlink/?
linkid=869452.

Las versiones del SDK de .NET Core tienen un historial y el compromiso de ser de alta calidad. Pero si no
quiere usar una versión preliminar, vea las distintas estrategias que puede aplicar con el SDK de .NET Core
3.0 o una versión posterior en la sección allowPrerelease. En el caso de los equipos que nunca han tenido
instalado un SDK o un runtime de .NET Core 3.0 o superior, debe crear un archivo global.json y especificar
la versión exacta que quiere usar.
La advertencia siguiente indica que el proyecto tiene como destino EF Core 1.0 ó 1.1, que no es compatible
 con el SDK de .NET Core 2.1 y versiones posteriores:

El proyecto de inicio "{proyectoDeInicio}" está destinado a la versión "{versiónPlataformaDeDestino}"

de ".NETCoreApp". Esta versión de las herramientas de línea de comandos de Entity Framework Core
.NET solo admite la versión 2.0 o superior. Para obtener información sobre el uso de versiones
anteriores de las herramientas, vea https://go.microsoft.com/fwlink/?linkid=871254.

A partir del SDK de .NET Core 2.1 (versión 2.1.300), el comando dotnet ef se incluye en el SDK. Para
compilar el proyecto, instale el SDK de .NET Core 2.0 (versión 2.1.201) o versiones anteriores en el equipo
y defina la versión del SDK deseada mediante el archivo global.json. Para obtener más información sobre
el comando dotnet ef , vea EF Core .NET Command-line Tools (Herramientas de línea de comandos de EF
Core .NET).

Vea también
Resolución de los SDK de proyecto
 Telemetría del SDK de .NET
18/12/2020 • 10 minutes to read • Edit Online

El SDK de .NET incluye una característica de telemetría que recopila datos de uso e información de excepciones
cuando se bloquea la CLI de .NET. La CLI de .NET se incluye en el SDK de .NET y es el conjunto de verbos que
permiten compilar, probar y publicar las aplicaciones de .NET. Es importante que el equipo de .NET entienda cómo
se usan las herramientas con el fin de mejorarlas. Con la información sobre los errores, el equipo consigue resolver
problemas y corregir errores.
Los datos recopilados se publican de forma agregada bajo la licencia de atribución de Creative Commons.

Ámbito
dotnet tiene dos funciones: ejecutar aplicaciones y ejecutar comandos de la CLI. La telemetría no se recopila
cuando se usa dotnet para iniciar una aplicación con el siguiente formato:
dotnet [path-to-app].dll

La telemetría se recopila cuando se usa cualquiera de los comandos de la CLI de .NET, como:
dotnet build
dotnet pack
dotnet run

Cómo desactivar la característica

La característica de telemetría del SDK de .NET está habilitada de manera predeterminada. Para desactivar la
característica de telemetría, establezca la variable de entorno DOTNET_CLI_TELEMETRY_OPTOUT en 1 o true .
El instalador del SDK de .NET también envía una única entrada de telemetría cuando se produce una instalación
correcta. Para no participar, establezca la variable de entorno DOTNET_CLI_TELEMETRY_OPTOUT antes de instalar el SDK
de .NET.

Divulgación
El SDK de .NET muestra texto similar al siguiente cuando se ejecuta por primera vez uno de los comandos de la CLI
de .NET (por ejemplo, dotnet build ). El texto puede variar ligeramente según la versión del SDK que ejecute. Esta
experiencia de "primera vista" es la forma en que Microsoft le notifica sobre la recopilación de datos.

Telemetry
---------
The .NET tools collect usage data in order to help us improve your experience. The data is collected by
Microsoft and shared with the community. You can opt-out of telemetry by setting the
DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

Para deshabilitar este mensaje y el de bienvenida de .NET, establezca la variable de entorno DOTNET_NOLOGO en
true . Tenga en cuenta que esta variable no tiene ningún efecto sobre la exclusión de la telemetría.

Puntos de datos
La característica de telemetría no recopila datos personales, como direcciones de correo electrónico o nombres de
usuario. No examina el código ni extrae datos de nivel de proyecto, como el nombre, el repositorio o el autor. Los
datos se envían de forma segura a los servidores de Microsoft con tecnología de Azure Monitor, se conservan bajo
acceso restringido y se publican bajo controles de seguridad estrictos de sistemas seguros de Azure Storage.
La protección de su privacidad es importante para nosotros. Si sospecha que la telemetría está recopilando datos
confidenciales o que los datos se están tratando de forma no segura o inapropiada, informe de un problema en el
repositorio de dotnet/cli o envíenos un correo electrónico a [email protected] para que lo investiguemos.
La característica de telemetría recopila los siguientes datos:

VERSIO N ES DEL SDK DATO S

Todas Marca de tiempo de la invocación.

Todas Comando invocado (por ejemplo, "build"), con hash a partir de

2.1.

Todas Dirección IP de tres octetos usada para determinar la

ubicación geográfica.

Todas Sistema operativo y versión.

Todas Identificador de tiempo de ejecución (RID) en el que se ejecuta

el SDK.

Todas Versión del SDK de .NET.

Todas Perfil de telemetría: valor opcional usado internamente en

Microsoft y que solo se usa con la participación explícita del
usuario.

>=2.0 Opciones y argumentos del comando: se recopilan varias

opciones y argumentos (no cadenas arbitrarias). Vea opciones
recopiladas. Con hash a partir de la versión 2.1.300.

>=2.0 Si el SDK se ejecuta en un contenedor.

>=2.0 Plataformas de destino (desde el evento TargetFramework ),

con hash a partir de 2.1.

>=2.0 Dirección de Media Access Control (MAC) con hash (SHA256).

>=2.0 Directorio de trabajo actual con hash.

>=2.0 Informe de instalación correcta, con el nombre de archivo exe

del instalador con hash.

>=2.1.300 Versión de kernel.

>=2.1.300 Versión/versión de libc.

>=3.0.100 Indica si la salida se redirigió (true o false).

 VERSIO N ES DEL SDK DATO S

>=3.0.100 En un bloqueo de CLI/SDK, el tipo de excepción y su

seguimiento de pila (solo el código de CLI/SDK se incluye en el
seguimiento de la pila enviado). Para obtener más información,
vea Telemetría de la excepción de bloqueo de SDK/CLI de .NET
Core recopilada.

Opciones recopiladas
Determinados comandos envían datos adicionales. Un subconjunto de comandos envía el primer argumento:

C O M A N DO DATO S DEL P RIM ER A RGUM EN TO EN VIA DO S

dotnet help <arg> Se está consultando la ayuda del comando.

dotnet new <arg> Nombre de la plantilla (con hash).

dotnet add <arg> La palabra package o reference .

dotnet remove <arg> La palabra package o reference .

dotnet list <arg> La palabra package o reference .

dotnet sln <arg> La palabra add , list o remove .

dotnet nuget <arg> La palabra delete , locals o push .

Un subconjunto de comandos envía las opciones seleccionadas, si se usan, junto con sus valores:

O P C IÓ N C O M A N DO S

--verbosity Todos los comandos

--language dotnet new

--configuration dotnet build , dotnet clean , dotnet publish ,

dotnet run , dotnet test

--framework dotnet build , dotnet clean , dotnet publish ,

dotnet run , dotnet test , dotnet vstest

--runtime dotnet build , dotnet publish

--platform dotnet vstest

--logger dotnet vstest

--sdk-package-version dotnet migrate

A excepción de --verbosity y --sdk-package-version , se aplica un algoritmo hash a los demás valores a partir del
SDK de .NET Core 2.1.100.
Telemetría de la excepción de bloqueo de SDK/CLI de .NET Core
recopilada
Si se bloquea el SDK o la CLI de .NET, se recopilan el nombre de la excepción y el seguimiento de la pila del código
de la CLI o el SDK. Esta información se recopila para evaluar los problemas y mejorar la calidad del SDK y la CLI de
.NET. En este artículo se proporciona información sobre los datos que se recopilan. También se ofrecen sugerencias
para que los usuarios que compilan una versión propia del SDK de .NET eviten la divulgación involuntaria de
información personal o confidencial.
Tipos de datos recopilados
La CLI de .NET solo recopila información de las excepciones de la CLI o el SDK, no de las excepciones de la
aplicación. Los datos recopilados contienen el nombre de la excepción y el seguimiento de la pila. Este seguimiento
de la pila es del código de CLI/SDK.
En este ejemplo se muestra el tipo de datos que se recopilan:

System.IO.IOException
at System.ConsolePal.WindowsConsoleStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
at System.IO.StreamWriter.Write(Char[] buffer)
at System.IO.TextWriter.WriteLine()
at System.IO.TextWriter.SyncTextWriter.WriteLine()
at Microsoft.DotNet.Cli.Utils.Reporter.WriteLine()
at Microsoft.DotNet.Tools.Run.RunCommand.EnsureProjectIsBuilt()
at Microsoft.DotNet.Tools.Run.RunCommand.Execute()
at Microsoft.DotNet.Tools.Run.RunCommand.Run(String[] args)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)

Evasión de la divulgación involuntaria de información

Los colaboradores de .NET y cualquier otro usuario que ejecute una versión del SDK de .NET compilada por ellos
mismos deben tener en cuenta la ruta de acceso al código fuente del SDK. Si se produce un bloqueo mientras se
usa un SDK de .NET que es una compilación de depuración personalizada o está configurado con archivos de
símbolos de compilación personalizados, la ruta de acceso del archivo de origen del SDK desde el equipo de
compilación se recopila como parte del seguimiento de la pila y no tiene un algoritmo hash.
Por este motivo, las compilaciones personalizadas del SDK de .NET no se deben almacenar en directorios cuyos
nombres de ruta de acceso expongan información personal o confidencial.

Vea también
Datos de telemetría de la CLI de .NET
Fuente de referencia de telemetría (repositorio dotnet/sdk)
 Acceso con privilegios elevados para comandos de
dotnet
18/12/2020 • 8 minutes to read • Edit Online

Los procedimientos recomendados de desarrollo de software sirven de guía a los desarrolladores para escribir
software que requiera la menor cantidad de privilegios. Sin embargo, algunos programas, como las herramientas
de supervisión de rendimiento, requieren permiso del administrador debido a las reglas del sistema operativo. En
las siguientes instrucciones se describen los escenarios admitidos para escribir dicho software con .NET Core.
Los siguientes comandos se pueden ejecutar con privilegios elevados:
Comandos dotnet tool , como dotnet tool install.
dotnet run --no-build
dotnet-core-uninstall

No se recomienda ejecutar otros comandos con privilegios elevados. En concreto, no se recomienda usar
privilegios elevados con los comandos que usa MSBuild, como dotnet restore, dotnet build y dotnet run. Los
problemas de administración de permisos son el principal problema cuando un usuario cambia varias veces entre
una cuenta restringida y otra raíz después de emitir comandos de dotnet. Como usuario restringido, es posible que
no tenga acceso al archivo generado por un usuario raíz. Hay maneras de resolver esta situación, pero, para
empezar, no es necesario que surjan.
Puede ejecutar comandos como raíz siempre y cuando no cambie repetidas veces entre la raíz y una cuenta
restringida. Por ejemplo, los contenedores de Docker se ejecutan como raíz de forma predeterminada, por lo que
tienen esta característica.

Instalación de herramienta global

En las instrucciones siguientes se muestra la manera recomendada de instalar, ejecutar y desinstalar las
herramientas de .NET que necesitan privilegios elevados para ejecutarse.
Windows
Linux
macOS
Instalación de la herramienta
Si la carpeta %ProgramFiles%\dotnet-tools ya existe, siga este procedimiento para comprobar si el grupo "Usuarios"
tiene permiso para escribir o modificar ese directorio:
Haga clic con el botón derecho en la carpeta %ProgramFiles%\dotnet-tools y seleccione Propiedades . Se abrirá
el cuadro de diálogo Propiedades comunes .
Seleccione la pestaña Seguridad . En Nombres de grupos o usuarios , compruebe si el grupo "Usuarios"
tiene permiso para escribir o modificar el directorio.
Si el grupo "Usuarios" puede escribir o modificar el directorio, al instalar las herramientas, use otro nombre de
directorio de dotnet-tools.
Para instalar las herramientas, ejecute el siguiente comando en un símbolo del sistema con privilegios elevados.
Creará la carpeta dotnet-tools durante la instalación.
 dotnet tool install PACKAGEID --tool-path "%ProgramFiles%\dotnet-tools".

Ejecución de la herramienta global

Opción 1 Use la ruta de acceso completa con privilegios elevados:

"%ProgramFiles%\dotnet-tools\TOOLCOMMAND"

Opción 2 Agregue la carpeta recién creada a %Path% . Solo necesita realizar esta operación una vez.

setx Path "%Path%;%ProgramFiles%\dotnet-tools\"

Y ejecute con:

TOOLCOMMAND

Desinstalación de la herramienta global

En un símbolo del sistema con privilegios elevados, escriba el siguiente comando:

dotnet tool uninstall PACKAGEID --tool-path "%ProgramFiles%\dotnet-tools"

Herramientas locales
Las herramientas locales se limitan al árbol de subdirectorio, por usuario. Cuando se ejecutan con privilegios
elevados, las herramientas locales comparten un entorno de usuario con privilegios restringidos en el entorno con
privilegios elevados. En Linux y macOS, esto da como resultado archivos que establecen con acceso de solo usuario
raíz. Si el usuario cambia a una cuenta restringida, el usuario ya no podrá acceder a los archivos ni escribir en ellos.
Por tanto, no se recomienda instalar las herramientas que necesiten permisos elevados como herramientas locales.
En su lugar, use la opción --tool-path y las instrucciones anteriores para las herramientas globales.

Elevación durante el desarrollo

Durante el desarrollo, puede que necesite acceso con privilegios elevados para probar la aplicación. Este escenario
es común para las aplicaciones de IoT, por ejemplo. Se recomienda que compile la aplicación sin la elevación y, a
continuación, la ejecute con privilegios elevados. Hay unos pocos patrones, como los siguientes:
Uso de archivo ejecutable generado (proporciona el mejor rendimiento de inicio):

dotnet build
sudo ./bin/Debug/netcoreapp3.0/APPLICATIONNAME

Mediante el comando dotnet run con la marca —no-build para evitar que se generen nuevos archivos
binarios:

dotnet build
sudo dotnet run --no-build

Vea también
Información general sobre las herramientas de .NET
 Procedimiento para habilitar la finalización con
tabulación para la CLI de .NET
18/12/2020 • 3 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores
En este artículo se describe cómo configurar la finalización con tabulación para tres shells: PowerShell, Bash y zsh.
En el caso de otros shells, consulte la documentación para saber cómo configurar la finalización con tabulación.
Una vez que se ha configurado, para desencadenar la finalización con tabulación para la CLI de .NET, escriba un
comando dotnet en el shell y, después, presione el tabulador. La línea de comandos que se envía al comando
dotnet complete y los resultados se procesan mediante el shell. Puede probar los resultados sin habilitar la
finalización con tabulación si envía algo directamente al comando dotnet complete . Por ejemplo:

> dotnet complete "dotnet a"

add
clean
--diagnostics
migrate
pack

Si ese comando no funciona, asegúrese de que está instalado el SDK de .NET Core 2.0 o una versión superior. Si
está instalado, pero el comando sigue sin funcionar, asegúrese de que dotnet se resuelva como mínimo en la
versión 2.0 del SDK de .NET Core. Use el comando dotnet --version para ver en qué versión de dotnet se
resuelve la ruta de acceso actual. Para obtener más información, vea Selección de la versión de .NET Core que se va
a usar.
Ejemplos
Estos son algunos ejemplos de lo que proporciona la finalización con tabulación:

EN T RA DA SE C O N VIERT E EN P O RQ UE

dotnet a ⇥ dotnet add add es el primer subcomando, por

orden alfabético.

dotnet add p ⇥ dotnet add --help La finalización con tabulación hace

coincidir las subcadenas y --help
aparece primero alfabéticamente.

dotnet add p ⇥⇥ dotnet add package Al presionar la tecla Tab una segunda
vez aparece la siguiente sugerencia.

dotnet add package Microsoft ⇥ dotnet add package Los resultados se devuelven por orden
Microsoft.ApplicationInsights.Web alfabético.

dotnet remove reference ⇥ dotnet remove reference La finalización con tabulación es

..\..\src\OmniSharp.DotNet\OmniSharp.DotNet.csproj
compatible con archivos de proyecto.

PowerShell
Para agregar finalización con tabulación a PowerShell para la CLI de .NET, cree o edite el perfil almacenado en la
variable $PROFILE . Para obtener más información, vea Cómo crear el perfil y Los perfiles y la directiva de ejecución.
Agregue el código siguiente al perfil:

# PowerShell parameter completion shim for the dotnet CLI

Register-ArgumentCompleter -Native -CommandName dotnet -ScriptBlock {
param($commandName, $wordToComplete, $cursorPosition)
dotnet complete --position $cursorPosition "$wordToComplete" | ForEach-Object {
[System.Management.Automation.CompletionResult]::new($_, $_, 'ParameterValue', $_)
}
}

Bash
Para agregar finalización con tabulación al shell de bash para la CLI de .NET, agregue el código siguiente al archivo
.bashrc :

# bash parameter completion for the dotnet CLI

_dotnet_bash_complete()
{
local word=${COMP_WORDS[COMP_CWORD]}

local completions
completions="$(dotnet complete --position "${COMP_POINT}" "${COMP_LINE}" 2>/dev/null)"
if [ $? -ne 0 ]; then
completions=""
fi

COMPREPLY=( $(compgen -W "$completions" -- "$word") )

}

complete -f -F _dotnet_bash_complete dotnet

zsh
Para agregar finalización con tabulación al shell de zsh para la CLI de .NET, agregue el código siguiente al archivo
.zshrc :

# zsh parameter completion for the dotnet CLI

_dotnet_zsh_complete()
{
local completions=("$(dotnet complete "$words")")

reply=( "${(ps:\n:)completions}" )
}

compctl -K _dotnet_zsh_complete dotnet

 Uso del SDK y herramientas de .NET en la
integración continua (CI)
18/12/2020 • 15 minutes to read • Edit Online

En este documento se describen el uso del SDK de .NET y sus herramientas en un servidor de compilación. El
conjunto de herramientas de .NET funciona tanto de manera interactiva, donde un desarrollador escribe
comandos en un símbolo del sistema, como de manera automática, donde un servidor de integración continua
(CI) ejecuta un script de compilación. Los comandos, las opciones, las entradas y las salidas son los mismos, y solo
lo que el usuario especifica sirve para adquirir las herramientas y un sistema para compilar la aplicación. Este
documento se centra en escenarios de adquisición de herramientas de integración continua, donde además se
ofrecen recomendaciones sobre cómo diseñar y estructurar los scripts de compilación.

Opciones de instalación para los servidores de compilación de CI

Uso de instaladores nativos
Los instaladores nativos están disponibles para macOS, Linux y Windows. Los instaladores requieren acceso de
administrador (sudo) para el servidor de compilación. El instalador nativo ofrece la ventaja de que instala todas las
dependencias nativas necesarias para la ejecución de las herramientas. Además, los instaladores nativos instalan el
SDK en todo el sistema.
Los usuarios de macOS deben usar los instaladores PKG. En Linux, se ofrece la posibilidad de usar un
administrador de paquetes basado en fuentes, como apt-get para Ubuntu o yum para CentOS, o de usar los
mismos paquetes (DEB o RPM). En Windows, utilice el instalador MSI.
Los archivos binarios estables más recientes se encuentran en Descargas de .NET. Si desea utilizar las
herramientas de la última versión preliminar, que posiblemente sean inestables, use los vínculos proporcionados
en el repositorio de GitHub dotnet/core-sdk. Para las distribuciones de Linux, se encuentran disponibles los
archivos tar.gz (conocidos también como tarballs ); use los scripts de instalación dentro de los archivos para
instalar .NET Core.
Uso del script del instalador
El uso del script del instalador permite la instalación sin derechos administrativos en el servidor de compilación y
una sencilla automatización para obtener las herramientas. El script se encarga de descargar las herramientas y
extraerlas en una ubicación predeterminada o especificada para su uso. También puede especificar la versión de
las herramientas que desea instalar y si prefiere instalar el SDK completo o solo el runtime compartido.
El script del instalador se puede automatizar para que se ejecute al principio de la compilación, a fin de obtener e
instalar la versión deseada del SDK. La versión deseada se corresponde con cualquier versión del SKD que los
proyectos necesitan para la compilación. El script permite instalar el SDK en un directorio local del servidor,
ejecutar las herramientas desde la ubicación de instalación y limpiar después de la compilación, o bien dejar que el
servicio de CI realice dicha limpieza. Esto permite encapsular y aislar todo el proceso de compilación. La referencia
del script de instalación se encuentra en el artículo dotnet-install.

NOTE
Azure DevOps Ser vices
Cuando se utiliza el script del instalador, las dependencias nativas no se instalan automáticamente. Debe instalarlas en caso
de el sistema operativo no las incluya. Para obtener más información, vea Dependencias y requisitos de .NET.
Ejemplos de configuración de CI
En esta sección se explica un procedimiento de instalación manual con un script de PowerShell o de Bash, además
de incluir una descripción de varias soluciones de CI de software como servicio (SaaS). Las soluciones de CI de
SaaS tratadas son Travis CI, AppVeyor y Azure Pipelines.
Instalación manual
Cada servicio de SaaS tiene sus propios métodos para crear y configurar un proceso de compilación. Si usa una
solución de SaaS distinta a las que indican o necesita realizar alguna personalización aparte de la compatibilidad
preconfigurada, debe realizar al menos alguna configuración manual.
En general, para realizar una instalación manual, es necesario que adquiera una versión de las herramientas o las
últimas compilaciones nocturnas de las herramientas y que, después, ejecute el script de compilación. Puede usar
un script de PowerShell o bash para orquestar los comandos de .NET, o bien utilizar un archivo del proyecto en el
que se describa el proceso de compilación. En la sección de orquestación se ofrece más información sobre estas
opciones.
Después de crear un script que realiza una instalación manual del servidor de compilación de CI, úselo en el
equipo de desarrollo para compilar el código de forma local con fines de pruebas. Cuando confirme que el script
se ejecuta de forma correcta en el entorno local, impleméntelo en el servidor de compilación de CI. Un script de
PowerShell relativamente sencillo demuestra cómo obtener el SDK de .NET e instalarlo en un servidor de
compilación de Windows:
 $ErrorActionPreference="Stop"
$ProgressPreference="SilentlyContinue"

# $LocalDotnet is the path to the locally-installed SDK to ensure the

# correct version of the tools are executed.
$LocalDotnet=""
# $InstallDir and $CliVersion variables can come from options to the
# script.
$InstallDir = "./cli-tools"
$CliVersion = "1.0.1"

# Test the path provided by $InstallDir to confirm it exists. If it

# does, it's removed. This is not strictly required, but it's a
# good way to reset the environment.
if (Test-Path $InstallDir)
{
rm -Recurse $InstallDir
}
New-Item -Type "directory" -Path $InstallDir

Write-Host "Downloading the CLI installer..."

# Use the Invoke-WebRequest PowerShell cmdlet to obtain the

# installation script and save it into the installation directory.
Invoke-WebRequest `
-Uri "https://dot.net/v1/dotnet-install.ps1" `
-OutFile "$InstallDir/dotnet-install.ps1"

Write-Host "Installing the CLI requested version ($CliVersion) ..."

# Install the SDK of the version specified in $CliVersion into the

# specified location ($InstallDir).
& $InstallDir/dotnet-install.ps1 -Version $CliVersion `
-InstallDir $InstallDir

Write-Host "Downloading and installation of the SDK is complete."

# $LocalDotnet holds the path to dotnet.exe for future use by the

# script.
$LocalDotnet = "$InstallDir/dotnet"

# Run the build process now. Implement your build script here.

Debe proporcionar la implementación para el proceso de compilación al final del script. El script adquiere las
herramientas y, después, ejecuta el proceso de compilación. En los equipos UNIX, el siguiente script de Bash realiza
las acciones descritas en el script de PowerShell de forma similar:
 #!/bin/bash
INSTALLDIR="cli-tools"
CLI_VERSION=1.0.1
DOWNLOADER=$(which curl)
if [ -d "$INSTALLDIR" ]
then
rm -rf "$INSTALLDIR"
fi
mkdir -p "$INSTALLDIR"
echo Downloading the CLI installer.
$DOWNLOADER https://dot.net/v1/dotnet-install.sh > "$INSTALLDIR/dotnet-install.sh"
chmod +x "$INSTALLDIR/dotnet-install.sh"
echo Installing the CLI requested version $CLI_VERSION. Please wait, installation may take a few minutes.
"$INSTALLDIR/dotnet-install.sh" --install-dir "$INSTALLDIR" --version $CLI_VERSION
if [ $? -ne 0 ]
then
echo Download of $CLI_VERSION version of the CLI failed. Exiting now.
exit 0
fi
echo The CLI has been installed.
LOCALDOTNET="$INSTALLDIR/dotnet"
# Run the build process now. Implement your build script here.

Travis CI
Puede configurar Travis CI para instalar el SDK de .NET con el lenguaje csharp y la clave dotnet . Para más
información, consulte los documentos oficiales de Travis CI en Building a C#, F#, or Visual Basic Project
(Compilación de un proyecto de C#, F# o Visual Basic). Al acceder a la información de Travis CI, observará que el
identificador de lenguaje language: csharp de cuyo mantenimiento se encarga la comunidad funciona con todos
los lenguajes de .NET, incluidos F# y Mono.
Travis CI se ejecuta tanto en trabajos de macOS como de Linux en una matriz de compilación, donde debe
especificar una combinación de runtime, entorno y exclusiones/inclusiones para aceptar las combinaciones de
compilación de la aplicación. Para más información, vea el artículo Customizing the Build (Personalización de la
compilación) en la documentación de Travis CI. Las herramientas basadas en MSBuild incluyen los runtimes LTS
(1.0.x) y Current (1.1.x) en el paquete; por tanto, cuando instala el SDK, recibe todo lo que necesita para la
compilación.
AppVeyor
AppVeyor instala el SDK de .NET Core 1.0.1 con la imagen de trabajo de compilación de Visual Studio 2017 . Hay
otras imágenes de compilación disponibles con distintas versiones del SDK de .NET. Para más información,
consulte el ejemplo appveyor.yml y el artículo Build worker images (Imágenes de trabajo de compilación) en los
documentos de AppVeyor.
Los archivos binarios del SDK de .NET se descargan y descomprimen en un subdirectorio mediante el script de
instalación y, después, se agregan a la variable de entorno PATH . Agregue una matriz de compilación para ejecutar
las pruebas de integración con varias versiones del SDK de .NET:

environment:
matrix:
- CLI_VERSION: 1.0.1
- CLI_VERSION: Latest

install:
# See appveyor.yml example for install script

Azure DevOps Services

Configure Azure DevOps Services para compilar proyectos de .NET mediante alguno de estos enfoques:
1. Ejecute el script del paso de instalación manual con sus comandos.
2. Cree una compilación compuesta de varias tareas de compilación integradas en Azure DevOps Services
configuradas para usar herramientas de .NET.
Ambas soluciones son válidas. Con la utilización de un script de instalación manual, puede controlar la versión de
las herramientas que recibe, ya que las descarga como parte de la compilación. La compilación se ejecuta desde
un script que debe crear. En este artículo solo se trata la opción manual. Para más información sobre cómo
elaborar una compilación con las tareas de compilación de Azure DevOps Services, consulte la documentación de
Azure Pipelines.
Para usar un script de instalación manual en Azure DevOps Services, cree una definición de compilación y
especifique el script que va a ejecutar para el paso de compilación. Esto se realiza en la interfaz de usuario de
Azure DevOps Services:
1. Empiece por crear una definición de compilación. Cuando llegue a la pantalla en la que se ofrece la opción
de definir el tipo de compilación que desea crear, seleccione la opción Vacío .

2. Después de configurar el repositorio que va a compilar, se le remite a las definiciones de compilación.

Seleccione Agregar paso de compilación :
3. Se abre el Catálogo de tareas . El catálogo contiene tareas que se utilizan en la compilación. Como ya
tiene un script, seleccione el botón Agregar en PowerShell: Ejecute un script de PowerShell .

4. Configure el paso de compilación. Agregue el script desde el repositorio que se va a compilar:

Orquestación de la compilación
En la mayor parte de este documento se describe cómo adquirir las herramientas de .NET y configurar varios
servicios de CI sin ofrecer información sobre cómo orquestar o compilar realmente el código con .NET Core. Las
opciones para estructurar el proceso de compilación dependen de muchos factores que no se pueden tratar aquí
en términos generales. Para más información sobre cómo orquestar las compilaciones con cada tecnología,
explore los recursos y los ejemplos que se proporciona en los conjuntos de documentación de Travis CI, AppVeyor
y Azure Pipelines.
Dos enfoques generales que se aplican para estructurar el proceso de compilación del código de .NET mediante
herramientas de .NET consisten en usar directamente MSBuild, o bien usar los comandos de la línea de comandos
de .NET. El enfoque que debe adoptar depende de lo cómo que se sienta con cada uno de ellos y de los
inconvenientes que presente su complejidad. MSBuild ofrece la posibilidad de expresar el proceso de compilación
como tareas y objetivos, pero presenta la complejidad añadida de tener que aprender la sintaxis del archivo de
proyecto de MSBuild. Es posible que sea más sencillo usar las herramientas de línea de comandos de .NET, pero,
en este caso, es necesario escribir la lógica de orquestación en un lenguaje de scripting como bash o PowerShell.

Vea también
Descargas de .NET: Linux
 Desarrollo de bibliotecas con la CLI de .NET Core
18/12/2020 • 22 minutes to read • Edit Online

En este artículo se explica cómo escribir bibliotecas para .NET con la CLI de .NET Core. La CLI proporciona una
experiencia eficaz y de bajo nivel que funciona en todos los SO compatibles. De todos modos puede seguir
compilando bibliotecas con Visual Studio; si esa es la experiencia de su preferencia, consulte la guía sobre Visual
Studio.

Requisitos previos
Necesita la CLI y el SDK de .NET Core que están instalados en la máquina.
En las secciones de este documento que se refieren a las versiones de .NET Framework, necesita tener instalado
.NET Framework en una máquina con Windows.
Además, si desea admitir destinos de .NET Framework anteriores, deberá instalar paquetes de destino o
desarrollador desde la página de archivos de descarga de .NET. Consulte la tabla siguiente:

VERSIÓ N DE . N ET F RA M EW O RK Q UÉ DEB E DESC A RGA R

4.6.1 Paquete de compatibilidad de .NET Framework 4.6.1

4.6 Paquete de compatibilidad de .NET Framework 4.6

4.5.2 Paquete de desarrollador de .NET Framework 4.5.2

4.5.1 Paquete de desarrollador de .NET Framework 4.5.1

4.5 Kit de desarrollo de software de Windows para Windows 8

4.0 Windows SDK para Windows 7 y .NET Framework 4

2.0, 3.0 y 3.5 Entorno de ejecución de .NET Framework 3.5 SP1 (o una
versión posterior a Windows 8)

Establecimiento de .NET Standard como destino

Si no conoce .NET Standard, consulte el tema .NET Standard para más información.
En ese artículo podrá ver una tabla que asigna las versiones de .NET Standard a diversas implementaciones:

. N ET
STA N DA
RD 1. 0 1. 1 1. 2 1. 3 1. 4 1. 5 1. 6 2. 0 2. 1

.NET Co 1.0 1.0 1.0 1.0 1.0 1.0 1.0 2.0 3.0
re y
.NET 5
 . N ET
STA N DA
RD 1. 0 1. 1 1. 2 1. 3 1. 4 1. 5 1. 6 2. 0 2. 1

.NET 4.5 4.5 4.5.1 4.6 4.6.1 4.6.1 2 4.6.1 2 4.6.1 2 N/A3
Framew
ork 1

Mono 4.6 4.6 4.6 4.6 4.6 4.6 4.6 5.4 6.4

Xamarin 10.0 10.0 10.0 10.0 10.0 10.0 10.0 10.14 12.16
.iOS

Xamarin 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.8 5.16
.Mac

Xamarin 7.0 7.0 7.0 7.0 7.0 7.0 7.0 8.0 10.0
.Android

Platafor 10.0 10.0 10.0 10.0 10.0 10.0.16 10.0.16 10.0.16 TBD
ma 299 299 299
universa
l de
Window
s

Unity 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 TBD

1 Las versiones que se muestran de .NET Framework se aplican al SDK de .NET Core 2.0 y versiones posteriores de la herramienta. Las versiones
anteriores usaban una asignación diferente para .NET Standard 1.5 y versiones posteriores. Puede descargar herramientas para .NET Core para Visual
Studio 2015 si no se puede actualizar a Visual Studio 2017 ni a una versión posterior.

2 Las versiones siguientes representan las reglas que usa NuGet para determinar si una determinada biblioteca de .NET Standard es aplicable. Aunque
NuGet considera a .NET Framework 4.6.1 compatible con .NET Standard (versiones 1.5 a 2.0) hay varios problemas con el consumo de bibliotecas de
.NET Standard que se compilaron para esas versiones desde proyectos de .NET Framework 4.6.1. Para los proyectos de .NET Framework que tengan
que usar estas bibliotecas, se recomienda actualizar el proyecto para destinarlo a .NET Framework 4.7.2 o una versión posterior.

3 .NET Framework no es compatible con .NET Standard 2.1. Para obtener más información, vea el anuncio de .NET Standard 2.1.

Las columnas representan las versiones de .NET Standard. Cada celda de encabezado es un vínculo a un
documento que muestra qué API se han agregado en esa versión de .NET Standard.
Las filas representan las diferentes implementaciones de .NET.
El número de versión de cada celda indica la versión mínima de la implementación que necesitará para tener
como destino dicha versión de .NET Standard.
Para ver una tabla interactiva, consulte Versiones de .NET Standard.
Este es el significado de la tabla para crear una biblioteca:
La versión de .NET Standard que elija será un equilibrio entre el acceso a las API más recientes y la capacidad de
apuntar a más implementaciones .NET y más versiones de .NET Standard. Puede controlar el intervalo de
versiones y plataformas de destino si elige una versión de netstandardX.X (donde X.X es un número de
versión) y la agrega al archivo del proyecto ( .csproj o .fsproj ).
En función de sus necesidades, tiene tres opciones principales cuando el destino es .NET Standard.
1. Puede usar la versión predeterminada de .NET Standard que se proporciona con plantillas, netstandard1.4
, que le permite acceder a la mayoría de API en .NET Standard mientras sigue siendo compatible con UWP,
 .NET Framework 4.6.1 y .NET Standard 2.0.

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.4</TargetFramework>
</PropertyGroup>
</Project>

2. Puede usar una versión anterior o posterior de .NET Standard modificando el valor en el nodo
TargetFramework de su archivo del proyecto.

Las versiones del estándar .NET son compatibles con versiones anteriores. Eso significa que las bibliotecas
netstandard1.0 se pueden ejecutar en plataformas netstandard1.1 y versiones superiores. Sin embargo,
no hay compatibilidad con versiones posteriores. Las plataformas de .NET Standard anteriores no pueden
hacer referencia a las posteriores. Esto significa que las bibliotecas netstandard1.0 no pueden hacer
referencia a las bibliotecas que tienen como destino netstandard1.1 o una versión superior. Seleccione la
versión estándar que tiene la combinación adecuada de compatibilidad con API y plataformas que
necesita. Por ahora le recomendamos netstandard1.4 .
3. Si desea tener como destino .NET Framework versión 4.0 o inferior, o bien desea usar una API disponible
en .NET Framework pero no disponible en el estándar .NET (por ejemplo, System.Drawing ), lea las
secciones siguientes y sepa cómo tener compatibilidad con múltiples versiones.

Uso de .NET Framework como destino

NOTE
En estas instrucciones se supone que tiene instalado .NET Framework en su máquina. Consulte los requisitos previos para
instalar las dependencias.

Tenga en cuenta que algunas de las versiones de .NET Framework que se usan aquí ya no cuentan con soporte
técnico. Consulte las P+F sobre la directiva del ciclo de vida de soporte técnico de .NET Framework sobre las
versiones sin soporte técnico.
Si quiere llegar a la mayor cantidad posible de desarrolladores y proyectos, use .NET Framework 4.0 como el
destino de línea base. Para tener .NET Framework como destino, comience utilizando el moniker de la plataforma
de destino (TFM) correcto que corresponda a la versión de .NET Framework que desea admitir.

VERSIÓ N DE . N ET F RA M EW O RK T FM

.NET Framework 2.0 net20

.NET Framework 3.0 net30

.NET Framework 3,5 net35

.NET Framework 4.0 net40

.NET Framework 4.5 net45

.NET Framework 4.5.1 net451

.NET Framework 4.5.2 net452

 VERSIÓ N DE . N ET F RA M EW O RK T FM

.NET Framework 4.6 net46

.NET Framework 4.6.1 net461

.NET Framework 4.6.2 net462

.NET Framework 4.7 net47

.NET Framework 4.8 net48

Después, inserte el TFM en la sección TargetFramework de su archivo del proyecto. El siguiente es un ejemplo de
cómo podría escribir una biblioteca que tenga como destino .NET Framework 4.0:

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net40</TargetFramework>
</PropertyGroup>
</Project>

Y listo. Aunque esto solo hace la compilación para .NET Framework 4, puede usar la biblioteca en las versiones
más recientes de .NET Framework.

Cómo lograr la compatibilidad con varias versiones

NOTE
Las instrucciones siguientes suponen que tiene instalado .NET Framework en su máquina. Consulte la sección de requisitos
previos para información sobre las dependencias que debe instalar y dónde descargarlas.

Es posible que deba tener como destino versiones anteriores de .NET Framework cuando el proyecto admite .NET
Framework y .NET Core. En este escenario, si desea usar API más recientes y construcciones de lenguaje para los
destinos más recientes, use las directivas #if en el código. También es posible que tenga que agregar distintos
paquetes y dependencias para cada plataforma que tiene como destino para incluir las distintas API necesarias
para cada caso.
Por ejemplo, digamos que tiene una biblioteca que realiza operaciones de red a través de HTTP. En el estándar
.NET y .NET Framework versión 4.5 o superiores, puede usar la clase HttpClient del espacio de nombres
System.Net.Http . Sin embargo, las versiones anteriores de .NET Framework no tienen la clase HttpClient , por lo
que, en su lugar, podría usar la clase WebClient del espacio de nombres System.Net para esas versiones.
Su archivo del proyecto podría tener la siguiente apariencia:
 <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard1.4;net40;net45</TargetFrameworks>
</PropertyGroup>

<!-- Need to conditionally bring in references for the .NET Framework 4.0 target -->
<ItemGroup Condition="'$(TargetFramework)' == 'net40'">
<Reference Include="System.Net" />
</ItemGroup>

<!-- Need to conditionally bring in references for the .NET Framework 4.5 target -->
<ItemGroup Condition="'$(TargetFramework)' == 'net45'">
<Reference Include="System.Net.Http" />
<Reference Include="System.Threading.Tasks" />
</ItemGroup>
</Project>

Observará tres cambios principales aquí:

1. El nodo TargetFramework se ha reemplazado por TargetFrameworks , y se expresan tres TFM dentro.
2. Existe un nodo <ItemGroup> para el destino net40 que se dirige a una referencia de .NET Framework.
3. Existe un nodo <ItemGroup> para el destino net45 que se dirige a dos referencias de .NET Framework.

El sistema de compilación conoce los siguientes símbolos del preprocesador que se usan en las directivas #if :

VERSIO N ES DE . N ET F RA M EW O RK DE DEST IN O SÍM B O LO S

.NET Framework NETFRAMEWORK , NET48 , NET472 , NET471 , NET47 ,

NET462 , NET461 , NET46 , NET452 , NET451 , NET45 ,
NET40 , NET35 , NET20

.NET Standard NETSTANDARD , NETSTANDARD2_1 , NETSTANDARD2_0 ,

NETSTANDARD1_6 , NETSTANDARD1_5 , NETSTANDARD1_4 ,
NETSTANDARD1_3 , NETSTANDARD1_2 , NETSTANDARD1_1 ,
NETSTANDARD1_0

.NET 5 (y .NET Core) NET5_0 , NETCOREAPP , NETCOREAPP3_1 , NETCOREAPP3_0 ,

NETCOREAPP2_2 , NETCOREAPP2_1 , NETCOREAPP2_0 ,
NETCOREAPP1_1 , NETCOREAPP1_0

Aquí se muestra un ejemplo en el que se usa la compilación condicional por destino:

 using System;
using System.Text.RegularExpressions;
#if NET40
// This only compiles for the .NET Framework 4 targets
using System.Net;
#else
// This compiles for all other targets
using System.Net.Http;
using System.Threading.Tasks;
#endif

namespace MultitargetLib
{
public class Library
{
#if NET40
private readonly WebClient _client = new WebClient();
private readonly object _locker = new object();
#else
private readonly HttpClient _client = new HttpClient();
#endif

#if NET40
// .NET Framework 4.0 does not have async/await
public string GetDotNetCount()
{
string url = "https://www.dotnetfoundation.org/";

var uri = new Uri(url);

string result = "";

// Lock here to provide thread-safety.

lock(_locker)
{
result = _client.DownloadString(uri);
}

int dotNetCount = Regex.Matches(result, ".NET").Count;

return $"Dotnet Foundation mentions .NET {dotNetCount} times!";

}
#else
// .NET Framework 4.5+ can use async/await!
public async Task<string> GetDotNetCountAsync()
{
string url = "https://www.dotnetfoundation.org/";

// HttpClient is thread-safe, so no need to explicitly lock here

var result = await _client.GetStringAsync(url);

int dotNetCount = Regex.Matches(result, ".NET").Count;

return $"dotnetfoundation.org mentions .NET {dotNetCount} times in its HTML!";

}
#endif
}
}

Si crea este proyecto con dotnet build , observará tres directorios en la carpeta bin/ :

net40/
net45/
netstandard1.4/
Cada uno de ellos contiene los archivos .dll para cada destino.

Prueba de las bibliotecas en .NET Core

Es importante poder probar las plataformas. Puede usar xUnit o MSTest de fábrica. Ambos son perfectamente
adecuados para las pruebas unitarias de su biblioteca en .NET Core. Cómo configurar la solución con proyectos
de prueba dependerá de la estructura de la solución. En el ejemplo siguiente se presupone que los directorios de
origen y de prueba residen en el mismo directorio de nivel superior.

NOTE
Esto usa algunos comandos de la CLI de .NET Core. Vea dotnet new y dotnet sln para obtener más información.

1. Configure la solución. Puede hacerlo con los siguientes comandos:

mkdir SolutionWithSrcAndTest
cd SolutionWithSrcAndTest
dotnet new sln
dotnet new classlib -o MyProject
dotnet new xunit -o MyProject.Test
dotnet sln add MyProject/MyProject.csproj
dotnet sln add MyProject.Test/MyProject.Test.csproj

Esto creará proyectos y se vincularán conjuntamente en una solución. Su directorio para

SolutionWithSrcAndTest debe tener el siguiente aspecto:

/SolutionWithSrcAndTest
|__SolutionWithSrcAndTest.sln
|__MyProject/
|__MyProject.Test/

2. Vaya al directorio del proyecto de prueba y agregue una referencia a MyProject.Test desde MyProject .

cd MyProject.Test
dotnet add reference ../MyProject/MyProject.csproj

3. Restaurar paquetes y crear proyectos:

dotnet restore
dotnet build

No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que
necesitan que se produzca una restauración, como dotnet new , dotnet build , dotnet run , dotnet test ,
dotnet publish y dotnet pack . Para deshabilitar la restauración implícita, use la opción --no-restore .

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una
restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los
sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.
Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de
dotnet restore .

4. Compruebe que xUnit se ejecuta mediante la ejecución del comando dotnet test . Si decide usar MSTest,
entonces debe ejecutarse en su lugar el ejecutor de la consola de MSTest.
Y listo. Ahora puede probar la biblioteca en todas las plataformas; para ello, use herramientas de línea de
comandos. Para seguir con las pruebas ahora que ya está todo configurado, probar la biblioteca es un proceso
muy simple:
1. Haga los cambios en la biblioteca.
2. Ejecute las pruebas desde la línea de comandos, en el directorio de prueba, con el comando dotnet test .

El código se recompilará automáticamente cuando invoque el comando dotnet test .

Uso de varios proyectos

Una necesidad en común de las bibliotecas de mayor tamaño es ubicar la funcionalidad en distintos proyectos.
Imagine que desea compilar una biblioteca que se pudiera consumir en C# y F# idiomático. Eso significaría que
los usuarios de las bibliotecas las consumirían de manera natural para C# o F#. Por ejemplo, en C#, podría
consumir la biblioteca de la siguiente manera:

using AwesomeLibrary.CSharp;

public Task DoThings(Data data)

{
var convertResult = await AwesomeLibrary.ConvertAsync(data);
var result = AwesomeLibrary.Process(convertResult);
// do something with result
}

En F#, sería de la siguiente manera:

open AwesomeLibrary.FSharp

let doWork data = async {

let! result = AwesomeLibrary.AsyncConvert data // Uses an F# async function rather than C# async method
// do something with result
}

Escenarios de consumo similares a este significan que las API a las que se tiene acceso deben tener una
estructura distinta para C# y para F#. Un enfoque común para lograrlo es factorizar toda la lógica de una
biblioteca en un proyecto central, con los proyectos de C# y F# definiendo los niveles de API que hacen llamadas
a ese proyecto central. En el resto de la sección se usarán los siguientes nombres:
AwesomeLibrar y.Core : un proyecto central que contiene toda la lógica de la biblioteca
AwesomeLibrar y.CSharp : un proyecto con API públicas pensado para el consumo en C#
AwesomeLibrar y.FSharp : un proyecto con API públicas pensado para el consumo en F#
Puede ejecutar los siguientes comandos en su terminal para generar la misma estructura de esta guía:

mkdir AwesomeLibrary && cd AwesomeLibrary

dotnet new sln
mkdir AwesomeLibrary.Core && cd AwesomeLibrary.Core && dotnet new classlib
cd ..
mkdir AwesomeLibrary.CSharp && cd AwesomeLibrary.CSharp && dotnet new classlib
cd ..
mkdir AwesomeLibrary.FSharp && cd AwesomeLibrary.FSharp && dotnet new classlib -lang "F#"
cd ..
dotnet sln add AwesomeLibrary.Core/AwesomeLibrary.Core.csproj
dotnet sln add AwesomeLibrary.CSharp/AwesomeLibrary.CSharp.csproj
dotnet sln add AwesomeLibrary.FSharp/AwesomeLibrary.FSharp.fsproj
Esto agregará los tres proyectos anteriores y un archivo de solución que los vincula conjuntamente. Crear el
archivo de solución y vincular los proyectos le permitirá restaurar y crear proyectos desde un nivel superior.
Referencias entre proyectos
La mejor manera de hacer referencia a un proyecto es usar la CLI de .NET Core para agregar una referencia de
proyecto. Desde los directorios del proyecto AwesomeLibrar y.CSharp y AwesomeLibrar y.FSharp , puede
ejecutar el siguiente comando:

dotnet add reference ../AwesomeLibrary.Core/AwesomeLibrary.Core.csproj

Los archivos del proyecto para AwesomeLibrar y.CSharp y AwesomeLibrar y.FSharp ahora harán referencia
a AwesomeLibrar y.Core como un destino ProjectReference . Puede comprobar esto inspeccionando los
archivos del proyecto y observando lo siguiente en ellos:

<ItemGroup>
<ProjectReference Include="..\AwesomeLibrary.Core\AwesomeLibrary.Core.csproj" />
</ItemGroup>

Puede agregar esta sección a cada archivo del proyecto manualmente si prefiere no usar la CLI de .NET Core.
Estructura de una solución
Otro aspecto importante de las soluciones de varios proyectos es establecer una buena estructura de proyecto
general. Puede organizar el código de la manera que quiera, y siempre y cuando vincule cada proyecto a su
archivo de solución con dotnet sln add , podrá ejecutar dotnet restore y dotnet build en el nivel de solución.
 Plantillas personalizadas para dotnet new
18/12/2020 • 19 minutes to read • Edit Online

El SDK de .NET cuenta con muchas plantillas ya instaladas y listas para su uso. El comando dotnet new no es solo
la forma de usar una plantilla, sino también cómo instalarlas y desinstalarlas. Puede crear plantillas personalizadas
propias para cualquier tipo de proyecto, como una aplicación, un servicio, una herramienta o una biblioteca de
clases. Incluso puede crear una plantilla que genere uno o más archivos independientes, como un archivo de
configuración.
Puede instalar plantillas personalizadas desde un paquete NuGet en cualquier fuente NuGet, haciendo referencia a
un archivo .nupkg de NuGet directamente o especificando un directorio del sistema de archivos que contenga la
plantilla. El motor de plantillas ofrece características que le permiten reemplazar valores, incluir y excluir archivos
y ejecutar operaciones de procesamiento personalizadas cuando se usa la plantilla.
El motor de plantillas es de código abierto, y el repositorio de código en línea está en dotnet/templating en
GitHub. Puede encontrar más plantillas, incluidas las plantillas de terceros, en Plantillas disponibles para dotnet
new en GitHub. Para obtener información sobre cómo crear y usar plantillas personalizadas, vea Cómo crear sus
propias plantillas para dotnet new y la Wiki del repositorio de GitHub dotnet/templating.

NOTE
Los ejemplos de plantillas están disponibles en el repositorio de GitHub dotnet/dotnet-template-samples. Sin embargo,
aunque estos ejemplos son un buen recurso para aprender cómo funcionan las plantillas, el repositorio está archivado y no
recibe mantenimiento. Los ejemplos pueden no estar actualizados y ya no funcionan.

Para seguir un tutorial y crear una plantilla, vea el tutorial Creación de una plantilla personalizada para dotnet
new.
Plantillas predeterminadas .NET
Cuando instala el SDK de .NET, recibe más de una docena de plantillas integradas para crear proyectos y archivos,
incluidas aplicaciones de consola, bibliotecas de clases, proyectos de prueba unitaria, aplicaciones de
ASP.NET Core (incluidos los proyectos Angular y React) y archivos de configuración. Para enumerar las plantillas
integradas, ejecute el comando dotnet new con la opción -l|--list :

dotnet new --list

Configuración
Una plantilla consta de las siguientes partes:
Archivos de origen y carpetas.
Un archivo de configuración (template.json).
Archivos de origen y carpetas
Los archivos de origen y las carpetas incluyen todos los archivos y carpetas que quiera que el motor de plantilla
use cuando se ejecuta el comando dotnet new <TEMPLATE> . El motor de plantillas está diseñado para usar
proyectos ejecutables como código fuente para generar proyectos. Esto presenta varias ventajas:
El motor de plantillas no necesita que inserte tokens especiales en su código de origen del proyecto.
Los archivos de código no son archivos especiales ni se modifican de ninguna manera para que funcionen con
 el motor de plantillas. Por lo tanto, las herramientas que usa normalmente para trabajar con los proyectos
también funcionan con el contenido de la plantilla.
Compile, ejecute y depure sus proyectos de plantilla de la forma en que lo hace para cualquiera de sus otros
proyectos.
Puede crear rápidamente una plantilla de un proyecto existente simplemente agregando un archivo de
configuración ./.template.config/template.json al proyecto.
Los archivos y las carpetas que se almacenan en la plantilla no se limitan a tipos de proyectos .NET formales. Los
archivos de origen y las carpetas pueden constar de cualquier contenido que quiera crear cuando se use la
plantilla, incluso si el motor de plantillas genera solo un archivo como su salida.
Los archivos que genera la plantilla se pueden modificar según la lógica y la configuración que ha proporcionado
en el archivo de configuración template.json. El usuario puede invalidar esta configuración pasando las opciones
al comando dotnet new <TEMPLATE> . Un ejemplo común de una lógica personalizada es proporcionar un nombre
para una clase o variable en el archivo de código que se implementa mediante una plantilla.
template.json
El archivo template.json se coloca en una carpeta .template.config en el directorio raíz de la plantilla. El archivo
proporciona información de configuración al motor de plantillas. La configuración mínima necesita los miembros
que se muestran en la tabla siguiente, que es suficiente para crear una plantilla funcional.

M IEM B RO T IP O DESC RIP C IÓ N

$schema Identificador URI El esquema JSON para el archivo

template.json. Los editores que
admiten los esquemas JSON habilitan
las características de edición JSON
cuando se especifica el esquema. Por
ejemplo, Visual Studio Code necesita
este miembro para habilitar IntelliSense.
Use un valor de
http://json.schemastore.org/template
.

author cadena El autor de la plantilla.

classifications array(string) Cero o más características de la plantilla

que un usuario puede usar para buscar
la plantilla al buscarla. Las clasificaciones
también aparecen en la columna
Etiquetas cuando aparece en una lista
de plantillas que se han generado
mediante el comando
dotnet new -l|--list .

identity cadena Un nombre único para esta plantilla.

name cadena El nombre de la plantilla que los

usuarios deben ver.
 M IEM B RO T IP O DESC RIP C IÓ N

shortName cadena Un nombre abreviado predeterminado

para seleccionar la plantilla que se
aplica a entornos donde el usuario
especifica el nombre de la plantilla; no
se selecciona mediante una GUI. Por
ejemplo, un nombre abreviado es útil al
usar plantillas desde un símbolo del
sistema con comandos de la CLI.

sourceName string Nombre del árbol de origen que se va a

reemplazar por el nombre que
especifica el usuario. El motor de
plantillas buscará cualquier aparición
del valor sourceName mencionado en
el archivo de configuración y la
reemplazará en los nombres de archivo
y en el contenido del archivo. El valor
con el que se reemplazará se puede
proporcionar usando las opciones -n
o --name mientras se ejecuta una
plantilla. Si no se especifica ningún
nombre, se usa el directorio actual.

preferNameDirectory boolean Indica si se debe crear un directorio

para la plantilla si se especifica un
nombre pero no se establece un
directorio de salida (en lugar de crear el
contenido directamente en el directorio
actual). El valor predeterminado es
false.

El esquema completo del archivo template.json puede encontrarse en el Almacenamiento del esquema JSON. Para
más información sobre el archivo template.json, consulte la wiki de plantillas dotnet.
Ejemplo
Por ejemplo, esta es una carpeta de plantillas que tiene dos archivos de contenido: console.cs y readme.txt. Tenga
en cuenta que existe la carpeta requerida denominada .template.config que contiene el archivo template.json.

└───mytemplate
│ console.cs
│ readme.txt
│
└───.template.config
template.json

El archivo template.json tiene un aspecto parecido al siguiente:

{
"$schema": "http://json.schemastore.org/template",
"author": "Travis Chau",
"classifications": [ "Common", "Console" ],
"identity": "AdatumCorporation.ConsoleTemplate.CSharp",
"name": "Adatum Corporation Console Application",
"shortName": "adatumconsole"
}

La carpeta mytemplate es un paquete de plantilla instalable. Una vez instalado el paquete, shortName se puede
utilizar con el comando dotnet new . Por ejemplo, dotnet new adatumconsole generaría los archivos console.cs y
readme.txt en la carpeta actual.

Empaquetar una plantilla en un paquete NuGet (archivo nupkg)

Una plantilla personalizada se empaqueta con el comando la dotnet pack y un archivo .csproj. Como alternativa,
se puede usar NuGet con el comando nuget pack junto con un archivo .nuspec. Pero NuGet necesita .NET
Framework en Windows y Mono en Linux y macOS.
El archivo .csproj es ligeramente diferente al archivo .csproj de un proyecto de código tradicional. Tenga en cuenta
la siguiente configuración:
1. El valor <PackageType> se agrega y se establece en Template .
2. El valor <PackageVersion> se agrega y establece en un número de versión de NuGet.
3. El valor <PackageId> se agrega y se establece en un identificador único. Este identificador se usa para
desinstalar el paquete de plantillas y lo usan las fuentes NuGet para registrar su paquete de plantillas.
4. Se debe establecer la configuración de metadatos genérica: <Title> , <Authors> , <Description> y
<PackageTags> .
5. Debe establecerse la configuración <TargetFramework> , aunque no se usen los datos binarios generados por el
proceso de la plantilla. En el ejemplo siguiente se establece en netstandard2.0 .

Un paquete de plantillas, en forma de un paquete NuGet .nupkg, requiere que todas las plantillas se almacenan en
la carpeta content dentro del paquete. Hay algunas opciones de configuración más para agregar a un archivo
.csproj para asegurarse de que el paquete .nupkg generado se puede instalar como un paquete de plantilla:
1. El valor <IncludeContentInPack> se establece en true para incluir cualquier archivo que el proyecto establece
como content en el paquete NuGet.
2. El valor <IncludeBuildOutput> se establece en false para excluir todos los archivos binarios generados por el
compilador desde el paquete NuGet.
3. El valor <ContentTargetFolders> se establece en content . Esto garantiza que los archivos establecidos como
content se almacenan en la carpeta content carpeta en el paquete NuGet. Esta carpeta del paquete NuGet la
analiza el sistema de plantillas dotnet.
Una manera sencilla de excluir todos los archivos de código para que el proyecto de su plantilla no los compile es
usando el elemento <Compile Remove="**\*" /> del archivo de proyecto, dentro de un elemento <ItemGroup> .
Una manera sencilla de estructurar su paquete de plantillas es colocar todas las plantillas en carpetas individuales
y luego cada carpeta de plantillas dentro de una carpeta templates que se encuentra en el mismo directorio que el
archivo .csproj . De esta manera, puede usar un solo elemento del proyecto para incluir todos los archivos y
carpetas en templates como content . Dentro de un elemento <ItemGroup> , cree un elemento
<Content Include="templates\**\*" Exclude="templates\**\bin\**;templates\**\obj\**" /> .

Este es un archivo .csproj de ejemplo que sigue todas las pautas anteriores. Empaqueta la carpeta secundaria
templates en la carpeta del paquete content y excluye cualquier archivo de código de la compilación.
 <Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<PackageType>Template</PackageType>
<PackageVersion>1.0</PackageVersion>
<PackageId>AdatumCorporation.Utility.Templates</PackageId>
<Title>AdatumCorporation Templates</Title>
<Authors>Me</Authors>
<Description>Templates to use when creating an application for Adatum Corporation.</Description>
<PackageTags>dotnet-new;templates;contoso</PackageTags>
<TargetFramework>netstandard2.0</TargetFramework>

<IncludeContentInPack>true</IncludeContentInPack>
<IncludeBuildOutput>false</IncludeBuildOutput>
<ContentTargetFolders>content</ContentTargetFolders>
</PropertyGroup>

<ItemGroup>
<Content Include="templates\**\*" Exclude="templates\**\bin\**;templates\**\obj\**" />
<Compile Remove="**\*" />
</ItemGroup>

</Project>

En el siguiente ejemplo se muestra la estructura de archivos y carpetas de usar .csproj para crear un paquete de
plantillas. El archivo MyDotnetTemplates.csproj y la carpeta templates se encuentran en la raíz de un directorio
denominado project_folder. La carpeta templates contiene dos plantillas: mytemplate1 y mytemplate2. Cada
plantilla tiene archivos de contenido y una carpeta .template.config con un archivo de configuración template.json.

project_folder
│ MyDotnetTemplates.csproj
│
└───templates
├───mytemplate1
│ │ console.cs
│ │ readme.txt
│ │
│ └───.template.config
│ template.json
│
└───mytemplate2
│ otherfile.cs
│
└───.template.config
template.json

Instalar una plantilla

Use el comando dotnet new -i|--install para instalar un paquete.
Para instalar una plantilla de un paquete NuGet almacenado en nuget.org
Use el identificador del paquete NuGet para instalar un paquete de plantillas.

dotnet new -i <NUGET_PACKAGE_ID>

Para instalar una plantilla de un archivo nupkg local

Proporcione la ruta de acceso a un archivo de paquete NuGet .nupkg.
 dotnet new -i <PATH_TO_NUPKG_FILE>

Para instalar una plantilla desde un directorio de sistema de archivos

Las plantillas se pueden instalar desde una carpeta de plantillas, como la carpeta mytemplate1 del ejemplo
anterior. Especifique la ruta de acceso de la carpeta .template.config. La ruta de acceso al directorio de plantillas no
es necesario que sea absoluto. Sin embargo, se requiere una ruta de acceso absoluta para desinstalar una plantilla
que se instala desde una carpeta.

dotnet new -i <FILE_SYSTEM_DIRECTORY>

Obtención de una lista de plantillas instaladas

El comando de desinstalación, sin ningún otro parámetro, enumerará todas las plantillas instaladas.

dotnet new -u

Ese comando devuelve algo similar a la salida siguiente:

Template Instantiation Commands for .NET CLI

Currently installed items:

Microsoft.DotNet.Common.ItemTemplates
Templates:
global.json file (globaljson)
NuGet Config (nugetconfig)
Solution File (sln)
Dotnet local tool manifest file (tool-manifest)
Web Config (webconfig)
Microsoft.DotNet.Common.ProjectTemplates.3.0
Templates:
Class library (classlib) C#
Class library (classlib) F#
Class library (classlib) VB
Console Application (console) C#
Console Application (console) F#
Console Application (console) VB
...

El primer nivel de los elementos situados después de Currently installed items: son los identificadores usados
en la desinstalación de una plantilla. Y en el ejemplo anterior, se enumeran Microsoft.DotNet.Common.ItemTemplates
y Microsoft.DotNet.Common.ProjectTemplates.3.0 . Si la plantilla se instaló mediante una ruta de acceso del sistema
de archivos, este identificador será la ruta de acceso de la carpeta .template.config.

Desinstalación de una plantilla

Use el comando dotnet new -u|--uninstall para desinstalar un paquete.
Si el paquete lo instaló una fuente de NuGet o un archivo .nupkg directamente, proporcione el identificador.

dotnet new -u <NUGET_PACKAGE_ID>

Si el paquete se instaló mediante la especificación de una ruta de acceso a la carpeta .template.config, use esa ruta
de acceso absoluta para desinstalar el paquete. Puede ver la ruta de acceso absoluta de la plantilla en el resultado
proporcionado por el comando dotnet new -u . Para obtener más información, consulte la sección Obtención de
una lista de plantillas instaladas anterior.

dotnet new -u <ABSOLUTE_FILE_SYSTEM_DIRECTORY>

Crear un proyecto con una plantilla personalizada

Después de que se instale una plantilla, use la plantilla ejecutando el comando dotnet new <TEMPLATE> como lo
haría con cualquier otra plantilla preinstalada. También puede especificar opciones en el comando dotnet new ,
incluidas las opciones específicas de plantilla que ha definido en la configuración de la plantilla. Proporcione el
nombre breve de la plantilla directamente al comando:

dotnet new <TEMPLATE>

Vea también
Creación de una plantilla personalizada para dotnet new (tutorial)
Wiki del repositorio de GitHub dotnet/templating
Repositorio de GitHub dotnet/dotnet-template-samples
How to create your own templates for dotnet new (Cómo crear sus propias plantillas para dotnet new)
Esquema template.json en el Almacenamiento del esquema JSON
 Tutorial: Creación de una plantilla de elemento
02/11/2020 • 11 minutes to read • Edit Online

Con .NET Core, puede crear e implementar plantillas que generan proyectos, archivos e inclusos recursos. Este
tutorial es el primero de una serie que enseña a crear, instalar y desinstalar plantillas para usarlas con el
comando dotnet new .
En esta parte de la serie, aprenderá a:
Crear una clase para una plantilla de elemento.
Crear el archivo y la carpeta de configuración de la plantilla.
Instalar una plantilla desde una ruta de acceso de archivo.
Probar una plantilla de elemento.
Desinstalar una plantilla de elemento.

Requisitos previos
SDK de .NET Core 2.2 o versiones posteriores.
Leer el artículo de referencia Plantillas personalizadas para dotnet new.
En el artículo de referencia se explican los aspectos básicos de las plantillas y cómo se unen. Parte de esta
información se repetirá en este tutorial.
Abra un terminal y vaya a la carpeta working\templates.

Creación de las carpetas necesarias

Esta serie usa una "carpeta de trabajo", donde se encuentra el origen de la plantilla, y una "carpeta de prueba"
que se usa para probar las plantillas. La carpeta de trabajo y la carpeta de prueba deben estar en la misma
carpeta.
En primer lugar, cree la carpeta principal, no importa con qué nombre. Luego, cree una subcarpeta denominada
working (trabajo). Dentro de la carpeta working, cree una subcarpeta con el nombre templates (plantillas).
A continuación, cree una carpeta dentro de la carpeta principal con el nombre test (prueba). La estructura de
carpetas debe tener el siguiente aspecto.

parent_folder
├───test
└───working
└───templates

Creación de una plantilla de elemento

Una plantilla de elemento es un tipo de plantilla específico que contiene uno o varios archivos. Estos tipos de
plantillas son útiles cuando se quiere generar algún contenido como un archivo de solución, código o
configuración. En este ejemplo, creará una clase que agrega un método de extensión al tipo de cadena.
En el terminal, vaya a la carpeta working\templates y cree una subcarpeta llamada extensions. Entre a la carpeta.
 working
└───templates
└───extensions

Cree un archivo nuevo denominado CommonExtensions.cs y ábralo con el editor de texto que prefiera. Esta
clase proporcionará un método de extensión denominado Reverse que invierte el contenido de una cadena.
Pegue el código siguiente y guarde el archivo:

using System;

namespace System
{
public static class StringExtensions
{
public static string Reverse(this string value)
{
var tempArray = value.ToCharArray();
Array.Reverse(tempArray);
return new string(tempArray);
}
}
}

Ahora que creó el contenido de la plantilla, debe crear su configuración en la carpeta raíz de la plantilla.

Creación de la configuración de una plantilla

En .NET Core, las plantillas se reconocen con una carpeta especial y un archivo de configuración que existen en
la raíz de la plantilla. En este tutorial, la carpeta de la plantilla se encuentra en working\templates\extensions.
Cuando se crea una plantilla, todos los archivos y las carpetas de la carpeta de la plantilla se incluyen como
parte de la plantilla, a excepción de la carpeta de configuración especial. Esta carpeta de configuración se
denomina .template.config.
En primer lugar, cree una subcarpeta con el nombre .template.config y entre en ella. Luego, cree un archivo
denominado template.json. La estructura de la carpeta debe verse así:

working
└───templates
└───extensions
└───.template.config
template.json

Abra template.json con el editor de texto que prefiera, pegue el código JSON siguiente y guárdelo.

{
"$schema": "http://json.schemastore.org/template",
"author": "Me",
"classifications": [ "Common", "Code" ],
"identity": "ExampleTemplate.StringExtensions",
"name": "Example templates: string extensions",
"shortName": "stringext",
"tags": {
"language": "C#",
"type": "item"
}
}
Este archivo de configuración contiene todos los valores de la plantilla. Puede ver los valores básicos, como
name y shortName , pero también hay un valor tags/type que está establecido en item . De este modo, la
plantilla se clasifica como una plantilla de elemento. No hay ninguna restricción en el tipo de plantilla que crea.
Los valores item y project son nombres comunes que .NET Core recomienda para que los usuarios puedan
filtrar fácilmente el tipo de plantilla que buscan.
El elemento classifications representa la columna tags que ve cuando ejecuta dotnet new y obtiene una lista
de plantillas. Los usuarios también pueden hacer una búsqueda según las etiquetas de clasificación. No
confunda la propiedad tags del archivo *.json con la lista de etiquetas classifications . Lamentablemente, son
dos elementos que tienen nombres similares. El esquema completo del archivo template.json puede encontrarse
en el Almacenamiento del esquema JSON. Para más información sobre el archivo template.json, consulte la wiki
de plantillas dotnet.
Ahora que tiene un archivo .template.config/template.json válido, la plantilla está lista para instalarla. En el
terminal, vaya a la carpeta extensions y ejecute el comando siguiente para instalar la plantilla ubicada en la
carpeta actual:
En Windows : dotnet new -i .\
En Linux o macOS : dotnet new -i ./

Este comando genera la lista de las plantillas instaladas, que debería incluir la suya.

C:\working\templates\extensions> dotnet new -i .\

Usage: new [options]

Options:
-h, --help Displays help for this command.
-l, --list Lists templates containing the specified name. If no name is specified, lists all
templates.

... cut to save space ...

Templates Short Name Language Tags

------------------------------------------------------------------------------------------------------------
-------------------
Example templates: string extensions stringext [C#] Common/Code
Console Application console [C#], F#, VB Common/Console
Class library classlib [C#], F#, VB Common/Library
WPF Application wpf [C#], VB Common/WPF
Windows Forms (WinForms) Application winforms [C#], VB Common/WinForms
Worker Service worker [C#] Common/Worker/Web

Prueba de la plantilla de elemento

Ahora que tiene instalada una plantilla de elemento, pruébela. Vaya a la carpeta test/ y cree una aplicación de
consola con dotnet new console . Esto genera un proyecto de trabajo que puede probar fácilmente con el
comando dotnet run .

dotnet new console

Verá un resultado similar al siguiente.

 The template "Console Application" was created successfully.

Processing post-creation actions...

Running 'dotnet restore' on C:\test\test.csproj...
Restore completed in 54.82 ms for C:\test\test.csproj.

Restore succeeded.

Ejecute el proyecto.

dotnet run

Obtendrá la siguiente salida.

Hello World!

Luego, ejecute dotnet new stringext para generar CommonExtensions.cs desde la plantilla.

dotnet new stringext

Obtendrá la siguiente salida.

The template "Example templates: string extensions" was created successfully.

Cambie el código en Program.cs para invertir la cadena "Hello World" con el método de extensión que se
proporciona en la plantilla.

Console.WriteLine("Hello World!".Reverse());

Vuelva a ejecutar el programa y verá que el resultado se invirtió.

dotnet run

Obtendrá la siguiente salida.

!dlroW olleH

¡Enhorabuena! Ha creado e implementado una plantilla de elemento con .NET Core. Como preparación para la
próxima parte de esta serie de tutoriales, debe desinstalar la plantilla que creó. Asegúrese de eliminar también
todos los archivos de la carpeta test. Esto le permitirá volver a un estado limpio listo para la próxima sección
importante de este tutorial.

Desinstalación de la plantilla
Como instaló la plantilla a través de la ruta de acceso de archivo, debe desinstalarla con la ruta de acceso de
archivo absoluta . Ejecute el comando dotnet new -u para ver una lista de las plantillas instaladas. Su plantilla
debe aparecer en último lugar. Use la ruta de acceso mostrada para desinstalar la plantilla con el comando
dotnet new -u <ABSOLUTE PATH TO TEMPLATE DIRECTORY> .
 dotnet new -u

Verá un resultado similar al siguiente.

Template Instantiation Commands for .NET Core CLI

Currently installed items:

Microsoft.DotNet.Common.ItemTemplates
Templates:
dotnet gitignore file (gitignore)
global.json file (globaljson)
NuGet Config (nugetconfig)
Solution File (sln)
Dotnet local tool manifest file (tool-manifest)
Web Config (webconfig)

... cut to save space ...

NUnit3.DotNetNew.Template
Templates:
NUnit 3 Test Project (nunit) C#
NUnit 3 Test Item (nunit-test) C#
NUnit 3 Test Project (nunit) F#
NUnit 3 Test Item (nunit-test) F#
NUnit 3 Test Project (nunit) VB
NUnit 3 Test Item (nunit-test) VB
C:\working\templates\extensions
Templates:
Example templates: string extensions (stringext) C#

Para desinstalar una plantilla, ejecute el siguiente comando.

dotnet new -u C:\working\templates\extensions

Pasos siguientes
En este tutorial, creó una plantilla de elemento. Para aprender a crear una plantilla de proyecto, siga con esta
serie de tutoriales.
Creación de una plantilla de proyecto
 Tutorial: Creación de una plantilla de proyecto
02/11/2020 • 10 minutes to read • Edit Online

Con .NET Core, puede crear e implementar plantillas que generan proyectos, archivos e inclusos recursos. Este
tutorial es el segundo de una serie que enseña a crear, instalar y desinstalar plantillas para usarlas con el comando
dotnet new .

En esta parte de la serie, aprenderá a:

Crear los recursos de una plantilla de proyecto.
Crear el archivo y la carpeta de configuración de la plantilla.
Instalar una plantilla desde una ruta de acceso de archivo.
Probar una plantilla de elemento.
Desinstalar una plantilla de elemento.

Requisitos previos
Complete la parte 1 de esta serie de tutoriales.
Abra un terminal y vaya a la carpeta working\templates.

Creación de una plantilla de proyecto

Las plantillas de proyecto generan proyectos listos para ejecutarse que facilita a los usuarios empezar a trabajar
con un espacio de trabajo de código. .NET Core incluye algunas plantillas de proyecto, como una aplicación de
consola o una biblioteca de clases. En este ejemplo, creará un proyecto de consola nuevo que habilita C# 8.0 y
genera un punto de entrada async main .
En el terminal, vaya a la carpeta working\templates y cree una subcarpeta denominada consoleasync. Entre a la
subcarpeta y ejecute dotnet new console para generar la aplicación de consola estándar. Para crear una plantilla
nueva, tendrá que editar los archivos que genere esta plantilla.

working
└───templates
└───consoleasync
consoleasync.csproj
Program.cs

Modificación de Program.cs
Abra el archivo program.cs. El proyecto de la consola no usa un punto de entrada asincrónico, por lo que vamos a
agregarlo. Cambie el código por lo siguiente y guarde el archivo.
 using System;
using System.Threading.Tasks;

namespace consoleasync
{
class Program
{
static async Task Main(string[] args)
{
await Console.Out.WriteAsync("Hello World with C# 8.0!");
}
}
}

Modificación de consoleasync.csproj
Actualicemos la versión del lenguaje C# que usa el proyecto a la versión 8.0. Edite el archivo consoleasync.csproj y
agregue el valor <LangVersion> a un nodo <PropertyGroup> .

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.2</TargetFramework>

<LangVersion>8.0</LangVersion>

</PropertyGroup>

</Project>

Compilar el proyecto
Antes de completar una plantilla de proyecto, debe probarla para asegurarse de que se compila y ejecuta
correctamente.
En el terminal, ejecute el comando siguiente.

dotnet run

Obtendrá la siguiente salida.

Hello World with C# 8.0!

Puede eliminar las carpetas obj y bin creadas si usa dotnet run . La eliminación de estos archivos garantizar que la
plantilla solo incluya los archivos relacionados con la plantilla y no cualquier archivo que resulte de una acción de
compilación.
Ahora que creó el contenido de la plantilla, debe crear su configuración en la carpeta raíz de la plantilla.

Creación de la configuración de una plantilla

En .NET Core, las plantillas se reconocen con una carpeta especial y un archivo de configuración que existen en la
raíz de la plantilla. En este tutorial, la carpeta de la plantilla se encuentra en working\templates\consoleasync.
Cuando se crea una plantilla, todos los archivos y las carpetas de la carpeta de la plantilla se incluyen como parte
de la plantilla, a excepción de la carpeta de configuración especial. Esta carpeta de configuración se denomina
.template.config.
En primer lugar, cree una subcarpeta con el nombre .template.config y entre en ella. Luego, cree un archivo
denominado template.json. La estructura de carpetas debe tener este aspecto.

working
└───templates
└───consoleasync
└───.template.config
template.json

Abra template.json con el editor de texto que prefiera, pegue el código JSON siguiente y guárdelo.

{
"$schema": "http://json.schemastore.org/template",
"author": "Me",
"classifications": [ "Common", "Console", "C#8" ],
"identity": "ExampleTemplate.AsyncProject",
"name": "Example templates: async project",
"shortName": "consoleasync",
"tags": {
"language": "C#",
"type": "project"
}
}

Este archivo de configuración contiene todos los valores de la plantilla. Puede ver los valores básicos, como name
y shortName , pero también hay un valor tags/type que está establecido en project . Esto diseña la plantilla como
una plantilla de proyecto. No hay ninguna restricción en el tipo de plantilla que crea. Los valores item y project
son nombres comunes que .NET Core recomienda para que los usuarios puedan filtrar fácilmente el tipo de
plantilla que buscan.
El elemento classifications representa la columna tags que ve cuando ejecuta dotnet new y obtiene una lista
de plantillas. Los usuarios también pueden hacer una búsqueda según las etiquetas de clasificación. No confunda
la propiedad tags del archivo .json con la lista de etiquetas classifications . Lamentablemente, son dos
elementos que tienen nombres similares. El esquema completo del archivo template.json puede encontrarse en el
Almacenamiento del esquema JSON. Para más información sobre el archivo template.json, consulte la wiki de
plantillas dotnet.
Ahora que tiene un archivo .template.config/template.json válido, la plantilla está lista para instalarla. Antes de
instalar la plantilla, asegúrese de eliminar cualquier archivo o carpeta de archivos adicional que no quiere que se
incluya en la plantilla, como las carpetas bin o obj. En el terminal, vaya a la carpeta consoleasync y ejecute
dotnet new -i .\ para instalar la plantilla ubicada en la carpeta actual. Si usa un sistema operativo Linux o
macOS, use una barra diagonal: dotnet new -i ./ .
Este comando genera la lista de las plantillas instaladas, que debería incluir la suya.

dotnet new -i .\

Verá un resultado similar al siguiente.

 Usage: new [options]

Options:
-h, --help Displays help for this command.
-l, --list Lists templates containing the specified name. If no name is specified, lists all
templates.

... cut to save space ...

Templates Short Name Language Tags

--------------------------------------------------------------------------------------------------------------
-----------------
Console Application console [C#], F#, VB Common/Console
Example templates: async project consoleasync [C#] Common/Console/C#8
Class library classlib [C#], F#, VB Common/Library
WPF Application wpf [C#], VB Common/WPF
Windows Forms (WinForms) Application winforms [C#], VB Common/WinForms
Worker Service worker [C#] Common/Worker/Web

Prueba de la plantilla de proyecto

Ahora que tiene instalada una plantilla de elemento, pruébela.
1. Vaya a la carpeta test.
2. Cree una aplicación de consola con el siguiente comando que genera un proyecto de trabajo que puede
probar fácilmente con el comando dotnet run .

dotnet new consoleasync

Obtendrá la siguiente salida.

The template "Example templates: async project" was created successfully.

3. Ejecute el proyecto con el comando siguiente.

dotnet run

Obtendrá la siguiente salida.

Hello World with C# 8.0!

¡Enhorabuena! Ha creado e implementado una plantilla de proyecto con .NET Core. Como preparación para la
próxima parte de esta serie de tutoriales, debe desinstalar la plantilla que creó. Asegúrese de eliminar también
todos los archivos de la carpeta test. Esto le permitirá volver a un estado limpio listo para la próxima sección
importante de este tutorial.
Desinstalación de la plantilla
Como instaló la plantilla a través de una ruta de acceso de archivo, debe desinstalarla con la ruta de acceso de
archivo absoluta . Ejecute el comando dotnet new -u para ver una lista de las plantillas instaladas. Su plantilla
debe aparecer en último lugar. Use la ruta de acceso mostrada para desinstalar la plantilla con el comando
dotnet new -u <ABSOLUTE PATH TO TEMPLATE DIRECTORY> .

dotnet new -u
Verá un resultado similar al siguiente.

Template Instantiation Commands for .NET Core CLI

Currently installed items:

Microsoft.DotNet.Common.ItemTemplates
Templates:
dotnet gitignore file (gitignore)
global.json file (globaljson)
NuGet Config (nugetconfig)
Solution File (sln)
Dotnet local tool manifest file (tool-manifest)
Web Config (webconfig)

... cut to save space ...

NUnit3.DotNetNew.Template
Templates:
NUnit 3 Test Project (nunit) C#
NUnit 3 Test Item (nunit-test) C#
NUnit 3 Test Project (nunit) F#
NUnit 3 Test Item (nunit-test) F#
NUnit 3 Test Project (nunit) VB
NUnit 3 Test Item (nunit-test) VB
C:\working\templates\consoleasync
Templates:
Example templates: async project (consoleasync) C#

Para desinstalar una plantilla, ejecute el siguiente comando.

dotnet new -u C:\working\templates\consoleasync

Pasos siguientes
En este tutorial creó una plantilla de proyecto. Para información sobre cómo empaquetar la plantilla de elemento y
la de proyecto en un archivo fácil de usar, continúe con esta serie de tutoriales.
Creación de un paquete de plantillas
 Tutorial: Creación de un paquete de plantillas
02/11/2020 • 10 minutes to read • Edit Online

Con .NET Core, puede crear e implementar plantillas que generan proyectos, archivos e inclusos recursos. Este
tutorial es el tercero de una serie que enseña a crear, instalar y desinstalar plantillas para usarlas con el comando
dotnet new .

En esta parte de la serie, aprenderá a:

Crear un proyecto *.csproj para compilar un paquete de plantillas
Configurar el archivo del proyecto para el empaquetado.
Instalar una plantilla a partir de un archivo de paquete de NuGet.
Desinstalar una plantilla por el identificador del paquete.

Requisitos previos
Complete la parte 1 y la parte 2 de esta serie de tutoriales.
En este tutorial se usan las dos plantillas que se crearon en las dos primeras partes de este tutorial. Puede
usar otra plantilla siempre que la copie como una carpeta en la carpeta working\templates\ .
Abra un terminal y vaya a la carpeta working\ .

Creación de un proyecto de paquete de plantillas

Cuando se habla un paquete de plantillas, nos referimos a una o más plantillas empaquetadas en un archivo.
Cuando instala o desinstala un paquete, se agregan o quitan todas las plantillas del paquete, respectivamente. Las
partes anteriores de esta serie de tutoriales solo funcionan con plantillas individuales. Para compartir una plantilla
no empaquetada, tiene que copiar la carpeta de plantilla y realizar la instalación mediante esa carpeta. Como un
paquete de plantillas puede tener más de una plantilla y se trata de un solo archivo, compartirlo resulta sencillo.
Los paquetes de plantillas se representan con un archivo ( .nupkg) de paquete de NuGet. Y, al igual que lo que
ocurre con cualquier paquete de NuGet, puede cargar el paquete de plantillas a una fuente NuGet. El comando
dotnet new -i permite instalar un paquete de plantillas desde una fuente NuGet. Además, puede instalar un
paquete de plantillas directamente desde un archivo .nupkg.
Por lo general, se usa un archivo del proyecto de C# para compilar el código y generar un archivo binario. Pero el
proyecto también se puede usar para generar un paquete de plantillas. Si cambia la configuración del archivo
.csproj, puede impedir que compile código y, en su lugar, incluir todos los recursos de las plantillas como recursos.
Cuando se compila este proyecto, genera un paquete de NuGet de paquete de plantillas.
El paquete que va a crear incluirá la plantilla de elemento y la plantilla de paquete que creó anteriormente. Como
agrupamos ambas plantillas en la carpeta working\templates\ , podemos usar la carpeta working para el archivo
.csproj.
En el terminal, vaya a la carpeta working. Cree un proyecto nuevo y establezca el nombre en templatepack y la
carpeta de salida en la carpeta actual.

dotnet new console -n templatepack -o .

El parámetro -n establece el nombre de archivo .csproj en templatepack.csproj. El parámetro -o crea los

archivos en el directorio actual. Verá un resultado similar a la salida siguiente.

dotnet new console -n templatepack -o .

The template "Console Application" was created successfully.

Processing post-creation actions...

Running 'dotnet restore' on .\templatepack.csproj...
Restore completed in 52.38 ms for C:\working\templatepack.csproj.

Restore succeeded.

A continuación, abra el archivo templatepack.csproj en su editor favorito y reemplace el contenido por el XML
siguiente:

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<PackageType>Template</PackageType>
<PackageVersion>1.0</PackageVersion>
<PackageId>AdatumCorporation.Utility.Templates</PackageId>
<Title>AdatumCorporation Templates</Title>
<Authors>Me</Authors>
<Description>Templates to use when creating an application for Adatum Corporation.</Description>
<PackageTags>dotnet-new;templates;contoso</PackageTags>

<TargetFramework>netstandard2.0</TargetFramework>

<IncludeContentInPack>true</IncludeContentInPack>
<IncludeBuildOutput>false</IncludeBuildOutput>
<ContentTargetFolders>content</ContentTargetFolders>
</PropertyGroup>

<ItemGroup>
<Content Include="templates\**\*" Exclude="templates\**\bin\**;templates\**\obj\**" />
<Compile Remove="**\*" />
</ItemGroup>

</Project>

El valor <PropertyGroup> del XML anterior se divide en tres grupos. El primer grupo trata con las propiedades
requeridas para un paquete de NuGet. Los tres valores <Package están relacionados con las propiedades del
paquete de NuGet para identificar el paquete en una fuente NuGet. En concreto, el valor <PackageId> se usa para
desinstalar el paquete de plantillas con un solo nombre en lugar de una ruta de acceso a un directorio. También se
puede usar para instalar el paquete de plantillas desde una fuente NuGet. Los valores restantes, como <Title> y
<PackageTags> , están relacionados con los metadatos que aparecen en la fuente NuGet. Para más información
sobre la configuración de NuGet, consulte el artículo sobre propiedades de NuGet y MSBuild.
La configuración <TargetFramework> se debe establecer de manera que MSBuild se ejecute correctamente al
ejecutar el comando pack para compilar y empaquetar el proyecto.
Los tres últimos valores están relacionados con la configuración correcta del proyecto para incluir las plantillas en
la carpeta correspondiente del paquete de NuGet cuando se crea.
<ItemGroup> contiene dos valores. En primer lugar, el valor <Content> incluye todo lo que hay en la carpeta
templates como contenido. También se establece para excluir cualquier carpeta bin o carpeta obj para evitar que se
incluya cualquier código compilado (si probó y compiló las plantillas). En segundo lugar, el valor <Compile> excluye
todos los archivos de código de la compilación, independientemente de dónde estén ubicados. Esto evita que el
proyecto que se usa para crear un paquete de plantillas intente compilar el código en la jerarquía de carpetas
templates.

Compilación e instalación
Guarde este archivo y, a continuación, ejecute el comando pack.

dotnet pack

Este comando compilará el proyecto y creará un paquete NuGet en la carpeta working\bin\Debug.

dotnet pack

Microsoft (R) Build Engine version 16.2.0-preview-19278-01+d635043bd for .NET Core

Copyright (C) Microsoft Corporation. All rights reserved.

Restore completed in 123.86 ms for C:\working\templatepack.csproj.

templatepack -> C:\working\bin\Debug\netstandard2.0\templatepack.dll

Successfully created package 'C:\working\bin\Debug\AdatumCorporation.Utility.Templates.1.0.0.nupkg'.

A continuación, instale el archivo del paquete de plantillas con el comando dotnet new -i PATH_TO_NUPKG_FILE .

C:\working> dotnet new -i C:\working\bin\Debug\AdatumCorporation.Utility.Templates.1.0.0.nupkg

Usage: new [options]

Options:
-h, --help Displays help for this command.
-l, --list Lists templates containing the specified name. If no name is specified, lists all
templates.

... cut to save space ...

Templates Short Name Language Tags

--------------------------------------------------------------------------------------------------------------
-----------------
Example templates: string extensions stringext [C#] Common/Code
Console Application console [C#], F#, VB Common/Console
Example templates: async project consoleasync [C#] Common/Console/C#8
Class library classlib [C#], F#, VB Common/Library

Si cargó el paquete de NuGet en una fuente NuGet, puede usar el comando dotnet new -i PACKAGEID , donde
PACKAGEID es igual que el valor <PackageId> del archivo .csproj. Este identificador de paquete es igual que el
identificador del paquete de NuGet.

Desinstalación del paquete de plantillas

Independientemente de cómo instaló el paquete de plantillas, ya sea directamente con el archivo .nupkg o
mediante la fuente NuGet, el proceso de quitar un paquete de plantillas es el mismo. Use el <PackageId> de la
plantilla que quiere desinstalar. Ejecute el comando dotnet new -u para ver una lista de las plantillas que están
instaladas.

dotnet new -u
 Template Instantiation Commands for .NET Core CLI

Currently installed items:

Microsoft.DotNet.Common.ItemTemplates
Templates:
dotnet gitignore file (gitignore)
global.json file (globaljson)
NuGet Config (nugetconfig)
Solution File (sln)
Dotnet local tool manifest file (tool-manifest)
Web Config (webconfig)

... cut to save space ...

NUnit3.DotNetNew.Template
Templates:
NUnit 3 Test Project (nunit) C#
NUnit 3 Test Item (nunit-test) C#
NUnit 3 Test Project (nunit) F#
NUnit 3 Test Item (nunit-test) F#
NUnit 3 Test Project (nunit) VB
NUnit 3 Test Item (nunit-test) VB
AdatumCorporation.Utility.Templates
Templates:
Example templates: async project (consoleasync) C#
Example templates: string extensions (stringext) C#

Ejecute dotnet new -u AdatumCorporation.Utility.Templates para desinstalar la plantilla. El comando dotnet new
generará información de ayuda sobre que debe omitir las plantillas que instaló previamente.
¡Enhorabuena! Ya instaló y desinstaló un paquete de plantillas.

Pasos siguientes
Para más información sobre las plantillas, que en gran parte ya conoce, consulte el artículo Plantillas
personalizadas para dotnet new.
Wiki del repositorio de GitHub dotnet/templating
Repositorio de GitHub dotnet/dotnet-template-samples
Esquema template.json en el Almacenamiento del esquema JSON
 SDK de proyectos de .NET
02/11/2020 • 12 minutes to read • Edit Online

Los proyectos de .NET Core y .NET 5.0 y posteriores están asociados a un kit de desarrollo de software (SDK). Cada
SDK de proyecto es un conjunto de destinos de MSBuild y tareas asociadas que se encarga de compilar,
empaquetar y publicar código. Un proyecto que hace referencia a un SDK de proyecto en ocasiones se denomina
proyecto de estilo SDK.

SDK disponibles
Están disponibles los siguientes SDK:

ID DESC RIP C IÓ N REP O SITO RIO

Microsoft.NET.Sdk SDK de .NET https://github.com/dotnet/sdk

Microsoft.NET.Sdk.Web SDK web de .NET https://github.com/dotnet/sdk

Microsoft.NET.Sdk.Razor SDK de Razor de .NET

Microsoft.NET.Sdk.Worker SDK del servicio de trabajo de .NET

Microsoft.NET.Sdk.WindowsDesktop SDK de WinForms y WPF* https://github.com/dotnet/winforms y

https://github.com/dotnet/wpf

El SDK de .NET es el SDK base para .NET. Los otros SDK hacen referencia al SDK de .NET, y los proyectos asociados
a los demás SDK disponen de todas las propiedades del SDK de .NET. El SDK web, por ejemplo, depende de los SDK
de .NET y de Razor.
También puede crear un SDK propio que se puede distribuir a través de NuGet.
* A partir de .NET 5.0, los proyectos de Windows Forms y Windows Presentation Foundation (WPF) deben
especificar el SDK de .NET ( Microsoft.NET.Sdk ) en lugar de Microsoft.NET.Sdk.WindowsDesktop . Para estos
proyectos, al establecer TargetFramework en net5.0-windows y UseWPF o UseWindowsForms en true , se importará
automáticamente el SDK de escritorio de Windows. Si el proyecto tiene como destino .NET 5.0 o versiones
posteriores y especifica el SDK de Microsoft.NET.Sdk.WindowsDesktop , obtendrá la advertencia de compilación
NETSDK1137.

Archivos de proyecto
Los proyectos de .NET se basan en el formato MSBuild. Los archivos de proyecto, que tienen extensiones como
.csproj para los proyectos de C# y .fsproj para los de F#, están en formato XML. El elemento raíz de un archivo de
proyecto de MSBuild es Project. El elemento Project tiene un atributo Sdk opcional que especifica qué SDK (y
versión) se van a usar. Para usar las herramientas de .NET y compilar el código, establezca el atributo Sdk en uno
de los identificadores de la tabla SDK disponibles.

<Project Sdk="Microsoft.NET.Sdk">
...
</Project>
Para especificar un SDK que proviene de NuGet, incluya la versión al final del nombre, o bien especifique el
nombre y la versión en el archivo global.json.

<Project Sdk="MSBuild.Sdk.Extras/2.0.54">
...
</Project>

Otra manera de especificar el SDK es mediante el elemento Sdk de nivel superior:

<Project>
<Sdk Name="Microsoft.NET.Sdk" />
...
</Project>

Al hacer referencia a un SDK de una de estas formas, se simplifican enormemente los archivos de proyecto de .NET.
Durante la evaluación del proyecto, MSBuild agrega importaciones implícitas para Sdk.props en la parte superior
del archivo del proyecto y para Sdk.targets en la inferior.

<Project>
<!-- Implicit top import -->
<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />
...
<!-- Implicit bottom import -->
<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

TIP
En un equipo con Windows, los archivos Sdk.props y Sdk.targets se pueden encontrar en la carpeta
%ProgramFiles%\dotnet\sdk\[versión]\Sdks\Microsoft.NET.Sdk\Sdk.

Procesamiento previo del archivo del proyecto

Puede ver el proyecto totalmente expandido como MSBuild lo ve después de incluir el SDK y sus destinos
mediante el comando dotnet msbuild -preprocess . El conmutador preprocess del comando dotnet msbuild
muestra qué archivos se han importado, sus orígenes y sus contribuciones a la compilación sin tener que compilar
el proyecto realmente.
Si el proyecto tiene varias plataformas de destino, para centrar los resultados del comando en una sola, debe
especificarla como una propiedad de MSBuild. Por ejemplo:
dotnet msbuild -property:TargetFramework=netcoreapp2.0 -preprocess:output.xml

Inclusiones de compilación predeterminadas

Las inclusiones y exclusiones predeterminadas de los elementos de compilación, los recursos insertados y los
elementos None se definen en el SDK. A diferencia de los proyectos de .NET Framework que no son de SDK, no es
necesario especificar estos elementos en el archivo del proyecto, ya que los valores predeterminados cubren los
casos de uso más comunes. Como resultado, el archivo de proyecto es más pequeño y más fácil de entender y
editar manualmente, si es necesario.
En la tabla siguiente se muestra qué elementos y qué globs se incluyen y excluyen en el SDK de .NET:

EL EM EN TO GLO B PA RA IN C L UIR GLO B PA RA EXC L UIR GLO B PA RA Q UITA R

 EL EM EN TO GLO B PA RA IN C L UIR GLO B PA RA EXC L UIR GLO B PA RA Q UITA R

Compile **/*.cs (u otras extensiones **/*.user; **/*.*proj; **/*.sln; N/D

de lenguaje) **/*.vssscc

EmbeddedResource **/*.resx **/*.user; **/*.*proj; **/*.sln; N/D

**/*.vssscc

None **/* **/*.user; **/*.*proj; **/*.sln; **/*.cs; **/*.resx

**/*.vssscc

NOTE
De forma predeterminada, las carpetas ./bin y ./obj (representadas por las propiedades de MSBuild
$(BaseOutputPath) y $(BaseIntermediateOutputPath) ) se excluyen de los globs. Las exclusiones se representan por
medio de la propiedad $(DefaultItemExcludes) .

Errores de compilación
Si define explícitamente cualquiera de estos elementos en el archivo del proyecto, es probable que obtenga un
error de compilación "NETSDK1022" similar al siguiente:

Se han incluido elementos de compilación duplicados. El SDK de .NET incluye elementos de compilación del
directorio del proyecto de forma predeterminada. Puede quitar estos elementos del archivo de proyecto o
establecer la propiedad “EnableDefaultCompileItems” en “false” si quiere incluirlos explícitamente en el archivo
del proyecto.

Se incluyeron elementos "EmbeddedResource" duplicados. El SDK de .NET incluye elementos

"EmbeddedResource" del directorio del proyecto de forma predeterminada. Puede quitar estos elementos del
archivo del proyecto, o bien establecer la propiedad "EnableDefaultEmbeddedResourceItems" en "false" si
quiere incluirlos en él de forma explícita.

Para resolver los errores, lleve a cabo una de las siguientes acciones:
Quite los elementos Compile , EmbeddedResource o None explícitos que coincidan con los implícitos
enumerados en la tabla anterior.
Establezca la propiedad EnableDefaultItems en false para deshabilitar toda la inclusión de archivos
implícita:

<PropertyGroup>
<EnableDefaultItems>false</EnableDefaultItems>
</PropertyGroup>

Si quiere especificar que se publiquen archivos con la aplicación, puede seguir usando los mecanismos de
MSBuild conocidos para ello, por ejemplo, el elemento Content .
Deshabilite de forma selectiva solo los globs Compile , EmbeddedResource o None estableciendo la
propiedad EnableDefaultCompileItems , EnableDefaultEmbeddedResourceItems o EnableDefaultNoneItems en
false :
 <PropertyGroup>
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
<EnableDefaultEmbeddedResourceItems>false</EnableDefaultEmbeddedResourceItems>
<EnableDefaultNoneItems>false</EnableDefaultNoneItems>
</PropertyGroup>

Si solo deshabilita los globs Compile , el Explorador de soluciones de Visual Studio sigue mostrando
elementos *.cs como parte del proyecto, incluidos como elementos None . Para deshabilitar el glob None
implícito, establezca EnableDefaultNoneItems en false .

Personalización de la compilación
Hay varias maneras de personalizar una compilación. Es posible que quiera invalidar una propiedad y pasarla
como argumento a un comando msbuild o dotnet. También puede agregar la propiedad al archivo del proyecto o a
un archivo Directory.Build.props. Para obtener una lista de propiedades útiles para los proyectos de .NET, consulte
Referencia de MSBuild para proyectos de SDK de .NET.
Destinos personalizados
Los proyectos de .NET pueden empaquetar propiedades y destinos de MSBuild personalizados para su uso en
proyectos que consuman el paquete. Use este tipo de extensibilidad cuando quiera:
Extender el proceso de compilación.
Acceder a artefactos del proceso de compilación, como los archivos generados.
Inspeccionar una configuración en la que se va a invocar la compilación.
Para agregar propiedades o destinos de compilación personalizados, coloque los archivos con el formato
<package_id>.targets o <package_id>.props (por ejemplo, Contoso.Utility.UsefulStuff.targets ) en la carpeta
build del proyecto.
El fragmento de código XML siguiente es de un archivo .csproj que indica al comando dotnet pack lo que debe
empaquetar. El elemento <ItemGroup Label="dotnet pack instructions"> coloca los archivos de destino en la
carpeta build dentro del paquete. El elemento
<Target Name="CollectRuntimeOutputs" BeforeTargets="_GetPackageFiles"> coloca los ensamblados y los archivos
.json en la carpeta build.

<Project Sdk="Microsoft.NET.Sdk">

...
<ItemGroup Label="dotnet pack instructions">
<Content Include="build\*.targets">
<Pack>true</Pack>
<PackagePath>build\</PackagePath>
</Content>
</ItemGroup>
<Target Name="CollectRuntimeOutputs" BeforeTargets="_GetPackageFiles">
<!-- Collect these items inside a target that runs after build but before packaging. -->
<ItemGroup>
<Content Include="$(OutputPath)\*.dll;$(OutputPath)\*.json">
<Pack>true</Pack>
<PackagePath>build\</PackagePath>
</Content>
</ItemGroup>
</Target>
...

</Project>
Para consumir un destino personalizado en el proyecto, agregue un elemento PackageReference que apunte al
paquete y su versión. A diferencia de las herramientas, el paquete de destinos personalizados se incluye en el
cierre de dependencia del proyecto que lo usa.
Puede configurar cómo se usa el destino personalizado. Como es un destino de MSBuild, puede depender de un
destino concreto, ejecutarse después de otro destino o bien invocarse de forma manual mediante el comando
dotnet msbuild -t:<target-name> . Pero para proporcionar una mejor experiencia de usuario, puede combinar las
herramientas y los destinos personalizados por proyecto. En este escenario, la herramienta por proyecto acepta los
parámetros necesarios y los traduce en la invocación de dotnet msbuild necesaria que ejecuta el destino. Puede
ver una muestra de esta clase de sinergia en el repositorio de ejemplos de MVP Summit 2016 Hackathon del
proyecto dotnet-packer .

Vea también
Instalación de .NET Core
Procedimiento para usar los SDK de proyecto de MSBuild
Empaquetado de destinos y propiedades de MSBuild personalizados con NuGet
 Referencia de MSBuild para proyectos del SDK de
.NET
18/12/2020 • 21 minutes to read • Edit Online

Esta página es una referencia de las propiedades y los elementos de MSBuild que puede usar para configurar
proyectos de .NET.

NOTE
Esta página es un trabajo en curso y no muestra todas las propiedades de MSBuild útiles para el SDK de .NET. Para obtener
una lista de las propiedades comunes de MSBuild, vea Propiedades comunes de MSBuild.

Propiedades del marco de trabajo

TargetFramework
TargetFrameworks
NetStandardImplicitPackageVersion
TargetFramework
La propiedad TargetFramework especifica la versión de la plataforma de destino de la aplicación. Para obtener una
lista de los monikers de plataforma de destino válidos, vea Plataformas de destino en proyectos de estilo SDK.

<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

Para obtener más información, vea Plataformas de destino en proyectos de estilo SDK.
TargetFrameworks
Use la propiedad TargetFrameworks cuando quiera que la aplicación tenga varias plataformas como destino. Para
obtener una lista de los monikers de plataforma de destino válidos, vea Plataformas de destino en proyectos de
estilo SDK.

NOTE
Esta propiedad se omite si se especifica TargetFramework (singular).

<PropertyGroup>
<TargetFrameworks>netcoreapp3.1;net462</TargetFrameworks>
</PropertyGroup>

Para obtener más información, vea Plataformas de destino en proyectos de estilo SDK.
NetStandardImplicitPackageVersion
 NOTE
Esta propiedad solo se aplica a los proyectos que usan netstandard1.x . No se aplica a los que usan netstandard2.x .

Use la propiedad NetStandardImplicitPackageVersion si quiere especificar una versión del marco que sea inferior a
la de la versión del metapaquete. El archivo del proyecto del ejemplo siguiente tiene como destino netstandard1.3
pero usa la versión 1.6.0 de NETStandard.Library .

<PropertyGroup>
<TargetFramework>netstandard1.3</TargetFramework>
<NetStandardImplicitPackageVersion>1.6.0</NetStandardImplicitPackageVersion>
</PropertyGroup>

Propiedades del paquete

Puede especificar propiedades como PackageId , PackageVersion , PackageIcon , Title y Description para
describir el paquete que se crea a partir del proyecto. Para más información sobre estas y otras propiedades, vea
Destino de pack.

<PropertyGroup>
...
<PackageId>ClassLibDotNetStandard</PackageId>
<Version>1.0.0</Version>
<Authors>John Doe</Authors>
<Company>Contoso</Company>
</PropertyGroup>

Publicación de propiedades y elementos

CopyLocalLockFileAssemblies
RuntimeIdentifier
RuntimeIdentifiers
TrimmerRootAssembly
UseAppHost
CopyLocalLockFileAssemblies
La propiedad CopyLocalLockFileAssemblies es útil para los proyectos de complementos que tienen dependencias
de otras bibliotecas. Si establece esta propiedad en true , todas las dependencias de paquetes NuGet se copian en
el directorio de salida. Esto significa que puede usar la salida de dotnet build para ejecutar el complemento en
cualquier equipo.

<PropertyGroup>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>

TIP
Como alternativa, puede usar dotnet publish para publicar la biblioteca de clases. Para obtener más información, vea
dotnet publish.

RuntimeIdentifier
La propiedad RuntimeIdentifier permite especificar un único identificador de tiempo de ejecución (RID) para el
proyecto. El RID permite publicar una implementación autocontenida.

<PropertyGroup>
<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
</PropertyGroup>

RuntimeIdentifiers
La propiedad RuntimeIdentifiers permite especificar una lista delimitada por puntos y coma de identificadores de
tiempo ejecución (RID) para el proyecto. Use esta propiedad si tiene que publicar para varios entornos de
ejecución. RuntimeIdentifiers se usa en el momento de la restauración para asegurarse de que los recursos
adecuados están en el gráfico.

TIP
RuntimeIdentifier (singular) puede proporcionar compilaciones más rápidas cuando solo se requiere un entorno de
ejecución.

<PropertyGroup>
<RuntimeIdentifiers>win10-x64;osx.10.11-x64;ubuntu.16.04-x64</RuntimeIdentifiers>
</PropertyGroup>

TrimmerRootAssembly
El elemento TrimmerRootAssembly permite excluir del recorte un ensamblado. El recorte es el proceso de quitar de
una aplicación empaquetada las partes que no se han usado del tiempo de ejecución. En algunos casos, el recorte
podría quitar de forma incorrecta las referencias necesarias.
El siguiente código XML excluye del recorte el ensamblado System.Security .

<ItemGroup>
<TrimmerRootAssembly Include="System.Security" />
</ItemGroup>

UseAppHost
La propiedad UseAppHost controla si se crea o no un archivo ejecutable nativo para una implementación. Un
archivo ejecutable nativo es obligatorio para las implementaciones independientes.
En .NET Core 3.0 y versiones posteriores, se crea de forma predeterminada un ejecutable dependiente del marco
de trabajo. Establezca la propiedad UseAppHost en false para deshabilitar la generación del archivo ejecutable.

<PropertyGroup>
<UseAppHost>false</UseAppHost>
</PropertyGroup>

Para más información sobre la implementación, consulte Implementación de aplicaciones .NET.

Propiedades de compilación
EmbeddedResourceUseDependentUponConvention
LangVersion
EmbeddedResourceUseDependentUponConvention
La propiedad EmbeddedResourceUseDependentUponConvention define si los nombres del archivo de manifiesto del
recurso se generan a partir de la información de tipo de los archivos de código fuente que se ubican
conjuntamente con archivos de recursos. Por ejemplo, si Form1.resx está en la misma carpera que Form1.cs, y
EmbeddedResourceUseDependentUponConvention se establece en true , el archivo .resources generado toma su
nombre del primer tipo que se define en Form1.cs. Por ejemplo, si MyNamespace.Form1 es el primer tipo definido en
Form1.cs, el nombre de archivo generado es myNameSpace.Form1.Resources.

NOTE
Si se especifican los metadatos LogicalName , ManifestResourceName o DependentUpon para un elemento
EmbeddedResource , el nombre del archivo de manifiesto generado para ese archivo de recurso se basa en esos metadatos.

De forma predeterminada, en un nuevo proyecto de .NET, esta propiedad se establece en true . Si se establece en
false y no se especifica ningún metadato LogicalName , ManifestResourceName o DependentUpon para el elemento
EmbeddedResource del archivo de proyecto, el nombre del archivo de manifiesto del recurso se basa en el espacio
de nombres raíz del proyecto y en la ruta de acceso relativa al archivo .resx. Para más información, consulte
Denominación de los archivos de manifiesto de recurso.

<PropertyGroup>
<EmbeddedResourceUseDependentUponConvention>true</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

LangVersion
La propiedad LangVersion permite especificar una versión concreta del lenguaje de programación. Por ejemplo, si
quiere acceder a las características en vista previa de C#, establezca LangVersion en preview .

<PropertyGroup>
<LangVersion>preview</LangVersion>
</PropertyGroup>

Para obtener más información, vea Control de versiones del lenguaje C#.

Propiedades de análisis de código

AnalysisLevel
La propiedad AnalysisLevel permite especificar un nivel de análisis de código. Por ejemplo, si quiere acceder a la
versión preliminar de los analizadores de código, establezca AnalysisLevel en preview . El valor predeterminado
es latest .

<PropertyGroup>
<AnalysisLevel>preview</AnalysisLevel>
</PropertyGroup>

En la siguiente tabla se muestran las opciones disponibles.

VA L UE SIGN IF IC A DO

latest Se usan los analizadores de código que se han publicado más

recientemente. Este es el valor predeterminado.
 VA L UE SIGN IF IC A DO

preview Se usan los analizadores de código más recientes, incluso si

están en versión preliminar.

5.0 Se usa el conjunto de reglas que se habilitó para .NET 5,0,

incluso si hay reglas más recientes disponibles.

5 Se usa el conjunto de reglas que se habilitó para .NET 5,0,

incluso si hay reglas más recientes disponibles.

AnalysisMode
A partir de .NET 5.0, el SDK de .NET incluye todas las reglas "CA" de calidad del código. De forma predeterminada,
solo algunas reglas están habilitadas como advertencias de compilación. La propiedad AnalysisMode le permite
personalizar el conjunto de reglas que están habilitadas de forma predeterminada. Puede cambiar a un modo de
análisis más agresivo (exclusión) o a uno más conservador (inclusión). Por ejemplo, si quiere habilitar todas las
reglas de forma predeterminada como advertencias de compilación, establezca el valor en AllEnabledByDefault .

<PropertyGroup>
<AnalysisMode>AllEnabledByDefault</AnalysisMode>
</PropertyGroup>

En la siguiente tabla se muestran las opciones disponibles.

VA L UE SIGN IF IC A DO

Default Modo predeterminado, en el que ciertas reglas están

habilitadas como advertencias de compilación, otras están
habilitadas como sugerencias del IDE de Visual Studio y el
resto están deshabilitadas.

AllEnabledByDefault Modo agresivo o de exclusión, en el que todas las reglas están

habilitadas de forma predeterminada como advertencias de
compilación. Puede excluir de forma selectiva reglas
individuales para deshabilitarlas.

AllDisabledByDefault Modo conservador o de inclusión, en el que todas las reglas

están deshabilitadas de forma predeterminada. Puede incluir
de forma selectiva reglas individuales para habilitarlas.

CodeAnalysisTreatWarningsAsErrors
La propiedad CodeAnalysisTreatWarningsAsErrors le permite configurar si las advertencias de análisis de calidad del
código (CAxxxx) se deben tratar como advertencias e interrumpir la compilación. Si usa la marca -warnaserror al
compilar los proyectos, las advertencias de análisis de calidad del código de .NET también se tratan como errores.
Si no quiere que las advertencias de análisis de calidad del código se traten como errores, puede establecer la
propiedad CodeAnalysisTreatWarningsAsErrors de MSBuild en false en el archivo del proyecto.

<PropertyGroup>
<CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarningsAsErrors>
</PropertyGroup>

EnableNETAnalyzers
De forma predeterminada, el análisis de calidad del código de .NET está habilitado para los proyectos que tienen
como destino .NET 5.0 o una versión posterior. Puede habilitar el análisis de código de .NET para los proyectos que
tienen como destino versiones anteriores de .NET estableciendo la propiedad EnableNETAnalyzers en true . Para
deshabilitar el análisis de código en cualquier proyecto, establezca esta propiedad en false .

<PropertyGroup>
<EnableNETAnalyzers>true</EnableNETAnalyzers>
</PropertyGroup>

TIP
Otra forma de habilitar el análisis de código de .NET en proyectos que tienen como destino versiones de .NET anteriores a
.NET 5.0 es establecer la propiedad AnalysisLevel en latest .

EnforceCodeStyleInBuild

NOTE
En la actualidad, esta característica es experimental y puede cambiar entre las versiones .NET 5 y .NET 6.

El análisis del estilo del código de .NET está deshabilitado de forma predeterminada en la compilación para todos
los proyectos de .NET. Puede habilitar el análisis del estilo del código para los proyectos de .NET estableciendo la
propiedad EnforceCodeStyleInBuild en true .

<PropertyGroup>
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
</PropertyGroup>

Todas las reglas de estilo del código configuradas como advertencias o errores se ejecutarán en la compilación y
notificarán infracciones.

Propiedades de configuración del tiempo de ejecución

Puede configurar algunos comportamientos del tiempo de ejecución si especifica las propiedades de MSBuild en el
archivo de proyecto de la aplicación. Para obtener información sobre otras formas de configurar el
comportamiento del tiempo de ejecución, consulte Opciones de configuración en tiempo de ejecución de .NET
Core.
ConcurrentGarbageCollection
InvariantGlobalization
RetainVMGarbageCollection
ServerGarbageCollection
ThreadPoolMaxThreads
ThreadPoolMinThreads
TieredCompilation
TieredCompilationQuickJit
TieredCompilationQuickJitForLoops
ConcurrentGarbageCollection
La propiedad ConcurrentGarbageCollection configura si está habilitada la recolección de elementos no utilizados en
segundo plano (simultánea). Establezca el valor en false para deshabilitar la recolección de elementos no
utilizados en segundo plano. Para obtener más información, vea Recolección de elementos no utilizados en
segundo plano.
 <PropertyGroup>
<ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>
</PropertyGroup>

InvariantGlobalization
La propiedad InvariantGlobalization configura si la aplicación se ejecuta en modo invariable de globalización, lo
que significa que no tiene acceso a datos específicos de la referencia cultural. Establezca el valor en true para
ejecutar en el modo invariable de globalización. Para obtener más información, consulte Modo invariable.

<PropertyGroup>
<InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

RetainVMGarbageCollection
La propiedad RetainVMGarbageCollection configura el recolector de elementos no utilizados para colocar los
segmentos de memoria eliminados en una lista en espera para su uso futuro o para liberarlos. Al establecer el
valor en true , se indica al recolector de elementos no utilizados que coloque los segmentos en una lista en
espera. Para obtener más información, vea Retain VM (Conservar VM).

<PropertyGroup>
<RetainVMGarbageCollection>true</RetainVMGarbageCollection>
</PropertyGroup>

ServerGarbageCollection
La propiedad ServerGarbageCollection configura si la aplicación usa la recolección de elementos no utilizados de
estación de trabajo o la de servidor. Establezca el valor en true para usar la recolección de elementos no
utilizados de servidor. Para obtener más información, vea Estación de trabajo frente a servidor.

<PropertyGroup>
<ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>

ThreadPoolMaxThreads
La propiedad ThreadPoolMaxThreads configura el número máximo de subprocesos para el grupo de subprocesos
de trabajo. Para obtener más información, consulte Máximo de subprocesos.

<PropertyGroup>
<ThreadPoolMaxThreads>20</ThreadPoolMaxThreads>
</PropertyGroup>

ThreadPoolMinThreads
La propiedad ThreadPoolMinThreads configura el número mínimo de subprocesos para el grupo de subprocesos de
trabajo. Para obtener más información, consulte Mínimo de subprocesos.

<PropertyGroup>
<ThreadPoolMinThreads>4</ThreadPoolMinThreads>
</PropertyGroup>

TieredCompilation
La propiedad TieredCompilation configura si el compilador Just-In-Time (JIT) usa la compilación en niveles.
Establezca el valor en false para deshabilitar la compilación en niveles. Para obtener más información, vea
Compilación en niveles.

<PropertyGroup>
<TieredCompilation>false</TieredCompilation>
</PropertyGroup>

TieredCompilationQuickJit
La propiedad TieredCompilationQuickJit configura si el compilador JIT usa JIT rápido. Establezca el valor en false
para deshabilitar JIT rápido. Para obtener más información, vea JIT rápido.

<PropertyGroup>
<TieredCompilationQuickJit>false</TieredCompilationQuickJit>
</PropertyGroup>

TieredCompilationQuickJitForLoops
La propiedad TieredCompilationQuickJitForLoops configura si el compilador JIT usa JIT rápido en métodos que
contienen bucles. Establezca el valor en true para habilitar JIT rápido en métodos que contienen bucles. Para
obtener más información, vea JIT rápido para bucles.

<PropertyGroup>
<TieredCompilationQuickJitForLoops>true</TieredCompilationQuickJitForLoops>
</PropertyGroup>

Referencia de propiedades y elementos

AssetTargetFallback
PackageReference
ProjectReference
Referencia
Propiedades relacionadas con la restauración
AssetTargetFallback
La propiedad AssetTargetFallback permite especificar versiones de la plataforma compatibles adicionales para las
referencias de proyectos y los paquetes NuGet. Por ejemplo, si se especifica una dependencia de paquete mediante
PackageReference pero ese paquete no contiene recursos compatibles con el valor TargetFramework del proyecto,
entra en juego la propiedad AssetTargetFallback . La compatibilidad del paquete al que se hace referencia se
vuelve a comprobar con cada plataforma de destino que se especifica en AssetTargetFallback .
Puede establecer la propiedad AssetTargetFallback en una o varias versiones de plataforma de destino.

<PropertyGroup>
<AssetTargetFallback>net461</AssetTargetFallback>
</PropertyGroup>

PackageReference
El elemento PackageReference define una referencia a un paquete NuGet.
El atributo Include especifica el identificador del paquete. El atributo Version especifica la versión o el intervalo
de versiones. Para obtener más información sobre cómo especificar una versión mínima, una máxima, un intervalo
o una coincidencia exacta, vea Intervalos de versiones. También puede agregar los metadatos IncludeAssets ,
ExcludeAssets y PrivateAssets a una referencia de proyecto.
El fragmento del archivo del proyecto del ejemplo siguiente hace referencia al paquete System.Runtime.

<ItemGroup>
<PackageReference Include="System.Runtime" Version="4.3.0" />
</ItemGroup>

Para obtener más información, vea Referencias de paquete en un archivo del proyecto.
ProjectReference
El elemento ProjectReference define una referencia a otro proyecto. El proyecto al que se hace referencia se
agrega como una dependencia del paquete NuGet, es decir, se trata como PackageReference .
El atributo Includeespecifica la ruta de acceso al proyecto. También puede agregar los metadatos IncludeAssets ,
ExcludeAssets y PrivateAssets a una referencia de proyecto.
El fragmento del archivo de proyecto de este ejemplo hace referencia a un proyecto denominado Project2 .

<ItemGroup>
<ProjectReference Include="..\Project2.csproj" />
</ItemGroup>

Referencia
El elemento Reference define una referencia a un archivo de ensamblado.
El atributo Include especifica el nombre del archivo y los metadatos HintPath especifican la ruta de acceso al
ensamblado.

<ItemGroup>
<Reference Include="MyAssembly">
<HintPath>..\..\Assemblies\MyAssembly.dll</HintPath>
</Reference>
</ItemGroup>

Propiedades relacionadas con la restauración

La restauración de un paquete al que se hace referencia instala todas sus dependencias directas y todas las
dependencias de esas dependencias. Puede personalizar la restauración de paquetes especificando propiedades
como RestorePackagesPath y RestoreIgnoreFailedSources . Para más información sobre estas y otras propiedades,
vea Destino de restore.

<PropertyGroup>
<RestoreIgnoreFailedSource>true</RestoreIgnoreFailedSource>
</PropertyGroup>

Propiedades y elementos de hospedaje

EnableComHosting
EnableDynamicLoading
EnableComHosting
La propiedad EnableComHosting indica que un ensamblado proporciona un servidor COM. Al establecer
EnableComHosting en true también implica que EnableDynamicLoading es true .
 <PropertyGroup>
<EnableComHosting>True</EnableComHosting>
</PropertyGroup>

Para obtener más información, vea Exposición de componentes de .NET en COM.

EnableDynamicLoading
La propiedad EnableDynamicLoading indica que un ensamblado es un componente cargado dinámicamente. El
componente podría ser una biblioteca de COM o una biblioteca que no es de COM que se puede usar desde un
host nativo. Establecer esta propiedad en true tiene los efectos siguientes:
Se genera un archivo runtimeconfig.json.
La puesta al día se establece en LatestMinor .
Las referencias de NuGet se copian localmente.

<PropertyGroup>
<EnableDynamicLoading>true</EnableDynamicLoading>
</PropertyGroup>

Vea también
Referencia del esquema de MSBuild
Propiedades comunes de MSBuild
Propiedades de MSBuild para pack de NuGet
Propiedades de MSBuild para restore de NuGet
Personalización de una compilación
 Plataformas de destino en proyectos de
estilo SDK
18/12/2020 • 14 minutes to read • Edit Online

Cuando se dirige a un marco en una aplicación o biblioteca, debe especificar el conjunto de

API que quiere poner a disposición de la aplicación o biblioteca. La plataforma de destino se
especifica en el archivo del proyecto mediante un moniker de la plataforma de destino (TFM).
Una aplicación o biblioteca puede tener como destino una versión de .NET Standard. Las
versiones de .NET Standard representan conjuntos estandarizados de API en todas las
implementaciones de .NET. Por ejemplo, una biblioteca puede tener como destino .NET
Standard 1.6 y obtener acceso a las API que funcionan en .NET Core y .NET Framework con el
mismo código base.
Una aplicación o biblioteca también puede tener como destino una implementación específica
de .NET para obtener acceso a las API específicas de la implementación. Por ejemplo, una
aplicación que tenga como destino Xamarin.iOS (por ejemplo, Xamarin.iOS10 ) tiene acceso a
contenedores de API de iOS proporcionados por Xamarin para iOS 10, o una aplicación que
tenga como destino la Plataforma universal de Windows (UWP, uap10.0 ) tiene acceso a las
API que compilan para dispositivos que ejecutan Windows 10.
Para algunas plataformas de destino (por ejemplo, .NET Framework), las API se definen
mediante los ensamblados que la plataforma instala en un sistema y pueden incluir API del
marco de trabajo de la aplicación (por ejemplo, ASP.NET).
Para plataformas de destino basadas en paquetes (por ejemplo, .NET 5, .NET Standard y
.NET Core), las API se definen mediante los paquetes incluidos en la aplicación o biblioteca. Un
metapaquete es un paquete de NuGet que no tiene contenido propio, pero que es una lista de
dependencias (otros paquetes). Una plataforma de destino basada en paquetes de NuGet
especifica implícitamente un metapaquete que hace referencia a todos los paquetes que
forman el marco de trabajo.

Últimas versiones
En la tabla siguiente se definen las plataformas de destino más comunes, cómo se hace
referencia a ellas y la versión de .NET Standard que implementan. Estas versiones de
plataformas de destino son las últimas versiones estables. No se muestran las versiones
preliminares. Un moniker de la plataforma de destino (TFM) es un formato de token
normalizado para especificar la plataforma de destino de una aplicación o biblioteca de .NET.

M O N IK ER DE L A IM P L EM EN TA DO
L AT EST P L ATA F O RM A DE VERSIÓ N DE . N ET
M A RC O DE DEST IN O VERSIÓ N ESTA B L E DEST IN O ( T F M ) STA N DA RD

.NET 5 5.0 net5.0 N/D

.NET Standard 2.1 netstandard2.1 N/D

.NET Core 3.1 netcoreapp3.1 2.1

 M O N IK ER DE L A IM P L EM EN TA DO
L AT EST P L ATA F O RM A DE VERSIÓ N DE . N ET
M A RC O DE DEST IN O VERSIÓ N ESTA B L E DEST IN O ( T F M ) STA N DA RD

.NET Framework 4.8 net48 2.0

Plataformas de destino admitidas

Normalmente, un TFM hace referencia a una plataforma de destino. En la tabla siguiente, se
muestran las plataformas de destino compatibles con el SDK de .NET y el cliente de NuGet. Los
equivalentes se muestran entre corchetes. Por ejemplo, win81 es un TFM equivalente a
netcore451 .

VERSIÓ N DE . N ET F RA M EW O RK DE DEST IN O T FM

.NET 5 (y .NET Core) netcoreapp1.0

netcoreapp1.1
netcoreapp2.0
netcoreapp2.1
netcoreapp2.2
netcoreapp3.0
netcoreapp3.1
net5.0*

.NET Standard netstandard1.0

netstandard1.1
netstandard1.2
netstandard1.3
netstandard1.4
netstandard1.5
netstandard1.6
netstandard2.0
netstandard2.1

.NET Framework net11

net20
net35
net40
net403
net45
net451
net452
net46
net461
net462
net47
net471
net472
net48

Tienda Windows netcore [netcore45]

netcore45 [win] [win8]
netcore451 [win81]

.NET Micro Framework netmf

Silverlight sl4
sl5
 VERSIÓ N DE . N ET F RA M EW O RK DE DEST IN O T FM

Windows Phone wp [wp7]

wp7
wp75
wp8
wp81
wpa81

Plataforma universal de Windows uap [uap10.0]

uap10.0 [win10] [netcore50]

* Los TFM de.NET 5.0 y versiones posteriores incluyen variaciones específicas del sistema
operativo. Para obtener más información, consulte la sección TFM específicos del sistema
operativo de .NET 5.
TFM específicos del sistema operativo de .NET 5
Para cada TFM de.NET 5.0 y versiones posteriores, por ejemplo, net5.0 , hay variaciones de
TFM que incluyen enlaces específicos del sistema operativo. Estas variaciones se muestran en
la tabla siguiente:

F O RM ATO ESP EC ÍF IC O DEL SIST EM A O P ERAT IVO E JEM P LO

<base-tfm>-android net5.0-android

<base-tfm>-ios net5.0-ios

<base-tfm>-macos net5.0-macos

<base-tfm>-tvos net5.0-tvos

<base-tfm>-watchos net5.0-watchos

<base-tfm>-windows net5.0-windows

El TFM net5.0 solo incluye tecnologías que funcionan entre plataformas. La especificación de
un TFM particular del sistema operativo hace que las API concretas de un sistema operativo
estén disponibles para la aplicación, por ejemplo, Windows Forms o enlaces de iOS. Los TFM
específicos del sistema operativo también heredan todas las API disponibles para el TFM
net5.0 .

Para que la aplicación sea portable entre distintas plataformas, puede tener como destino
varios TFM específicos del sistema operativo y agregar restricciones de plataforma alrededor
de llamadas API específicas del sistema operativo mediante directivas de preprocesador #if .
En la tabla siguiente se muestra la compatibilidad de los TFM de .NET 5 con los de versiones
anteriores de .NET.

T FM C O M PAT IB L E C O N N OTA S
 T FM C O M PAT IB L E C O N N OTA S

net5.0 net1.4 (con la advertencia

NU1701)
netcoreapp1.3.1 (advertencia
cuando se hace referencia a
WinForms o WPF)
netstandard1.2.1

net5.0-android xamarin.android (más todo lo

demás heredado de net5.0 )

net5.0-ios xamarin.ios (más todo lo demás

heredado de net5.0 )

net5.0-macos xamarin.mac (más todo lo

demás heredado de net5.0 )

net5.0-tvos xamarin.tvos (más todo lo

demás heredado de net5.0 )

net5.0-watchos xamarin.watchos (más todo lo

demás heredado de net5.0 )

net5.0-windows netcoreapp1.3.1 (más todo lo Incluye las API de WinForms,

demás heredado de net5.0 ) WPF y UWP.
Para obtener información, vea
Llamada a las a API de
Windows Runtime en
aplicaciones de escritorio.

Destinos sugeridos
Siga estas instrucciones para determinar qué TFM usar en la aplicación:
Las aplicaciones que se pueden portar a varias plataformas deben tener como destino
net5.0 . Esto incluye la mayoría de las bibliotecas, pero también ASP.NET Core y Entity
Framework.
Las bibliotecas específicas de la plataforma deben tener como destino tipos específicos
de la plataforma. Por ejemplo, los proyectos de WinForms y WPF deben tener como
destino net5.0-windows .
Los modelos de aplicación multiplataforma (Xamarin Forms, ASP.NET Core) y los
paquetes puente (Xamarin Essentials) deben tener el destino net5.0 como mínimo,
pero también pueden otros tipos específicos de la plataforma para obtener más API o
características.
Versión del sistema operativo en los TFM
También puede especificar una versión opcional del sistema operativo al final del TFM, por
ejemplo, net5.0-ios13.0 , que indica qué API están disponibles para la aplicación. (El SDK de
.NET 5 se actualizará para incluir la compatibilidad con las versiones más recientes del sistema
operativo a medida que se publiquen). Para obtener acceso a las API recién publicadas,
incremente la versión del sistema operativo en el TFM. Todavía puede hacer que la aplicación
sea compatible con versiones anteriores del sistema operativo (y agregar restricciones. en
torno a las llamadas a API de versiones posteriores) si agrega el elemento
SupportedOSPlatformVersion al archivo del proyecto. El elemento SupportedOSPlatformVersion
indica la versión mínima del sistema operativo necesaria para ejecutar la aplicación.
Por ejemplo, el siguiente extracto de archivo del proyecto especifica que las API de iOS 14
están disponibles para la aplicación, pero se puede ejecutar en equipos con iOS 13 o versiones
posteriores.

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>net5.0-ios14.0</TargetFramework>
<SupportedOSPlatformVersion>13.0</SupportedOSPlatformVersion> (minimum os platform
version)
</PropertyGroup>

...

</Project>

Procedimiento para especificar una plataforma de destino

Las plataformas de destino se especifican en un archivo del proyecto. Cuando especifique una
única plataforma de destino, use el elemento TargetFramework. En el siguiente archivo de
proyecto de aplicación de consola se muestra cómo elegir como destino .NET 5.0:

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>

</Project>

Al especificar varias plataformas de destino, puede hacer referencia de forma condicional a

ensamblados para cada plataforma de destino. En el código, puede compilar de forma
condicional en esos ensamblados utilizando símbolos de preprocesador con lógica if-then-
else.
El siguiente proyecto de biblioteca tiene como destino las API de .NET Standard (
netstandard1.4 ) y de .NET Framework ( net40 y net45 ). Use el elemento TargetFrameworks
plural con varias plataformas de destino. Los atributos Condition incluyen paquetes
específicos de la implementación cuando se compila la biblioteca para los dos TFM de .NET
Framework:
 <Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFrameworks>netstandard1.4;net40;net45</TargetFrameworks>
</PropertyGroup>

<!-- Conditionally obtain references for the .NET Framework 4.0 target -->
<ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
<Reference Include="System.Net" />
</ItemGroup>

<!-- Conditionally obtain references for the .NET Framework 4.5 target -->
<ItemGroup Condition=" '$(TargetFramework)' == 'net45' ">
<Reference Include="System.Net.Http" />
<Reference Include="System.Threading.Tasks" />
</ItemGroup>

</Project>

Dentro de su aplicación o biblioteca, puede escribir código condicional mediante directivas de

preprocesador para compilar para cada plataforma de destino:

public class MyClass

{
static void Main()
{
#if NET40
Console.WriteLine("Target framework: .NET Framework 4.0");
#elif NET45
Console.WriteLine("Target framework: .NET Framework 4.5");
#else
Console.WriteLine("Target framework: .NET Standard 1.4");
#endif
}
}

El sistema de compilación es consciente de los símbolos de preprocesador que representan las

plataformas de destino que se muestran en la tabla Versiones compatibles de las plataformas
de destino cuando se usan proyectos de estilo SDK. Cuando use un símbolo que representa un
TFM de .NET Standard, .NET Core o .NET 5, reemplace los puntos y guiones por un carácter de
subrayado y cambie las letras minúsculas por mayúsculas (por ejemplo, el símbolo de
netstandard1.4 es NETSTANDARD1_4 ).

La lista completa de símbolos de preprocesador para plataformas de destino de .NET es la

siguiente:

VERSIO N ES DE . N ET F RA M EW O RK DE DEST IN O SÍM B O LO S

.NET Framework NETFRAMEWORK , NET48 , NET472 , NET471 ,

NET47 , NET462 , NET461 , NET46 , NET452 ,
NET451 , NET45 , NET40 , NET35 , NET20

.NET Standard NETSTANDARD , NETSTANDARD2_1 ,

NETSTANDARD2_0 , NETSTANDARD1_6 ,
NETSTANDARD1_5 , NETSTANDARD1_4 ,
NETSTANDARD1_3 , NETSTANDARD1_2 ,
NETSTANDARD1_1 , NETSTANDARD1_0
 VERSIO N ES DE . N ET F RA M EW O RK DE DEST IN O SÍM B O LO S

.NET 5 (y .NET Core) NET5_0 , NETCOREAPP , NETCOREAPP3_1 ,

NETCOREAPP3_0 , NETCOREAPP2_2 ,
NETCOREAPP2_1 , NETCOREAPP2_0 ,
NETCOREAPP1_1 , NETCOREAPP1_0

Plataformas de destino en desuso

Las siguientes plataformas de destino están en desuso. Los paquetes que tienen como destino
estas plataformas deben migrarse a los reemplazos indicados.

T F M EN DESUSO REP L A C EM EN T

aspnet50 netcoreapp
aspnetcore50
dnxcore50
dnx
dnx45
dnx451
dnx452

dotnet netstandard
dotnet50
dotnet51
dotnet52
dotnet53
dotnet54
dotnet55
dotnet56

netcore50 uap10.0

win netcore45

win8 netcore45

win81 netcore451

win10 uap10.0

winrt netcore45

Vea también
Nombres de plataformas de destino en .NET 5
Desarrollo de bibliotecas con herramientas multiplataforma
.NET Standard
Control de versiones de .NET Core
Repositorio de GitHub dotnet/standard
Repositorio de GitHub de herramientas de NuGet
Framework Profiles in .NET (Perfiles de marco de trabajo en .NET)
Analizador de compatibilidad de plataformas
 Adiciones al formato csproj para .NET Core
02/11/2020 • 32 minutes to read • Edit Online

En este documento se describen los cambios que se han agregado a los archivos de proyecto como parte del cambio
de project.json a csproj y MSBuild. Para obtener más información sobre la sintaxis y la referencia del archivo de
proyecto general, consulte la documentación del archivo de proyecto de MSBuild.

Referencias implícitas del paquete

Se hace una referencia implícita a los metapaquetes basándose en los marcos de trabajo de destino especificados en
la propiedad <TargetFramework> o <TargetFrameworks> del archivo del proyecto. <TargetFrameworks> se ignora si
<TargetFramework> se especifica, independientemente del orden.

<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

<PropertyGroup>
<TargetFrameworks>netcoreapp3.1;net462</TargetFrameworks>
</PropertyGroup>

Recomendaciones
Como se hace referencia implícitamente a los metapaquetes Microsoft.NETCore.App o NETStandard.Library , estos
son los procedimientos recomendados:
Si el destino es .NET Core o .NET Standard, nunca incluya una referencia explícita a los metapaquetes
Microsoft.NETCore.App o NETStandard.Library mediante un elemento <PackageReference> en el archivo de
proyecto.
Si necesita una versión concreta del runtime cuando el destino es .NET Core, debe usar la propiedad
<RuntimeFrameworkVersion> del proyecto (por ejemplo, 1.0.4 ) en lugar de hacer referencia al metapaquete.
Esto puede ocurrir si está usando implementaciones autocontenidas y necesita una versión de revisión
específica del tiempo de ejecución de LTS 1.0.0, por ejemplo.
Si necesita una versión concreta del metapaquete NETStandard.Library cuando el destino es .NET Standard, puede
usar la propiedad <NetStandardImplicitPackageVersion> y establecer la versión necesaria.
No agregue referencias a los metapaquetes Microsoft.NETCore.App y NETStandard.Library ni las actualice
explícitamente en proyectos de .NET Framework. Si se necesita alguna versión de NETStandard.Library al usar un
paquete NuGet basado en .NET Standard, NuGet instala automáticamente esa versión.

Versión implícita para algunas referencias de paquete

La mayoría de los usos de <PackageReference> requieren establecer el atributo Version para especificar la versión
del paquete de NuGet que se va a usar. Sin embargo, el atributo es innecesario si se usa .NET Core 2.1 o 2.2 y se hace
referencia a Microsoft.AspNetCore.App o a Microsoft.AspNetCore.All. El SDK de .NET Core puede seleccionar
automáticamente la versión que se debe usar de estos paquetes.
Recomendación
Cuando haga referencia al paquete Microsoft.AspNetCore.App o al paquete Microsoft.AspNetCore.All , no especifique
la versión. Si se especifica una versión, el SDK podría generar la advertencia NETSDK1071. Para corregir esta
advertencia, quite la versión de paquete como en el ejemplo siguiente:
 <ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

Problema conocido: el SDK de .NET Core 2.1 solo admite esta sintaxis cuando el proyecto también usa
Microsoft.NET.Sdk.Web. Esto se resuelve en el SDK de .NET Core 2.2.

Estas referencias a los metapaquetes de ASP.NET Core tienen un comportamiento ligeramente distinto de los
paquetes más habituales de NuGet. Las implementaciones dependientes del marco de las aplicaciones que usan estos
metapaquetes aprovechan automáticamente el marco de uso compartido de ASP.NET Core. Al usar los metapaquetes,
no se implementa ningún recurso de los paquetes NuGet de ASP.NET Core a los que se hace referencia con la
aplicación, porque el marco de uso compartido de ASP.NET Core ya contiene estos recursos. Los recursos del marco
de uso compartido están optimizados para que la plataforma de destino mejore el tiempo de inicio de la aplicación.
Para más información sobre el marco de uso compartido, consulte Empaquetado de distribución de .NET Core.
Si se especifica una versión, se trata como la versión mínima del marco de uso compartido de ASP.NET Core para las
implementaciones dependientes del marco y como una versión exacta de las implementaciones autocontenidas. Esto
puede deberse a las siguientes consecuencias:
Si la versión de ASP.NET Core instalada en el servidor es anterior a la versión especificada en PackageReference,
no se iniciará el proceso de .NET Core. Por lo general, las actualizaciones del metapaquete están disponibles en
NuGet.org antes de que se aparezcan en entornos de hospedaje como Azure. Actualizar la versión de
PackageReference a ASP.NET Core podría provocar un error en una aplicación implementada.
Si la aplicación se implementa como una implementación autocontenida, es posible que no contenga las
actualizaciones de seguridad más recientes a .NET Core. Cuando no se especifica una versión, el SDK puede incluir
automáticamente la versión más reciente de ASP.NET Core en la implementación autocontenida.

Inclusiones de compilación predeterminadas en proyectos .NET Core

Con el cambio al formato csproj en las últimas versiones del SDK, hemos trasladado las inclusiones y exclusiones
predeterminadas para los elementos de compilación y los recursos incrustados a los archivos de propiedades del
SDK. Esto implica que ya no tiene que especificar dichos elementos en el archivo del proyecto.
El principal motivo de este cambio consiste en reducir el desorden en el archivo del proyecto. Los valores
predeterminados presentes en el SDK deberían abarcar los casos de uso más habituales, por lo que no resulta
necesario repetirlos en todos los proyectos que cree. Esto da lugar a archivos de proyecto más pequeños que resultan
mucho más fáciles de entender, así como de editar manualmente si fuera necesario.
En la siguiente tabla se muestra qué elementos y qué globs se incluyen y excluyen en el SDK:

EL EM EN TO GLO B PA RA IN C L UIR GLO B PA RA EXC L UIR GLO B PA RA Q UITA R

Compile **/*.cs (u otras extensiones **/*.user; **/*.*proj; **/*.sln; N/D

de lenguaje) **/*.vssscc

EmbeddedResource **/*.resx **/*.user; **/*.*proj; **/*.sln; N/D

**/*.vssscc

None **/* **/*.user; **/*.*proj; **/*.sln; **/*.cs; **/*.resx

**/*.vssscc
 NOTE
Glob para excluir siempre excluye las carpetas ./bin y ./obj , que se representan mediante las propiedades
$(BaseOutputPath) y $(BaseIntermediateOutputPath) de MSBuild, respectivamente. En su conjunto, todos los "exclude" se
representan mediante $(DefaultItemExcludes) .

Si tiene globs en el proyecto e intenta crearlo usando el SDK más reciente, le aparecerá el siguiente error:

Se han incluido elementos de compilación duplicados. El SDK de .NET incluye elementos de compilación del
directorio del proyecto de forma predeterminada. Puede quitar estos elementos del archivo de proyecto o
establecer la propiedad “EnableDefaultCompileItems” en “false” si quiere incluirlos explícitamente en el archivo
del proyecto.

Para evitar este error, puede quitar los elementos Compile explícitos que coinciden con los que aparecen en la tabla
anterior o establecer la propiedad <EnableDefaultCompileItems> en false de esta forma:

<PropertyGroup>
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
</PropertyGroup>

Al establecer esta propiedad en false , se deshabilita la inclusión implícita y se revierte el comportamiento de SDK
anteriores en los que había que especificar los globs predeterminados del proyecto.
Este cambio no modifica los mecanismos principales de otras inclusiones. En cambio, si quiere especificar, por
ejemplo, que algunos archivos se publiquen con la aplicación, puede seguir usando los mecanismos con los que está
familiarizado en csproj (por ejemplo, el elemento <Content> ).
<EnableDefaultCompileItems> solo deshabilita globs Compile , pero no afecta a otros globs, como el glob None
implícito, que también se aplica a elementos *.cs. Por eso, el Explorador de soluciones sigue mostrando elementos
*.cs como parte del proyecto, incluso como elementos None . Del mismo modo, puede establecer
<EnableDefaultNoneItems> en false para deshabilitar el glob None implícito, de esta forma:

<PropertyGroup>
<EnableDefaultNoneItems>false</EnableDefaultNoneItems>
</PropertyGroup>

Para deshabilitar todos los globs implícitos , puede establecer la propiedad <EnableDefaultItems> en false como
en el ejemplo siguiente:

<PropertyGroup>
<EnableDefaultItems>false</EnableDefaultItems>
</PropertyGroup>

Visualización del proyecto completo tal como MSBuild lo ve

Aunque dichos cambios de csproj simplifican considerablemente los archivos de proyecto, quizá desee visualizar el
proyecto totalmente expandido tal y como MSBuild lo ve después de haber incluido el SDK y sus destinos. Preprocese
el proyecto con el conmutador /pp del comando dotnet msbuild , que muestra qué archivos se han importado, sus
orígenes y sus contribuciones a la compilación sin tener que compilar el proyecto realmente:

dotnet msbuild -pp:fullproject.xml

Si el proyecto tiene varios marcos de destino, los resultados del comando deben centrarse solo en uno de ellos,
especificándolo como una propiedad de MSBuild:
 dotnet msbuild -p:TargetFramework=netcoreapp3.1 -pp:fullproject.xml

Adiciones
Atributo Sdk
El elemento raíz <Project> del archivo .csproj tiene un nuevo atributo denominado Sdk . Sdk especifica qué SDK
usará el proyecto. El SDK, como se describe en el documento sobre capas, es un conjunto de tareas y destinos de
MSBuild que pueden generar código de .NET Core. Los siguientes SDK están disponibles para .NET Core:
1. El SDK de .NET Core con el id. de Microsoft.NET.Sdk
2. El SDK web de .NET Core con el id. de Microsoft.NET.Sdk.Web
3. El SDK de la biblioteca de clases de Razor de .NET Core con el id. Microsoft.NET.Sdk.Razor
4. El servicio de trabajo de .NET Core con el id. de Microsoft.NET.Sdk.Worker (a partir de .NET Core 3.0)
5. WinForms y WPF de .NET Core con el id. de Microsoft.NET.Sdk.WindowsDesktop (a partir de .NET Core 3.0)

Debe tener el conjunto de atributos Sdk establecido en uno de esos id. del elemento <Project> para poder usar las
herramientas de .NET Core y generar el código.
PackageReference
Elemento <PackageReference> que especifica una dependencia de NuGet en el proyecto. El atributo Include
especifica el identificador del paquete.

<PackageReference Include="package-id" Version="" PrivateAssets="" IncludeAssets="" ExcludeAssets="" />

Versión
El atributo Version necesario especifica la versión del paquete que se va a restaurar. El atributo respeta las reglas del
esquema de intervalo de versiones de NuGet. El comportamiento predeterminado es una versión mínima, incluida
una coincidencia. Por ejemplo, la especificación de Version="1.2.3" es equivalente a la notación de NuGet [1.2.3, )
y significa que el paquete resuelto tendrá la versión 1.2.3 si está disponible o, de lo contrario, una superior.
IncludeAssets, ExcludeAssets y PrivateAssets
El atributo IncludeAssets especifica qué recursos que pertenecen al paquete especificado por <PackageReference> se
deben consumir. De forma predeterminada, se incluyen todos los recursos del paquete.
El atributo ExcludeAssets especifica qué recursos que pertenecen al paquete especificado por <PackageReference> no
se deben consumir.
El atributo PrivateAssets especifica qué recursos que pertenecen al paquete especificado por <PackageReference> se
deben consumir, pero no pasar al proyecto siguiente. Cuando este atributo no existe, los recursos Analyzers , Build
y ContentFiles son privados de forma predeterminada.

NOTE
PrivateAssets es equivalente al elemento project.json/xproj SuppressParent .

Estos atributos pueden contener uno o varios de los siguientes elementos, separados por punto y coma ; si aparece
más de uno:
Compile : el contenido de la carpeta lib está disponible para compilación.
Runtime : el contenido de la carpeta runtime está distribuido.
ContentFiles : se usa el contenido de la carpeta contentfiles.
Build : se usan los archivos props/targets de la carpeta build.
Native : el contenido de recursos nativos se copia en la carpeta output en runtime.
 Analyzers : se usan los analizadores.

Como alternativa, el atributo puede contener:

None : no se usa ninguno de los recursos.
All : se usan todos los recursos.

DotnetCliToolReference
Un elemento <DotNetCliToolReference> especifica la herramienta de la CLI que el usuario quiere restaurar en el
contexto del proyecto. Es un sustituto del nodo tools de project.json.

<DotNetCliToolReference Include="<package-id>" Version="" />

Tenga en cuenta que DotNetCliToolReference está ahora en desuso en favor de las herramientas locales de .NET Core.
Versión
Version especifica la versión del paquete que se va a restaurar. El atributo respeta las reglas del esquema de
versiones de NuGet. El comportamiento predeterminado es una versión mínima, incluida una coincidencia. Por
ejemplo, la especificación de Version="1.2.3" es equivalente a la notación de NuGet [1.2.3, ) y significa que el
paquete resuelto tendrá la versión 1.2.3 si está disponible o, de lo contrario, una superior.
RuntimeIdentifiers
El elemento de propiedad <RuntimeIdentifiers> permite especificar una lista delimitada por puntos y coma de
identificadores de tiempo ejecución (RID) para el proyecto. Los RID permiten publicar implementaciones
autocontenidas.

<RuntimeIdentifiers>win10-x64;osx.10.11-x64;ubuntu.16.04-x64</RuntimeIdentifiers>

RuntimeIdentifier
El elemento de propiedad <RuntimeIdentifier> permite especificar solo un identificador de tiempo ejecución (RID)
para el proyecto. El RID permite publicar una implementación autocontenida.

<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>

Use <RuntimeIdentifiers> (en plural) en su lugar si tiene que publicar para varios entornos de ejecución.
<RuntimeIdentifier> puede proporcionar compilaciones más rápidas cuando solo se requiere un entorno de
ejecución.
PackageTargetFallback
El elemento de propiedad <PackageTargetFallback> permite especificar un conjunto de destinos compatibles que se
van a usar al restaurar paquetes. Está diseñado para permitir que los paquetes que usan la dotnet TxM (destino x
moniker) funcionen con paquetes que no declaran una dotnet TxM. Si el proyecto usa la dotnet TxM, todos los
paquetes de los que depende también deben tener una dotnet TxM, a menos que agregue el elemento
<PackageTargetFallback> a su proyecto a fin de permitir que las plataformas sin dotnet sean compatibles con dotnet.

En el ejemplo siguiente se proporcionan los elementos Fallback para todos los destinos del proyecto:

<PackageTargetFallback>
$(PackageTargetFallback);portable-net45+win8+wpa81+wp8
</PackageTargetFallback >

En el ejemplo siguiente se especifican los elementos Fallback solo para el destino netcoreapp3.1 :
 <PackageTargetFallback Condition="'$(TargetFramework)'=='netcoreapp3.1'">
$(PackageTargetFallback);portable-net45+win8+wpa81+wp8
</PackageTargetFallback >

Eventos de compilación
La forma en que se especifican los eventos anteriores y posteriores a la compilación en el archivo de proyecto ha
cambiado. No se recomiendan las propiedades PreBuildEvent y PostBuildEvent en el formato de proyecto de estilo
SDK, ya que las macros como $(ProjectDir) no se resuelven. Por ejemplo, el código siguiente ya no se admite:

<PropertyGroup>
<PreBuildEvent>"$(ProjectDir)PreBuildEvent.bat" "$(ProjectDir)..\" "$(ProjectDir)" "$(TargetDir)"
</PreBuildEvent>
</PropertyGroup>

En los proyectos de estilo SDK, use un destino de MSBuild denominado PreBuild o PostBuild , y establezca la
propiedad BeforeTargets para PreBuild , o bien la propiedad AfterTargets para PostBuild . Para el ejemplo
anterior, use el código siguiente:

<Target Name="PreBuild" BeforeTargets="PreBuildEvent">

<Exec Command="&quot;$(ProjectDir)PreBuildEvent.bat&quot; &quot;$(ProjectDir)..\&quot;
&quot;$(ProjectDir)&quot; &quot;$(TargetDir)&quot;" />
</Target>

<Target Name="PostBuild" AfterTargets="PostBuildEvent">

<Exec Command="echo Output written to $(TargetDir)" />
</Target>

NOTE
Puede usar cualquier nombre para los destinos de MSBuild, pero el IDE de Visual Studio reconoce los destinos PreBuild y
PostBuild , por lo que se recomienda usar esos nombres para poder editar los comandos en el IDE de Visual Studio.

Propiedades de metadatos de NuGet

Con el paso a MSBuild, hemos trasladado los metadatos de entrada que se usan cuando se empaqueta un paquete
NuGet de archivos project.json a archivos .csproj. Las entradas son propiedades de MSBuild, por lo que deben ir
dentro de un grupo <PropertyGroup> . La siguiente es la lista de propiedades que se utilizan como entradas para el
proceso de empaquetado cuando se usa el comando dotnet pack o el destino de MSBuild Pack , que forma parte
del SDK:
IsPackable
Un valor booleano que especifica si se puede empaquetar el proyecto. El valor predeterminado es true .
PackageVersion
Especifica la versión que tendrá el paquete resultante. Acepta todos los formatos de la cadena de versión de NuGet. El
valor predeterminado es $(Version) , es decir, de la propiedad Version del proyecto.
PackageId
Especifica el nombre para el paquete resultante. Si no se especifica, la operación pack usará de forma
predeterminada el elemento AssemblyName o el nombre del directorio como el nombre del paquete.
Title
Un título fácil de usar del paquete, que se usa normalmente en las visualizaciones de la interfaz de usuario, como en
nuget.org, y el Administrador de paquetes de Visual Studio. Si no se especifica, se usa el identificador del paquete en
su lugar.
Authors
Una lista separada por punto y coma de los autores de los paquetes, que coinciden con los nombres de perfil de
nuget.org. Estos se muestran en la galería de NuGet, en nuget.org, y se usan para hacer referencias cruzadas a
paquetes de los mismos autores.
PackageDescription
Una descripción larga del paquete para su visualización en la interfaz de usuario.
Descripción
Una descripción larga del ensamblado. Si PackageDescription no se especifica, esta propiedad también se utiliza
como la descripción del paquete.
Copyright
Detalles de copyright del paquete.
PackageRequireLicenseAcceptance
Un valor booleano que especifica si el cliente debe pedir al consumidor que acepte la licencia del paquete antes de
instalarlo. De manera predeterminada, es false .
DevelopmentDependency
Valor booleano que especifica si el paquete se debe marcar como una dependencia de solo desarrollo, que impide
que el paquete se incluya como una dependencia en otros paquetes. Con PackageReference (NuGet 4.8 y versiones
posteriores), esta marca también significa que se excluirán los recursos en tiempo de compilación de la compilación.
Para más información, consulte Compatibilidad de DevelopmentDependency para PackageReference.
PackageLicenseExpression
Identificador de licencia SPDX o expresión. Por ejemplo: Apache-2.0 .
Esta es la lista completa de identificadores de licencia SPDX. NuGet.org acepta solo licencias aprobadas de OSI o FSF
cuando se usa la expresión de tipo de licencia.
La sintaxis exacta de las expresiones de licencia se describe a continuación en ABNF.

license-id = <short form license identifier from https://spdx.org/spdx-specification-21-web-

version#h.luq9dgcle9mo>

license-exception-id = <short form license exception identifier from https://spdx.org/spdx-specification-21-web-

version#h.ruv3yl8g6czd>

simple-expression = license-id / license-id”+”

compound-expression = 1*1(simple-expression /
simple-expression "WITH" license-exception-id /
compound-expression "AND" compound-expression /
compound-expression "OR" compound-expression ) /
"(" compound-expression ")" )

license-expression = 1*1(simple-expression / compound-expression / UNLICENSED)

NOTE
Solo se puede especificar una de estos elementos cada vez: PackageLicenseExpression , PackageLicenseFile o
PackageLicenseUrl .

PackageLicenseFile
Ruta de acceso a un archivo de licencia dentro del paquete si usa una licencia que no tiene asignado un identificador
SPDX, o se trata de una licencia personalizada (en caso contrario, se prefiere PackageLicenseExpression )
Reemplaza PackageLicenseUrl , no se puede combinar con PackageLicenseExpression y requiere Visual Studio
versión 15.9.4 y el SDK de .NET 2.1.502, 2.2.101 o una versión posterior.
Deberá asegurarse de que el archivo de licencia está empaquetado; para ello, agréguelo explícitamente al proyecto.
Ejemplo de uso:

<PropertyGroup>
<PackageLicenseFile>LICENSE.txt</PackageLicenseFile>
</PropertyGroup>
<ItemGroup>
<None Include="licenses\LICENSE.txt" Pack="true" PackagePath="$(PackageLicenseFile)"/>
</ItemGroup>

PackageLicenseUrl
Una dirección URL a la licencia que se aplica al paquete. (en desuso desde Visual Studio 15.9.4, SDK de .NET 2.1.502 y
2.2.101)
PackageIcon
Ruta de acceso a una imagen del paquete que se va a usar como icono del paquete. Más información sobre los
metadatos de icon . PackageIconUrl está en desuso en favor de PackageIcon.
PackageReleaseNotes
Notas de la versión para el paquete.
PackageTags
Una lista de etiquetas delimitada por punto y coma que designa el paquete.
PackageOutputPath
Determina la ruta de acceso de salida en la que se va a quitar el paquete empaquetado. El valor predeterminado es
$(OutputPath) .

IncludeSymbols
Este valor booleano indica si el paquete debe crear un paquete de símbolos adicionales cuando se empaqueta el
proyecto. El formato del paquete de símbolos se controla mediante la propiedad SymbolPackageFormat .
SymbolPackageFormat
Especifica el formato del paquete de símbolos. Si es "symbols.nupkg", se crea un paquete de símbolos heredado con
una extensión .symbols.nupkg que contiene archivos PDB, DLL y otros archivos de salida. Si es "snupkg", se crea un
paquete de símbolos snupkg que contiene los archivos PDB portátiles. El valor predeterminado es "symbols.nupkg".
IncludeSource
Este valor booleano indica si el proceso de empaquetado debe crear un paquete de origen. El paquete de origen
contiene el código fuente de la biblioteca, así como archivos PDB. Los archivos de origen se colocan en el directorio
src/ProjectName , en el archivo de paquete resultante.

IsTool
Especifica si se copian todos los archivos de salida en la carpeta tools en lugar de la carpeta lib. Esto es diferente de
un elemento DotNetCliTool , que se especifica estableciendo el elemento PackageType en el archivo .csproj.
RepositoryUrl
Especifica la dirección URL del repositorio donde reside el código fuente del paquete o desde el que se está creando.
RepositoryType
Especifica el tipo del repositorio. El valor predeterminado es “git”.
RepositoryBranch
Especifica el nombre de la rama de origen en el repositorio. Cuando el proyecto se empaqueta en un paquete NuGet,
se agrega a los metadatos del paquete.
RepositoryCommit
Confirmación o conjunto de cambios opcionales de repositorio para indicar en qué origen se ha compilado el
paquete. RepositoryUrl también se debe especificar para que esta propiedad se incluya. Cuando el proyecto se
empaqueta en un paquete NuGet, esta confirmación o conjunto de cambios se agrega a los metadatos del paquete.
NoPackageAnalysis
Especifica que el paquete no debe ejecutar el análisis de paquetes después de crear el paquete.
MinClientVersion
Especifica la versión mínima del cliente de NuGet que puede instalar este paquete, aplicada por nuget.exe y el
Administrador de paquetes de Visual Studio.
IncludeBuildOutput
Este valor booleano especifica si se deben empaquetar los ensamblados de salida de la compilación en el archivo
.nupkg o no.
IncludeContentInPack
Este valor booleano especifica si los elementos del tipo Content se incluirán automáticamente en el paquete
resultante. De manera predeterminada, es true .
BuildOutputTargetFolder
Especifica la carpeta en la que se colocarán los ensamblados de salida. Los ensamblados de salida (y otros archivos
de salida) se copian en sus respectivas carpetas de marco.
ContentTargetFolders
Esta propiedad especifica la ubicación predeterminada a la que deben ir todos los archivos de contenido si no se
especifica PackagePath para ellos. El valor predeterminado es “content;contentFiles”.
NuspecFile
Ruta de acceso relativa o absoluta al archivo .nuspec que se usa para el empaquetado.

NOTE
Si se especifica el archivo .nuspec, se usa exclusivamente para la información de empaquetado y no se usa ninguna de la
información de los proyectos.

NuspecBasePath
Ruta de acceso base para el archivo .nuspec.
NuspecProperties
Lista separada por punto y coma de pares clave=valor.

Propiedades de AssemblyInfo
Los atributos de ensamblado que solían estar presentes en un archivo AssemblyInfo ahora se generan
automáticamente a partir de las propiedades.
Propiedades por atributo
Como se muestra en la tabla siguiente, cada atributo tiene una propiedad que controla el contenido y otra que
deshabilita su generación:

AT RIB UTO P RO P IEDA D. P RO P IEDA D Q UE SE VA A DESH A B IL ITA R

AssemblyCompanyAttribute Company GenerateAssemblyCompanyAttribute

 AT RIB UTO P RO P IEDA D. P RO P IEDA D Q UE SE VA A DESH A B IL ITA R

AssemblyConfigurationAttribute Configuration GenerateAssemblyConfigurationAttribute

AssemblyCopyrightAttribute Copyright GenerateAssemblyCopyrightAttribute

AssemblyDescriptionAttribute Description GenerateAssemblyDescriptionAttribute

AssemblyFileVersionAttribute FileVersion GenerateAssemblyFileVersionAttribute

AssemblyInformationalVersionAttribute InformationalVersion GenerateAssemblyInformationalVersionAttribute

AssemblyProductAttribute Product GenerateAssemblyProductAttribute

AssemblyTitleAttribute AssemblyTitle GenerateAssemblyTitleAttribute

AssemblyVersionAttribute AssemblyVersion GenerateAssemblyVersionAttribute

NeutralResourcesLanguageAttribute NeutralLanguage GenerateNeutralResourcesLanguageAttribute

Notas:
El comportamiento predeterminado de AssemblyVersion y FileVersion consiste en adoptar el valor de
$(Version) sin sufijo. Por ejemplo, si $(Version) es 1.2.3-beta.4 , entonces el valor sería 1.2.3 .
El valor predeterminado de InformationalVersion es el de $(Version) .
InformationalVersion tiene $(SourceRevisionId) anexado si la propiedad está presente. Puede deshabilitarse
mediante IncludeSourceRevisionInInformationalVersion .
Las propiedades Copyright y Description también se utilizan para metadatos de NuGet.
Configuration se comparte con todos los procesos de compilación y se establece mediante el parámetro
--configuration de los comandos dotnet .

GenerateAssemblyInfo
Un valor booleano que habilita o deshabilita toda la generación de AssemblyInfo. El valor predeterminado es true .
GeneratedAssemblyInfoFile
La ruta de acceso del archivo de información del ensamblado generado. De forma predeterminada, se trata de un
archivo del directorio $(IntermediateOutputPath) (obj).
 Administración de dependencias en aplicaciones
.NET Core
02/11/2020 • 2 minutes to read • Edit Online

En este artículo se explica cómo agregar y quitar dependencias mediante la modificación del archivo de proyecto o
mediante la CLI.

El elemento <PackageReference>
El archivo del proyecto <PackageReference> tiene la estructura siguiente:

<PackageReference Include="PACKAGE_ID" Version="PACKAGE_VERSION" />

El atributo Include especifica el identificador del paquete que se va a agregar al proyecto. El atributo Version
especifica la versión que se va a obtener. Las versiones se especifican en función de las reglas de versión de NuGet.

NOTE
Si no está familiarizado con la sintaxis del archivo del proyecto, vea la documentación de Referencia de proyectos de MSBuild
para obtener más información.

Use condiciones para agregar una dependencia que solo está disponible en un destino específico, tal como se
muestra en el ejemplo siguiente:

<PackageReference Include="PACKAGE_ID" Version="PACKAGE_VERSION" Condition="'$(TargetFramework)' ==

'netcoreapp2.1'" />

En el ejemplo anterior, la dependencia solo será válida si la compilación sucede para ese destino dado. El elemento
$(TargetFramework) de la condición es una propiedad de MSBuild que se está configurando en el proyecto. En las
aplicaciones .NET Core más comunes, no es necesario hacer esto.

Adición de una dependencia mediante la edición del archivo del

proyecto
Para agregar una dependencia, agregue un elemento <PackageReference> dentro de un elemento <ItemGroup> .
Puede agregar a un elemento <ItemGroup> existente o crear uno. En el ejemplo siguiente se usa el proyecto de
aplicación de consola predeterminado creado por dotnet new console :
 <Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.1.2" />
</ItemGroup>

</Project>

Adición de una dependencia mediante la CLI

Para agregar una dependencia, ejecute el comando dotnet add package, como se muestra en el ejemplo siguiente:

dotnet add package Microsoft.EntityFrameworkCore

Eliminación de una dependencia mediante la edición del archivo del

proyecto
Para quitar una dependencia, quite su elemento <PackageReference> del archivo del proyecto.

Eliminación de una dependencia mediante la CLI

Para quitar una dependencia, ejecute el comando dotnet remove package, como se muestra en el ejemplo
siguiente:

dotnet remove package Microsoft.EntityFrameworkCore

Vea también
Referencias de paquete en archivos de proyecto
Comando dotnet list package
 Procedimiento para administrar herramientas de
.NET
18/12/2020 • 15 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores
Una herramienta de .NET es un paquete NuGet especial que contiene una aplicación de consola. Una
herramienta se puede instalar en el equipo de las siguientes maneras:
Como herramienta global.
Los archivos binarios de la herramienta se instalan en un directorio predeterminado que se agrega a
la variable de entorno PATH. Puede invocar la herramienta desde cualquier directorio del equipo sin
especificar su ubicación. Una versión de una herramienta se usa para todos los directorios del
equipo.
Como herramienta global en una ubicación personalizada (también conocida como herramienta de
ruta de acceso de herramientas).
Los archivos binarios de la herramienta se instalan en la ubicación especificada. Puede invocar la
herramienta desde el directorio de instalación o proporcionando el directorio con el nombre del
comando o agregando el directorio a la variable de entorno PATH. Una versión de una herramienta
se usa para todos los directorios del equipo.
Como herramienta local (se aplica al SDK de .NET Core 3.0 y versiones posteriores).
Los archivos binarios de la herramienta se instalan en un directorio predeterminado. Puede invocar
la herramienta desde el directorio de instalación o con cualquiera de sus subdirectorios. Distintos
directorios pueden usar versiones diferentes de la misma herramienta.
La CLI de .NET usa archivos de manifiesto para realizar un seguimiento de las herramientas que se
instalan como locales en un directorio. Cuando el archivo de manifiesto se guarda en el directorio
raíz de un repositorio de código fuente, un colaborador puede clonar el repositorio e invocar un
solo comando de la CLI de .NET que instale todas las herramientas enumeradas en los archivos de
manifiesto.

IMPORTANT
Las herramientas de .NET se ejecutan con plena confianza. No instale una herramienta de .NET a menos que confíe
en el autor.

Búsqueda de una herramienta

Estas son algunas formas de encontrar herramientas:
Use el comando dotnet tool search para buscar una herramienta que esté publicada en NuGet.org.
Busque en el sitio web de NuGet mediante el filtro de tipo de paquete "herramienta .NET". Para más
información, vea Búsqueda y selección de paquetes.
Consulte la lista de herramientas del repositorio GitHub natemcmaster/dotnet-tools.
Use ToolGet para buscar herramientas de .NET.
Puede ver el código fuente de las herramientas creado por el equipo de ASP.NET Core en el directorio
 de herramientas del repositorio de GitHub dotnet/aspnetcore.
Obtenga información sobre las herramientas de diagnóstico en Herramientas de diagnóstico de .NET.

Comprobar el autor y las estadísticas

Como las herramientas de .NET se ejecutan con plena confianza y las herramientas globales se agregan a
la variable de entorno PATH, pueden ser muy eficaces. No descargue herramientas de personas en las que
no confíe.
Si la herramienta está hospedada en NuGet, busque la herramienta para comprobar el autor y las
estadísticas.

Instalación de una herramienta global

Para instalar una herramienta como una herramienta global, use la opción -g o --global del comando
dotnet tool install, tal como se muestra en el ejemplo siguiente:

dotnet tool install -g dotnetsay

La salida muestra el comando que se usa para invocar la herramienta y la versión instalada, de forma
similar al ejemplo siguiente:

You can invoke the tool using the following command: dotnetsay
Tool 'dotnetsay' (version '2.1.4') was successfully installed.

La ubicación predeterminada de los archivos binarios de una herramienta depende del sistema operativo:

SO RUTA DE A C C ESO

Linux/macOS $HOME/.dotnet/tools

Windows %USERPROFILE%\.dotnet\tools

Esta ubicación se agrega a la ruta de acceso del usuario cuando se ejecuta el SDK por primera vez, por lo
que las herramientas globales se pueden invocar desde cualquier directorio sin especificar la ubicación de
la herramienta.
El acceso a las herramientas es específico del usuario, no de la máquina global. Una herramienta global
solo está disponible para el usuario que ha instalado la herramienta.
Instalación de una herramienta global en una ubicación personalizada
Para instalar una herramienta como una herramienta global, use la opción --tool-path del comando
dotnet tool install, tal como se muestra en los ejemplos siguientes.
En Windows:

dotnet tool install dotnetsay --tool-path c:\dotnet-tools

En Linux o macOS:

dotnet tool install dotnetsay --tool-path ~/bin

El SDK de .NET no agrega esta ubicación automáticamente a la variable de entorno PATH. Para invocar una
herramienta de ruta de acceso de herramientas, tiene que asegurarse de que el comando está disponible
mediante uno de los métodos siguientes:
Agregue el directorio de instalación a la variable de entorno PATH.
Especifique la ruta de acceso completa a la herramienta al invocarla.
Invoque la herramienta desde el directorio de instalación.

Instalación de una herramienta local

Se aplica al SDK de .NET Core 3.0 y versiones posteriores.
Para instalar una herramienta solo para el acceso local (del directorio y los subdirectorios actuales), debe
agregarse a un archivo de manifiesto de la herramienta. Para crear un archivo de manifiesto de
herramienta, ejecute el comando dotnet new tool-manifest :

dotnet new tool-manifest

Este comando crea un archivo de manifiesto denominado dotnet-tools.json en el directorio .config. Para
agregar una herramienta local al archivo de manifiesto, use el comando dotnet tool install y omita las
opciones --global y --tool-path , tal como se muestra en el ejemplo siguiente:

dotnet tool install dotnetsay

En la salida del comando se muestra el archivo de manifiesto en el que se encuentra la herramienta que
acaba de instalar, de manera similar al siguiente ejemplo:

You can invoke the tool from this directory using the following command:
dotnet tool run dotnetsay
Tool 'dotnetsay' (version '2.1.4') was successfully installed.
Entry is added to the manifest file /home/name/botsay/.config/dotnet-tools.json.

En el ejemplo siguiente se muestra un archivo de manifiesto con dos herramientas locales instaladas:

{
"version": 1,
"isRoot": true,
"tools": {
"botsay": {
"version": "1.0.0",
"commands": [
"botsay"
]
},
"dotnetsay": {
"version": "2.1.3",
"commands": [
"dotnetsay"
]
}
}
}

Normalmente, una herramienta local se agrega al directorio raíz del repositorio. Después de insertar el
archivo de manifiesto en el repositorio, los desarrolladores que extraen código del repositorio obtienen el
archivo de manifiesto más reciente. Para instalar todas las herramientas enumeradas en el archivo de
manifiesto, ejecutan el comando dotnet tool restore :

dotnet tool restore

La salida indica qué herramientas se han restaurado:

Tool 'botsay' (version '1.0.0') was restored. Available commands: botsay

Tool 'dotnetsay' (version '2.1.3') was restored. Available commands: dotnetsay
Restore was successful.

Instalación de una versión específica de la herramienta

Para instalar una versión preliminar o una versión específica de la herramienta, especifique el número de
versión con la opción --version , tal como se muestra en el ejemplo siguiente:

dotnet tool install dotnetsay --version 2.1.3

Uso de una herramienta

El comando que se usa para invocar una herramienta puede ser diferente del nombre del paquete que se
instala. Para mostrar todas las herramientas instaladas actualmente en el equipo para el usuario actual, use
el comando dotnet tool list:

dotnet tool list

La salida muestra la versión y el comando de cada herramienta, de forma similar al ejemplo siguiente:

Package Id Version Commands Manifest

-------------------------------------------------------------------------------------------
botsay 1.0.0 botsay /home/name/repository/.config/dotnet-tools.json
dotnetsay 2.1.3 dotnetsay /home/name/repository/.config/dotnet-tools.json

Tal como se muestra en este ejemplo, la lista muestra las herramientas locales. Para ver las herramientas
globales, use la opción --global y, para ver herramientas de ruta de acceso de herramientas, use la opción
--tool-path .

Invocación de una herramienta global

En el caso de las herramientas globales, use el comando de la herramienta por sí solo. Por ejemplo, si el
comando es dotnetsay o dotnet-doc , eso es lo que se usa para invocar el comando:

dotnetsay
dotnet-doc

Si el comando comienza con el prefijo dotnet- , una manera alternativa de invocar la herramienta es usar
el comando dotnet y omitir el prefijo del comando de la herramienta. Por ejemplo, si el comando es
dotnet-doc , el siguiente comando invoca la herramienta:

dotnet doc

Sin embargo, en el siguiente escenario no se puede usar el comando dotnet para invocar una
herramienta global:
Una herramienta global y una herramienta local tienen el mismo comando con el prefijo dotnet- .
Quiere invocar la herramienta global desde un directorio que está en el ámbito de la herramienta local.
En este escenario, dotnet doc y dotnet dotnet-doc invocan a la herramienta local. Para invocar la
herramienta global, use el comando por sí solo:

dotnet-doc

Invocación de una herramienta de ruta de acceso de herramientas

Para invocar una herramienta global que se instala mediante la opción tool-path , asegúrese de que el
comando está disponible, tal como se explicó anteriormente en este artículo.
Invocación de una herramienta local
Para invocar una herramienta local, tiene que usar el comando dotnet desde el directorio de instalación.
Puede usar el formato largo ( dotnet tool run <COMMAND_NAME> ) o el formato abreviado (
dotnet <COMMAND_NAME> ), tal como se muestra en los ejemplos siguientes:

dotnet tool run dotnetsay

dotnet dotnetsay

Si el comando tiene el prefijo dotnet- , puede incluir u omitir el prefijo al invocar la herramienta. Por
ejemplo, si el comando es dotnet-doc , cualquiera de los siguientes ejemplos invoca la herramienta local:

dotnet tool run dotnet-doc

dotnet dotnet-doc
dotnet doc

Actualización de una herramienta

La actualización de una herramienta implica desinstalarla y reinstalarla con la versión estable más reciente.
Para actualizar una herramienta, use el comando dotnet tool update con la misma opción que usó para
instalar la herramienta:

dotnet tool update --global <packagename>

dotnet tool update --tool-path <packagename>
dotnet tool update <packagename>

En el caso de una herramienta local, el SDK encuentra el primer archivo de manifiesto que contiene el
identificador de paquete mediante la búsqueda en el directorio actual y en los directorios principales. Si no
hay ningún identificador del paquete en ningún archivo de manifiesto, el SDK agrega una nueva entrada al
archivo de manifiesto más cercano.

Desinstalación de una herramienta

Quite una herramienta mediante el comando dotnet tool uninstall con la misma opción que usó para
instalar la herramienta:
 dotnet tool uninstall --global <packagename>
dotnet tool uninstall --tool-path <packagename>
dotnet tool uninstall <packagename>

En el caso de una herramienta local, el SDK encuentra el primer archivo de manifiesto que contiene el
identificador de paquete mediante la búsqueda en el directorio actual y en los directorios principales.

Ayuda y solución de problemas

Para obtener una lista de los comandos de dotnet tool disponibles, escriba el siguiente comando:

dotnet tool --help

Para obtener instrucciones sobre el uso de la herramienta, escriba uno de los siguientes comandos o vea el
sitio web de la herramienta:

<command> --help
dotnet <command> --help

Si una herramienta no se puede instalar o ejecutar, vea Solución de problemas de uso de herramientas de
.NET Core.

Vea también
Tutorial: Creación de una herramienta de .NET mediante la CLI de .NET
Tutorial: Instalación y uso de una herramienta global de .NET mediante la CLI de .NET
Tutorial: Instalación y uso de una herramienta local de .NET mediante la CLI de .NET
 Solución de problemas de uso de herramientas de
.NET Core
18/12/2020 • 13 minutes to read • Edit Online

Es posible que surjan problemas al intentar instalar o ejecutar una herramienta de .NET, que puede ser global o
local. En este artículo se describen las causas principales más comunes y algunas posibles soluciones.

No se puede ejecutar la herramienta de .NET instalada

Cuando una herramienta de .NET no se ejecuta, lo más probable es que se haya producido uno de los problemas
siguientes:
No se encontró el archivo ejecutable de la herramienta.
No se encuentra la versión correcta del entorno de ejecución de .NET.
No se encontró el archivo ejecutable
Si no se encuentra el archivo ejecutable, verá un mensaje similar al siguiente:

Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET program, but dotnet-xyz does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on
the PATH.

El nombre del archivo ejecutable determina cómo se invoca la herramienta. En la siguiente tabla se describe el
formato:

F O RM ATO DEL N O M B RE DEL A RC H IVO E JEC UTA B L E F O RM ATO DE IN VO C A C IÓ N

dotnet-<toolName>.exe dotnet <toolName>

<toolName>.exe <toolName>

Herramientas globales
Las herramientas globales pueden instalarse en el directorio predeterminado o en una ubicación específica.
Los directorios predeterminados son:

SO RUTA DE A C C ESO

Linux/macOS $HOME/.dotnet/tools

Windows %USERPROFILE%\.dotnet\tools

Si intenta ejecutar una herramienta global, compruebe que la variable del entorno PATH de su máquina
contiene la ruta de acceso donde instaló la herramienta global y que el archivo ejecutable está en esa ruta
de acceso.
La primera vez que se usa, la CLI de .NET intenta agregar la ubicación predeterminada a la variable de
 entorno PATH. Pero hay algunos escenarios en los que la ubicación podría no agregarse a PATH
automáticamente:
Si usa Linux y ha instalado el SDK de .NET mediante archivos .tar.gz en lugar de apt-get o rpm.
Si usa macOS 10.15 “Catalina” o versiones posteriores.
Si usa macOS 10.14 "Mojave" o versiones anteriores, y ha instalado el SDK de .NET mediante archivos
.tar.gz en lugar de .pkg.
Si ha instalado el SDK de .NET Core 3.0 y ha establecido la variable de entorno
DOTNET_ADD_GLOBAL_TOOLS_TO_PATH en false .
Si ha instalado el SDK de .NET Core 2.2 o versiones anteriores y ha establecido la variable de entorno
DOTNET_SKIP_FIRST_TIME_EXPERIENCE en true .
En estos casos, o si especificó la opción --tool-path , la variable de entorno PATH del equipo no contiene
automáticamente la ruta de acceso donde se instaló la herramienta global. En tal caso, anexe la ubicación
de la herramienta (por ejemplo, $HOME/.dotnet/tools ) a la variable de entorno PATH usando el método
que el shell proporcione para actualizar variables de entorno. Para obtener más información, vea
Herramientas de .NET.
Herramientas locales
Si intenta ejecutar una herramienta local, compruebe que hay un archivo de manifiesto denominado
dotnet-tools.json en el directorio actual o en cualquiera de sus directorios principales. Este archivo también
puede encontrarse en una carpeta denominada .config en cualquier lugar de la jerarquía de carpetas del
proyecto, en lugar de en la carpeta raíz. Si dotnet-tools.json existe, ábralo y busque la herramienta que
intenta ejecutar. Si el archivo no contiene una entrada para "isRoot": true , busque más arriba en la
jerarquía de archivos otros archivos de manifiesto de la herramienta.
Si intenta ejecutar una herramienta de .NET que se ha instalado con una ruta de acceso especificada, debe
incluir esa ruta de acceso al usar la herramienta. Un ejemplo de uso de una herramienta instalada en una
ruta de acceso de herramientas es:

..\<toolDirectory>\dotnet-<toolName>

No se encontró el runtime
Las herramientas globales de .NET son aplicaciones que dependen del marco, lo que significa que se basan en un
entorno de ejecución de .NET instalado en el equipo. Si no se encuentra el entorno de ejecución esperado, se
siguen las reglas normales de puesta al día del de .NET:
Una aplicación avanza a la versión de revisión más alta de las versiones principal y secundaria especificadas.
Si no hay ningún runtime que coincida con un número de versión principal y secundaria, se usa la siguiente
versión secundaria más alta.
Esta puesta al día no se produce entre versiones preliminares del runtime ni entre versiones preliminares y
versiones de lanzamiento. Por tanto, las herramientas de .NET creadas con versiones preliminares deben ser
recompiladas, publicadas nuevamente y reinstaladas por el autor.
La puesta al día no se producirá de forma predeterminada en dos escenarios comunes:
Solo están disponibles las versiones anteriores del runtime. La puesta al día solo selecciona versiones
posteriores del runtime.
Solo están disponibles las versiones posteriores principales del runtime. La puesta al día no traspasa los límites
de la versión principal.
Si una aplicación no encuentra el runtime apropiado, no se puede ejecutar y notifica un error.
Puede averiguar qué entornos de ejecución de .NET están instalados en el equipo con uno de los comandos
siguientes:

dotnet --list-runtimes
dotnet --info

Si cree que la herramienta debería ser compatible con la versión de runtime que tiene instalada actualmente,
puede ponerse en contacto con el autor de la herramienta para ver si puede actualizar el número de versión o la
compatibilidad con varios destinos. Una vez que se vuelva a compilar y a publicar el paquete de herramientas en
NuGet con un número de versión actualizado, podrá actualizar su copia. Mientras tanto, la solución más rápida es
instalar una versión del runtime que funcione con la herramienta que intenta ejecutar. Para descargar una versión
específica del entorno de ejecución de .NET, visite la página de descarga de .NET.
Si instala el SDK de .NET en una ubicación que no es la predeterminada, debe establecer la variable de entorno
DOTNET_ROOT en el directorio que contiene el archivo ejecutable dotnet .

Error en la instalación de una herramienta de .NET

Hay varias razones por las que se puede producir un error en la instalación de una herramienta local o global de
.NET. Cuando se produzca un error en la instalación de la herramienta, verá un mensaje similar al siguiente:

Tool '{0}' failed to install. This failure may have been caused by:

* You are attempting to install a preview release and did not use the --version option to specify the
version.
* A package by this name was found, but it was not a .NET tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.

For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool

Para ayudar a diagnosticar estos errores, los mensajes de NuGet se muestran directamente al usuario, junto con el
mensaje anterior. El mensaje de NuGet puede ayudarle a identificar el problema.
Cumplimiento de la nomenclatura de los paquetes
Microsoft ha cambiado sus instrucciones sobre los identificadores de paquetes para las herramientas, lo que ha
dado lugar a que no se encuentren diversas herramientas con el nombre previsto. Según las nuevas instrucciones,
todas las herramientas de Microsoft deben tener el prefijo “Microsoft”. Este prefijo está reservado y solo se puede
usar para los paquetes firmados con un certificado autorizado de Microsoft.
Durante la transición, algunas herramientas de Microsoft tendrán el formato anterior del identificador de paquete,
mientras que otras tendrán el nuevo formato:

dotnet tool install -g Microsoft.<toolName>

dotnet tool install -g <toolName>

A medida que se actualicen los identificadores de paquetes, deberá usar el nuevo identificador de paquete para
obtener las actualizaciones más recientes. Los paquetes con el nombre de herramienta simplificado estarán en
desuso.
Versiones preliminares
Intenta instalar una versión preliminar y no ha usado la opción --version para especificar la versión.

Las herramientas de .NET que se encuentran en versión preliminar se deben especificar con una parte del nombre
para indicar que están en versión preliminar. No es necesario incluir todo el nombre de la versión preliminar. Si los
números de versión tienen el formato esperado, puede usar algo parecido al ejemplo siguiente:
 dotnet tool install -g --version 1.1.0-pre <toolName>

El paquete no es una herramienta de .NET

Se ha encontrado un paquete NuGet con este nombre, pero no era una herramienta de .NET.
Si intenta instalar un paquete NuGet normal que no es una herramienta de .NET, verá un error similar al siguiente:

NU1212: combinación de paquete de proyecto no válida para <ToolName> . El estilo de proyecto

DotnetToolReference solo puede contener referencias de tipo DotnetTool.

No se puede acceder a la fuente NuGet

No se puede acceder a la fuente NuGet necesaria, quizás debido a un problema con la conexión a Internet.
La instalación de la herramienta requiere acceso a la fuente NuGet que contiene el paquete de la herramienta. Se
produce un error si la fuente no está disponible. Puede modificar las fuentes con nuget.config , solicitar un
archivo nuget.config determinado o especificar fuentes adicionales con el modificador --add-source . De forma
predeterminada, NuGet genera un error para cualquier fuente con la que no pueda conectar. La marca
--ignore-failed-sources puede omitir estos orígenes no accesibles.

Identificador de paquete incorrecto

No ha escrito correctamente el nombre de la herramienta.
Un motivo habitual de error es que el nombre de la herramienta no es correcto. Esto puede ocurrir cuando se
produce un error de escritura, o porque la herramienta se ha movido o está en desuso. En el caso de las
herramientas de NuGet.org, una manera de asegurarse de que tiene el nombre correcto es buscar la herramienta
en NuGet.org y copiar el comando de instalación.

Vea también
Herramientas de .NET
 Tutorial: Creación de una herramienta de .NET
mediante la CLI de .NET
18/12/2020 • 7 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores
En este tutorial se explica cómo crear y empaquetar una herramienta de .NET. La CLI de .NET permite crear una
aplicación de consola como una herramienta, que otros usuarios pueden instalar y ejecutar. Las herramientas de
.NET son paquetes NuGet que se instalan desde la CLI de .NET. Para obtener más información sobre las
herramientas, vea Información general sobre las herramientas de .NET.
La herramienta que se va a crear es una aplicación de consola que toma un mensaje como entrada y muestra el
mensaje junto con líneas de texto que crean la imagen de un robot.
Este es el primero en una serie de tres tutoriales. En este tutorial, creará y empaquetará una herramienta. En los
dos tutoriales siguientes, usará la herramienta como una herramienta global y usará la herramienta como una
herramientas local.

Requisitos previos
SDK 3.1 de NET Core o una versión posterior.
Este tutorial y el siguiente tutorial para las herramientas globales se aplican al SDK de .NET Core 2.1 y
versiones posteriores, porque las herramientas globales están disponibles a partir de esa versión. Pero en
este tutorial se da por supuesto que tiene instalada la versión 3.1 o posterior para que tenga la opción de
continuar con el tutorial de herramientas locales. Las herramientas locales están disponibles a partir del
SDK de .NET Core 3.0. Los procedimientos para crear una herramienta son los mismos tanto si se usan
como una herramienta global o como una herramienta local.
Un editor de texto o un editor de código de su elección.

Crear un proyecto
1. Abra un símbolo del sistema y cree una carpeta denominada repositorio.
2. Desplácese hasta la carpeta repository y escriba el comando siguiente:

dotnet new console -n microsoft.botsay

El comando crea una carpeta denominada microsoft.botsay en la carpeta repository.

3. Navegue hasta la carpeta microsoft.botsay.

cd microsoft.botsay

Agregar el código
1. Abra el archivo Program.cs con el editor de código.
2. Agregue la siguiente directiva using al principio del archivo:
 using System.Reflection;

3. Reemplace el método Main con el siguiente código para procesar los argumentos de la línea de comandos
para la aplicación.

static void Main(string[] args)

{
if (args.Length == 0)
{
var versionString = Assembly.GetEntryAssembly()
.GetCustomAttribute<AssemblyInformationalVersionAttribute>()
.InformationalVersion
.ToString();

Console.WriteLine($"botsay v{versionString}");
Console.WriteLine("-------------");
Console.WriteLine("\nUsage:");
Console.WriteLine(" botsay <message>");
return;
}

ShowBot(string.Join(' ', args));

}

Si no se pasó ningún argumento, se muestra un mensaje de ayuda breve. De lo contrario, todos los
argumentos se concatenan en una sola cadena y se imprimen llamando al método ShowBot que se crea en
el paso siguiente.
4. Agregue un nuevo método denominado ShowBot que toma un parámetro de cadena. El método imprime
el mensaje y una imagen de un robot usando líneas de texto.
 static void ShowBot(string message)
{
string bot = $"\n {message}";
bot += @"
__________________
\
\
....
....'
....
..........
.............'..'..
................'..'.....
.......'..........'..'..'....
........'..........'..'..'.....
.'....'..'..........'..'.......'.
.'..................'... ......
. ......'......... .....
. _ __ ......
.. # ## ......
.... . .......
...... ....... ............
................ ......................
........................'................
......................'..'...... .......
.........................'..'..... .......
........ ..'.............'..'.... ..........
..'..'... ...............'....... ..........
...'...... ...... .......... ...... .......
........... ....... ........ ......
....... '...'.'. '.'.'.' ....
....... .....'.. ..'.....
.. .......... ..'........
............ ..............
............. '..............
...........'.. .'.'............
............... .'.'.............
.............'.. ..'..'...........
............... .'..............
......... ..............
.....
";
Console.WriteLine(bot);
}

5. Guarde los cambios.

Probar la aplicación
Ejecute el proyecto y observe la salida. Pruebe estas variaciones en la línea de comandos para ver resultados
diferentes:

dotnet run
dotnet run -- "Hello from the bot"
dotnet run -- Hello from the bot

Todos los argumentos después del delimitador -- se pasan a la aplicación.

Empaquetado de la herramienta
Antes de que pueda empaquetar y distribuir la aplicación como una herramienta, debe modificar el archivo de
proyecto.
1. Abra el archivo microsoft.botsay.csproj y agregue tres nuevos nodos XML al final del nodo
<PropertyGroup> :

<PackAsTool>true</PackAsTool>
<ToolCommandName>botsay</ToolCommandName>
<PackageOutputPath>./nupkg</PackageOutputPath>

<ToolCommandName> es un elemento opcional que especifica el comando que invocará a la herramienta una
vez instalada. Si no se proporciona este elemento, el nombre de comando para la herramienta es el
nombre del archivo de proyecto sin la extensión .csproj.
<PackageOutputPath> es un elemento opcional que determina dónde se generará el paquete NuGet. El
paquete NuGet es el que la CLI de .NET Core utiliza para instalar la herramienta.
El archivo del proyecto debe ser similar al siguiente ejemplo:

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>

<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>

<PackAsTool>true</PackAsTool>
<ToolCommandName>botsay</ToolCommandName>
<PackageOutputPath>./nupkg</PackageOutputPath>

</PropertyGroup>

</Project>

2. Cree un paquete NuGet ejecutando el comando dotnet pack:

dotnet pack

El archivo microsoft.botsay.1.0.0.nupkg se crea en la carpeta identificada por el valor <PackageOutputPath>

del archivo microsoft.botsay.csproj, que en este ejemplo es la carpeta ./nupkg.
Si quiere lanzar una herramienta públicamente, puede cargarla en https://www.nuget.org . Una vez que la
herramienta está disponible en NuGet, los desarrolladores pueden instalar la herramienta mediante el
comando dotnet tool install. En este tutorial, se instalará el paquete directamente desde la carpeta local
nupkg, por lo que no es necesario cargar el paquete en NuGet.

Solucionar problemas
Si recibe un mensaje de error al seguir el tutorial, vea Solución de problemas de uso de herramientas de .NET
Core.

Pasos siguientes
En este tutorial, ha creado una aplicación de consola y la ha empaquetado como una herramienta. Para aprender a
usar la herramienta como una herramienta global, avance al siguiente tutorial.
Instalación y uso de una herramienta global
Si lo prefiere, puede omitir el tutorial de herramientas globales y pasar directamente al tutorial de herramientas
locales.
Instalación y uso de una herramienta local
 Tutorial: Instalación y uso de una herramienta global
de .NET mediante la CLI de .NET
18/12/2020 • 4 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 2.1 y versiones posteriores
En este tutorial se enseña cómo instalar y usar una herramienta global. Usará una herramienta que ha creado en
el primer tutorial de esta serie.

Requisitos previos
Complete el primer tutorial de esta serie.

Uso de la herramienta como una herramienta global

1. Instale la herramienta desde el paquete; para ello, ejecute el comando dotnet tool install en la carpeta del
proyecto microsoft.botsay:

dotnet tool install --global --add-source ./nupkg microsoft.botsay

El parámetro --global indica a la CLI de .NET que instale los archivos binarios de la herramienta en una
ubicación predeterminada que se agrega de forma automática a la variable de entorno PATH.
El parámetro --add-source indica a la CLI de .NET que use temporalmente el directorio ./nupkg como una
fuente de origen adicional para los paquetes NuGet. Ha asignado un nombre único al paquete para
asegurarse de que solo se encontrará en el directorio ./nupkg, no en el sitio de Nuget.org.
En la salida se muestra el comando que se ha usado para llamar a la herramienta y la versión instalada:

You can invoke the tool using the following command: botsay
Tool 'microsoft.botsay' (version '1.0.0') was successfully installed.

2. Invoque la herramienta:

botsay hello from the bot

NOTE
Si se produce un error en este comando, es posible que tenga que abrir un nuevo terminal para actualizar el valor
de PATH.

3. Ejecute el comando dotnet tool uninstall para quitar la herramienta:

dotnet tool uninstall -g microsoft.botsay

Uso de la herramienta como una herramienta global instalada en una

ubicación personalizada
1. Instale la herramienta desde el paquete.
En Windows:

dotnet tool install --tool-path c:\dotnet-tools --add-source ./nupkg microsoft.botsay

En Linux o macOS:

dotnet tool install --tool-path ~/bin --add-source ./nupkg microsoft.botsay

El parámetro --tool-path indica a la CLI de .NET que instale los archivos binarios de la herramienta en la
ubicación especificada. Si el directorio no existe, se crea. Este directorio no se agrega automáticamente a
la variable de entorno PATH.
En la salida se muestra el comando que se ha usado para llamar a la herramienta y la versión instalada:

You can invoke the tool using the following command: botsay
Tool 'microsoft.botsay' (version '1.0.0') was successfully installed.

2. Invoque la herramienta:
En Windows:

c:\dotnet-tools\botsay hello from the bot

En Linux o macOS:

~/bin/botsay hello from the bot

3. Ejecute el comando dotnet tool uninstall para quitar la herramienta:

En Windows:

dotnet tool uninstall --tool-path c:\dotnet-tools microsoft.botsay

En Linux o macOS:

dotnet tool uninstall --tool-path ~/bin microsoft.botsay

Solucionar problemas
Si recibe un mensaje de error al seguir el tutorial, vea Solución de problemas de uso de herramientas de .NET
Core.

Pasos siguientes
En este tutorial, ha instalado y usado una herramienta como una herramienta global. Para instalar y usar la
misma herramienta como una herramienta local, vaya al siguiente tutorial.
Instalación y uso de herramientas locales
 Tutorial: Instalación y uso de una herramienta local
de .NET mediante la CLI de .NET
18/12/2020 • 7 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores
En este tutorial se enseña cómo instalar y usar una herramienta local. Usará una herramienta que ha creado en
el primer tutorial de esta serie.

Requisitos previos
Complete el primer tutorial de esta serie.
Instale el entorno de ejecución de .NET Core 2.1.
En este tutorial, instalará y usará una herramienta que tiene como destino .NET Core 2.1, por lo que debe
tener ese entorno de ejecución instalado en el equipo. Para instalar la versión 2.1 del entorno de
ejecución, vaya a la página de descarga de .NET Core 2.1 y busque el vínculo de instalación del entorno
de ejecución en la columna Ejecutar aplicaciones: entorno de ejecución .

Crear un archivo de manifiesto

Para instalar una herramienta solo para el acceso local (del directorio y los subdirectorios actuales), debe
agregarse a un archivo de manifiesto.
Desde la carpeta microsoft.botsay, suba un nivel hasta la carpeta repository:

cd ..

Cree un archivo de manifiesto; para ello, ejecute el comando dotnet new:

dotnet new tool-manifest

En la salida se indica que el archivo se ha creado correctamente.

The template "Dotnet local tool manifest file" was created successfully.

El archivo .config/dotnet-tools.json aún no contiene ninguna herramienta:

{
"version": 1,
"isRoot": true,
"tools": {}
}

Las herramientas enumeradas en un archivo de manifiesto están disponibles en el directorio y los

subdirectorios actuales. El directorio actual es el que contiene el directorio .config con el archivo de manifiesto.
Si se usa un comando de la CLI que hace referencia a una herramienta local, el SDK busca un archivo de
manifiesto en el directorio actual y los directorios principales. Si encuentra un archivo de manifiesto, pero el
archivo no incluye la herramienta a la que se hace referencia, continúa con la búsqueda en los directorios
principales. La búsqueda finaliza cuando encuentra la herramienta a la que se hace referencia o un archivo de
manifiesto con isRoot establecido en true .

Instalación de botsay como una herramienta local

Instale la herramienta desde el paquete que ha creado en el primer tutorial:

dotnet tool install --add-source ./microsoft.botsay/nupkg microsoft.botsay

Este comando agrega la herramienta al archivo de manifiesto que ha creado en el paso anterior. En la salida del
comando se muestra el archivo de manifiesto en el que se encuentra la herramienta que acaba de instalar:

You can invoke the tool from this directory using the following command:
'dotnet tool run botsay' or 'dotnet botsay'
Tool 'microsoft.botsay' (version '1.0.0') was successfully installed.
Entry is added to the manifest file /home/name/repository/.config/dotnet-tools.json

Ahora, el archivo .config/dotnet-tools.json tiene una herramienta:

{
"version": 1,
"isRoot": true,
"tools": {
"microsoft.botsay": {
"version": "1.0.0",
"commands": [
"botsay"
]
}
}
}

Usar la herramienta
Para invocar la herramienta, ejecute el comando dotnet tool run desde la carpeta repository:

dotnet tool run botsay hello from the bot

Restauración de una herramienta local instalada por otros usuarios

Normalmente, una herramienta local se instala en el directorio raíz del repositorio. Después de insertar el
archivo de manifiesto en el repositorio, otros desarrolladores pueden obtener el archivo de manifiesto más
reciente. Para instalar todas las herramientas enumeradas en el archivo de manifiesto, pueden ejecutar un único
comando dotnet tool restore .
1. Abra el archivo .config/dotnet-tools.json y reemplace el contenido con el siguiente código JSON:
 {
"version": 1,
"isRoot": true,
"tools": {
"microsoft.botsay": {
"version": "1.0.0",
"commands": [
"botsay"
]
},
"dotnetsay": {
"version": "2.1.3",
"commands": [
"dotnetsay"
]
}
}
}

2. Reemplace <name> con el nombre que ha usado para crear el proyecto.

3. Guarde los cambios.
Cambiar esto tiene el mismo resultado que obtener la versión más reciente del repositorio después de
que otra persona haya instalado el paquete dotnetsay en el directorio del proyecto.
4. Ejecute el comando dotnet tool restore .

dotnet tool restore

El comando genera una salida como la del siguiente ejemplo:

Tool 'microsoft.botsay' (version '1.0.0') was restored. Available commands: botsay

Tool 'dotnetsay' (version '2.1.3') was restored. Available commands: dotnetsay
Restore was successful.

5. Compruebe que las herramientas están disponibles:

dotnet tool list

La salida es una lista de paquetes y comandos, similar al ejemplo siguiente:

Package Id Version Commands Manifest

--------------------------------------------------------------------------------------------
microsoft.botsay 1.0.0 botsay /home/name/repository/.config/dotnet-tools.json
dotnetsay 2.1.3 dotnetsay /home/name/repository/.config/dotnet-tools.json

6. Pruebe las herramientas:

dotnet tool run dotnetsay hello from dotnetsay

dotnet tool run botsay hello from botsay

Actualización de una herramienta local

La versión instalada de la herramienta local dotnetsay es 2.1.3. La versión más reciente es 2.1.4. Use el
comando dotnet tool update para actualizar la herramienta a la versión más reciente.

dotnet tool update dotnetsay

En la salida se indica el nuevo número de versión:

Tool 'dotnetsay' was successfully updated from version '2.1.3' to version '2.1.4'
(manifest file /home/name/repository/.config/dotnet-tools.json).

El comando update busca el primer archivo de manifiesto que contiene el identificador del paquete y lo
actualiza. Si no hay ningún identificador del paquete en ningún archivo de manifiesto que esté en el ámbito de
la búsqueda, el SDK agrega una nueva entrada al archivo de manifiesto más cercano. El ámbito de búsqueda va
hacia los directorios principales hasta que se encuentra un archivo de manifiesto con isRoot = true .

Eliminación de las herramientas locales

Ejecute el comando dotnet tool uninstall para quitar las herramientas instaladas:

dotnet tool uninstall microsoft.botsay

dotnet tool uninstall dotnetsay

Solucionar problemas
Si recibe un mensaje de error al seguir el tutorial, vea Solución de problemas de uso de herramientas de .NET
Core.

Vea también
Para obtener más información, vea Herramientas de .NET Core.
 Herramientas adicionales de .NET Core
18/12/2020 • 5 minutes to read • Edit Online

En esta sección se recopila una lista de herramientas compatibles con las funcionalidades de .NET Core y que las
amplían, además de las herramientas de la CLI de .NET Core.

Herramienta de desinstalación de .NET Core

La herramienta de desinstalación de .NET Core ( dotnet-core-uninstall ) permite limpiar los SDK y los entornos de
ejecución de .NET Core en un sistema, de modo que solo queden las versiones especificadas. Hay una colección de
opciones disponible para especificar las versiones que se van a desinstalar.

Herramientas de diagnóstico de .NET Core

dotnet-counters es una herramienta diseñada para la investigación del rendimiento y la supervisión del estado de
primer nivel.
dotnet-dump permite recopilar y analizar los volcados de Windows y Linux sin necesidad de un depurador nativo.
dotnet-gcdump permite recopilar volcados de memoria de GC (recolector de elementos no utilizados) de procesos
de .NET dinámicos.
dotnet-trace recopila datos de generación de perfiles de la aplicación que pueden ayudar en escenarios en los que
es necesario averiguar lo que causa que una aplicación se ejecute lentamente.

Herramienta de instalación de .NET para autores de extensiones

La herramienta de instalación de .NET para autores de extensiones es una extensión de Visual Studio Code que
permite la adquisición del runtime de .NET Core específicamente para autores de extensiones de VS Code. Esta
herramienta está diseñada para aprovecharse en extensiones escritas en .NET y requiere que .NET arranque partes
de la extensión (por ejemplo, un servidor de lenguaje). La extensión no está pensada para que la usen
directamente los usuarios con el fin de instalar .NET para el desarrollo.

Herramienta WCF Web Service Reference

La herramienta WCF (Windows Communication Foundation) Web Service Reference es un proveedor de servicios
conectados de Visual Studio que se estrenó en la versión 15.5 de Visual Studio 2017. Esta herramienta recupera
metadatos de un servicio web en la solución actual, en una ubicación de red o desde un archivo WSDL. Genera un
archivo de código fuente compatible con .NET Core, que define una clase de proxy de WCF con métodos que se
pueden usar para acceder a las operaciones del servicio web.

Herramienta dotnet-svcutil de WCF

La herramienta dotnet-svcutil de WCF es una herramienta de .NET que recupera los metadatos de un servicio web
en una ubicación de red o en un archivo WSDL. Genera un archivo de código fuente compatible con .NET Core, que
define una clase de proxy de WCF con métodos que se pueden usar para acceder a las operaciones del servicio
web.
La herramienta dotnet-svcutil es una alternativa al proveedor de servicios conectados de Visual Studio WCF
Web Ser vice Reference , que se distribuyó por primera vez en la versión 15.5 de Visual Studio 2017. La
herramienta dotnet-svcutil , como herramienta de .NET, está disponible en Linux, macOS y Windows.
Herramienta dotnet-svcutil.xmlserializer de WCF
En .NET Framework, puede generar previamente un ensamblado de serialización con la herramienta svcutil. La
herramienta dotnet-svcutil.xmlserializer de WCF proporciona una funcionalidad parecida en .NET Core. Genera
previamente código de serialización de C# para los tipos de la aplicación cliente que usa el contrato de servicio de
WCF y que puede serializar XmlSerializer. Esto mejora el rendimiento de inicio de la serialización de XML al
serializar o deserializar objetos de esos tipos.

Generador de serializador XML

Tal y como sucede con el generador serializador de XML (sgen.exe) para .NET Framework, el paquete NuGet
Microsoft.XmlSerializer.Generator es la solución para las bibliotecas .NET Core y .NET Standard. Crea un
ensamblado de serialización de XML para los tipos contenidos en un ensamblado para mejorar el rendimiento de
inicio de la serialización XML al serializar o deserializar objetos de esos tipos con XmlSerializer.

Generación de certificados autofirmados

Puede usar dotnet-dev-certs para crear certificados autofirmados para escenarios de desarrollo y pruebas.
 Herramienta de desinstalación de .NET Core
02/11/2020 • 25 minutes to read • Edit Online

La herramienta de desinstalación de .NET Core ( dotnet-core-uninstall ) permite quitar los SDK y los entornos en
tiempo de ejecución de .NET Core de un sistema. Hay una colección de opciones disponible para especificar las
versiones que desea desinstalar.
La herramienta es compatible con Windows y macOS. Linux no se admite actualmente.
En Windows, la herramienta solo puede desinstalar los SDK y entornos en tiempo de ejecución que se instalaron
mediante uno de los siguientes instaladores:
El instalador del SDK y del entorno en tiempo de ejecución de .NET Core.
El instalador de Visual Studio en versiones anteriores a Visual Studio 2019, versión 16.3.
En macOS, la herramienta solo puede desinstalar los SDK y entornos en tiempo de ejecución ubicados en la
carpeta /usr/local/share/dotnet.
Debido a estas limitaciones, es posible que la herramienta no pueda desinstalar todos los SDK y los entornos en
tiempo de ejecución de .NET Core de la máquina. Puede usar el comando dotnet --info para buscar todos los
SDK y los entornos en tiempo de ejecución de .NET Core instalados, incluidos los entornos en tiempo de ejecución
y SDK que esta herramienta no puede quitar. El comando dotnet-core-uninstall list muestra qué SDK se pueden
desinstalar con la herramienta.

Instalación de la herramienta
Puede descargar la herramienta de desinstalación de .NET Core desde la página de versiones de la herramienta y
encontrar el código fuente en el repositorio dotnet/cli-lab de GitHub.

NOTE
La herramienta requiere elevación para desinstalar los SDK y los entornos en tiempo de ejecución de .NET Core. Por lo tanto,
debe instalarse en un directorio protegido contra escritura, como C:\Archivos de programa en Windows o /usr/local/bin en
macOS. Consulte también Acceso con privilegios elevados para comandos de dotnet. Para obtener más información, vea las
instrucciones de instalación detalladas.

Ejecución de la herramienta
En los pasos siguientes se muestra el enfoque recomendado para ejecutar la herramienta de desinstalación:
Paso 1: Mostrar los SDK y los entornos en tiempo de ejecución de .NET Core instalados
Paso 2: Realizar un simulacro
Paso 3: Desinstalar los SDK y los entornos en tiempo de ejecución de .NET Core
Paso 4: Eliminar la carpeta de reserva de NuGet (opcional)
Paso 1: Mostrar los SDK y los entornos en tiempo de ejecución de .NET Core instalados
El comando dotnet-core-uninstall list enumera los SDK y los entornos en tiempo de ejecución de .NET Core
instalados que se pueden quitar con esta herramienta. Visual Studio puede necesitar algunos SDK y entornos en
tiempo de ejecución, que se muestran con una nota de por qué no se recomienda desinstalarlos.
 NOTE
En la mayoría de los casos, la salida del comando dotnet-core-uninstall list no coincidirá con la lista de versiones
instaladas en la salida de dotnet --info . En concreto, esta herramienta no mostrará las versiones instaladas mediante
archivos ZIP ni administradas por Visual Studio (cualquier versión instalada con Visual Studio 2019 16.3 o posterior). Una
manera de comprobar si una versión está administrada por Visual Studio es verla en Add or Remove Programs , donde las
versiones administradas de Visual Studio se marcan como tales en sus nombres para mostrar.

dotnet-core-uninstall list
Sinopsis

dotnet-core-uninstall list [options]

Opciones
Windows
macOS
--aspnet-runtime

Enumera todos los entornos en tiempo de ejecución de ASP.NET Core que se pueden desinstalar con esta
herramienta.
--hosting-bundle

Enumera todos los conjuntos de hospedaje de .NET Core que se pueden desinstalar con esta herramienta.
--runtime

Enumera todos los entornos en tiempo de ejecución de .NET Core que se pueden desinstalar con esta
herramienta.
--sdk

Enumera todos los SDK de .NET Core que se pueden desinstalar con esta herramienta.
-v, --verbosity <LEVEL>

Establece el nivel de detalle. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] , d[etailed] y
diag[nostic] . El valor predeterminado es normal .

--x64

Enumera todos los SDK y entornos en tiempo de ejecución de .NET Core x64 que se pueden desinstalar con
esta herramienta.
--x86

Enumera todos los SDK y entornos en tiempo de ejecución de .NET Core x86 que se pueden desinstalar con
esta herramienta.
Ejemplos
Enumerar todos los SDK y entornos en tiempo de ejecución de .NET Core que se pueden quitar con esta
herramienta:

dotnet-core-uninstall list

Enumerar todos los SDK y entornos en tiempo de ejecución de .NET Core x64:
 dotnet-core-uninstall list --x64

Enumerar todos los SDK de .NET Core x86:

dotnet-core-uninstall list --sdk --x86

Paso 2: Realizar un simulacro

Los comandos dotnet-core-uninstall dry-run y dotnet-core-uninstall whatif muestran los SDK y los entornos en
tiempo de ejecución de .NET Core que se quitarán en función de las opciones proporcionadas sin realizar la
desinstalación. Estos comandos son sinónimos.
dotnet-core-uninstall dr y-run y dotnet-core-uninstall whatif
Sinopsis

dotnet-core-uninstall dry-run [options] [<VERSION>...]

dotnet-core-uninstall whatif [options] [<VERSION>...]

Argumentos
VERSION

La versión especificada que se va a desinstalar. Puede enumerar varias versiones una detrás de la otra,
separadas por espacios. También se admiten los archivos de respuesta.

TIP
Los archivos de respuesta son una alternativa a la colocación de todas las versiones en la línea de comandos. Son
archivos de texto, normalmente con una extensión *.rsp y cada versión aparece en una línea independiente. Para
especificar un archivo de respuesta para el argumento VERSION , use el carácter @ seguido inmediatamente del
nombre del archivo de respuesta.

Opciones
Windows
macOS
--all

Quita todos los SDK y entornos en tiempo de ejecución de .NET Core.

--all-below <VERSION>[ <VERSION>...]

Quita solo los SDK y los entornos en tiempo de ejecución de .NET Core que tienen una versión menor que la
versión especificada. La versión especificada permanece instalada.
--all-but <VERSIONS>[ <VERSION>...]

Quita todos los SDK y entornos en tiempo de ejecución de .NET Core, excepto las versiones especificadas.
--all-but-latest

Quita los SDK y los entornos en tiempo de ejecución de .NET Core, excepto la versión más alta.
--all-lower-patches

Quita los SDK y los entornos en tiempo de ejecución de .NET Core reemplazados por revisiones superiores.
 Esta opción protege el archivo global.json.
--all-previews

Quita los SDK y los entornos en tiempo de ejecución de .NET Core marcados como versiones preliminares.
--all-previews-but-latest

Quita los SDK y los entornos en tiempo de ejecución de .NET Core marcados como versiones preliminares,
excepto la versión preliminar más alta.
--aspnet-runtime

Solo quita los entornos en tiempos de ejecución de ASP.NET Core.

--hosting-bundle

Quita el entorno en tiempo de ejecución de .NET Core y los conjuntos de hospedaje.

--major-minor <MAJOR_MINOR>

Quita los SDK y los entornos en tiempo de ejecución de .NET Core que coinciden con la versión
major.minor especificada.

--runtime

Solo quita los entornos en tiempo de ejecución de .NET Core.

--sdk

Solo quita los SDK de .NET Core.

-v, --verbosity <LEVEL>

Establece el nivel de detalle. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] , d[etailed] y
diag[nostic] . El valor predeterminado es normal .

--x64

Se debe usar con --sdk , --runtime y --aspnet-runtime para quitar los SDK o los entornos en tiempo de
ejecución x64.
--x86

Se debe usar con --sdk , --runtime y --aspnet-runtime para quitar los SDK o los entornos en tiempo de
ejecución x86.
--force Fuerza la eliminación de las versiones que Visual Studio puede usar.

Notas:
1. Se requiere exactamente uno de los valores --sdk , --runtime , --aspnet-runtime y --hosting-bundle .
2. --all , --all-below , --all-but , --all-but-latest , --all-lower-patches , --all-previews ,
--all-previews-but-latest , --major-minor y [<VERSION>...] son valores exclusivos.
3. Si no se especifica --x64 o --x86 , se quitarán tanto x64 como x86.
Ejemplos
 NOTE
De forma predeterminada, los SDK y los entornos en tiempo de ejecución de .NET Core que puede necesitar Visual Studio u
otros SDK no se incluyen en la salida de dotnet-core-uninstall dry-run . En los siguientes ejemplos, es posible que
algunos de los SDK y entornos en tiempo de ejecución especificados no se incluyan en la salida, según el estado de la
máquina. Para incluir todos los SDK y entornos en tiempo de ejecución, agréguelos explícitamente como argumentos o use la
opción --force .

Realizar un simulacro de la eliminación de todos entornos en tiempo de ejecución de .NET Core que se han
reemplazado por revisiones superiores:

dotnet-core-uninstall dry-run --all-lower-patches --runtime

Realizar un simulacro de la eliminación de todos los SDK de .NET Core inferiores a la versión 2.2.301 :

dotnet-core-uninstall whatif --all-below 2.2.301 --sdk

Paso 3: Desinstalar los SDK y los entornos en tiempo de ejecución de .NET Core
dotnet-core-uninstall remove desinstala los SDK y los entornos en tiempo de ejecución de .NET Core especificados
por una colección de opciones. La herramienta no se puede usar para desinstalar los SDK y entornos en tiempo de
ejecución con la versión 5.0 o posterior.
Dado que esta herramienta tiene un comportamiento destructivo, es altamente recomendable que realice un
simulacro antes de ejecutar el comando remove. El simulacro le mostrará qué SDK y entornos en tiempo de
ejecución de .NET Core se quitarán cuando use el comando remove . Consulte ¿Puedo quitar una versión? para
saber qué SDK y entornos en tiempo de ejecución se pueden quitar de forma segura.
Cau t i on

Tenga en cuenta las siguientes advertencias:

Esta herramienta puede desinstalar las versiones del SDK de .NET Core que necesitan los archivos global.json
de la máquina. Puede volver a instalar los SDK de .NET Core desde la página Descarga de .NET Core.
Esta herramienta puede desinstalar las versiones del entorno en tiempo de ejecución de .NET Core que
necesitan las aplicaciones que dependen del marco de trabajo de la máquina. Puede volver a instalar los
entornos en tiempo de ejecución de .NET Core desde la página Descarga de .NET Core.
Esta herramienta puede desinstalar las versiones del SDK y del entorno en tiempo de ejecución de .NET Core en
las que se basa Visual Studio. Si interrumpe la instalación de Visual Studio, ejecute "Reparar" en el instalador de
Visual Studio para volver a un estado de funcionamiento.
De forma predeterminada, todos los comandos mantienen los SDK y los entornos en tiempo de ejecución de .NET
Core que puede necesitar Visual Studio u otros SDK. Estos SDK y entornos en tiempos de ejecución se pueden
desinstalar si se enumeran explícitamente como argumentos o mediante la opción --force .
La herramienta requiere elevación para desinstalar los SDK y los entornos en tiempo de ejecución de .NET Core.
Ejecute la herramienta en un símbolo del sistema de administrador en Windows y con sudo en macOS. Los
comandos dry-run y whatif no requieren elevación.
dotnet-core-uninstall remove
Sinopsis

dotnet-core-uninstall remove [options] [<VERSION>...]

Argumentos
 VERSION

La versión especificada que se va a desinstalar. Puede enumerar varias versiones una detrás de la otra,
separadas por espacios. También se admiten los archivos de respuesta.

TIP
Los archivos de respuesta son una alternativa a la colocación de todas las versiones en la línea de comandos. Son
archivos de texto, normalmente con una extensión *.rsp y cada versión aparece en una línea independiente. Para
especificar un archivo de respuesta para el argumento VERSION , use el carácter @ seguido inmediatamente del
nombre del archivo de respuesta.

Opciones
Windows
macOS
--all

Quita todos los SDK y entornos en tiempo de ejecución de .NET Core.

--all-below <VERSION>[ <VERSION>...]

Quita solo los SDK y los entornos en tiempo de ejecución de .NET Core que tienen una versión menor que la
versión especificada. La versión especificada permanece instalada.
--all-but <VERSIONS>[ <VERSION>...]

Quita todos los SDK y entornos en tiempo de ejecución de .NET Core, excepto las versiones especificadas.
--all-but-latest

Quita los SDK y los entornos en tiempo de ejecución de .NET Core, excepto la versión más alta.
--all-lower-patches

Quita los SDK y los entornos en tiempo de ejecución de .NET Core reemplazados por revisiones superiores.
Esta opción protege el archivo global.json.
--all-previews

Quita los SDK y los entornos en tiempo de ejecución de .NET Core marcados como versiones preliminares.
--all-previews-but-latest

Quita los SDK y los entornos en tiempo de ejecución de .NET Core marcados como versiones preliminares,
excepto la versión preliminar más alta.
--aspnet-runtime

Solo quita los entornos en tiempos de ejecución de ASP.NET Core.

--hosting-bundle

Solo quita conjuntos de hospedaje de .NET Core.

--major-minor <MAJOR_MINOR>

Quita los SDK y los entornos en tiempo de ejecución de .NET Core que coinciden con la versión
major.minor especificada.

--runtime
 Solo quita los entornos en tiempo de ejecución de .NET Core.
--sdk

Solo quita los SDK de .NET Core.

-v, --verbosity <LEVEL>

Establece el nivel de detalle. Los valores permitidos son q[uiet] , m[inimal] , n[ormal] , d[etailed] y
diag[nostic] . El valor predeterminado es normal .

--x64

Se debe usar con --sdk , --runtime y --aspnet-runtime para quitar los SDK o los entornos en tiempo de
ejecución x64.
--x86

Se debe usar con --sdk , --runtime y --aspnet-runtime para quitar los SDK o los entornos en tiempo de
ejecución x86.
-y, --yes Ejecuta el comando sin requerir una confirmación sí o no.
--force Fuerza la eliminación de las versiones que Visual Studio puede usar.
Notas:
1. Se requiere exactamente uno de los valores --sdk , --runtime , --aspnet-runtime y --hosting-bundle .
2. --all , --all-below , --all-but , --all-but-latest , --all-lower-patches , --all-previews ,
--all-previews-but-latest , --major-minor y [<VERSION>...] son valores exclusivos.
3. Si no se especifica --x64 o --x86 , se quitarán tanto x64 como x86.
Ejemplos

NOTE
De forma predeterminada, los SDK y los entornos en tiempo de ejecución de .NET Core que puede necesitar Visual Studio u
otros SDK se mantienen. En los siguientes ejemplos, es posible que algunos de los SDK y entornos en tiempo de ejecución
especificados se mantengan, según el estado de la máquina. Para quitar todos los SDK y entornos en tiempo de ejecución,
agréguelos explícitamente como argumentos o use la opción --force .

Quitar todos los entornos en tiempo de ejecución de .NET Core excepto la versión 3.0.0-preview6-27804-01
sin necesidad de la confirmación S/N:

dotnet-core-uninstall remove --all-but 3.0.0-preview6-27804-01 --runtime --yes

Quitar todos los SDK de .NET Core 1.1 sin necesidad de la confirmación de S/N:

dotnet-core-uninstall remove --sdk --major-minor 1.1 -y

Quitar el SDK de .NET Core 1.1.11 sin salida de consola:

dotnet-core-uninstall remove 1.1.11 --sdk --yes --verbosity q

Quitar todos los SDK de .NET Core que se puedan quitar con seguridad con esta herramienta:
 dotnet-core-uninstall remove --all --sdk

Quitar todos los SDK de .NET Core que puede quitar esta herramienta, incluidos los SDK que puede
necesitar Visual Studio (no recomendado):

dotnet-core-uninstall remove --all --sdk --force

Quitar todos los SDK de .NET Core que se especifican en el archivo de respuesta versions.rsp

dotnet-core-uninstall remove --sdk @versions.rsp

El contenido de versions.rsp es el siguiente:

2.2.300
2.1.700

Paso 4: Eliminar la carpeta de reserva de NuGet (opcional)

En algunos casos, ya no necesita NuGetFallbackFolder y puede que desee eliminarlo. Para más información sobre
cómo eliminar esta carpeta, consulte Quitar NuGetFallbackFolder.

Desinstalación de la herramienta.
Windows
macOS
1. Abra Agregar o quitar programas .
2. Busque Microsoft .NET Core SDK Uninstall Tool .
3. Seleccione Desinstalar .
 Herramienta de instalación de .NET para autores de
extensiones
18/12/2020 • 2 minutes to read • Edit Online

La herramienta de instalación de .NET para autores de extensiones es una extensión de Visual Studio Code que
permite la adquisición del entorno de ejecución de .NET específicamente para autores de extensiones de VS Code.
Esta herramienta está diseñada para aprovecharse en extensiones escritas en .NET y requiere que .NET arranque
partes de la extensión (por ejemplo, un servidor de lenguaje). La extensión no está pensada para que la usen
directamente los usuarios con el fin de instalar .NET para el desarrollo.

Introducción: autores de extensiones

Para asegurarse de que la herramienta de instalación de .NET para autores de extensiones es la opción adecuada en
su escenario, empiece por revisar los objetivos de esta extensión en nuestra página de GitHub.

NOTE
Esta herramienta solo se puede usar para instalar el entorno de ejecución de .NET, actualmente no tiene la capacidad de
instalar el SDK de .NET.

Cuando haya comprobado que la herramienta de instalación de .NET para autores de extensiones se adapta a sus
necesidades, puede aceptar una dependencia de ella en el manifiesto de la extensión y empezar a usar los
comandos que exponemos con la API de VS Code. Puede encontrar la lista de comandos que expone esta extensión
en nuestro GitHub.
Consulte esta extensión de ejemplo para ver estos pasos en acción.
Para ver más ejemplos, consulte estas extensiones de código abierto que aprovechan actualmente esta
herramienta:
Herramientas de Azure Resource Manager (ARM) para Visual Studio Code
.NET Interactive Notebooks

Introducción: usuarios finales

En general, no es necesario que el usuario final interactúe con la herramienta de instalación de .NET para autores
extensiones. Si tiene problemas con la extensión, consulte nuestra página de solución de problemas o presente una
incidencia en nuestro GitHub.
 Generación de certificados autofirmados con la CLI
de .NET
18/12/2020 • 12 minutes to read • Edit Online

Cuando se usan certificados autofirmados, hay diferentes maneras de crearlos y usarlos en escenarios de
desarrollo y pruebas. En esta guía, se describirá el uso de certificados autofirmados con dotnet dev-certs y otras
opciones, como PowerShell y OpenSSL .
Después, puede validar que el certificado se cargará mediante un ejemplo como una aplicación ASP.NET Core
hospedada en un contenedor.

Requisitos previos
En el ejemplo, puede usar .NET Core 3.1 o .NET 5.
Para dotnet dev-certs , asegúrese de que tiene instalada la versión adecuada de .NET:
Instalación de .NET en Windows
Instalación de .NET en Linux
Instalación de .NET en macOS
En este ejemplo se necesita la versión Docker 17.06 o posterior del cliente Docker.

Preparación de la aplicación de ejemplo

Tendrá que preparar la aplicación de ejemplo en función del entorno de ejecución que quiera usar para las
pruebas, ya sea .NET Core 3.1 o .NET 5.
En esta guía, usará una aplicación de ejemplo y realizará los cambios necesarios.
Aplicación de ejemplo para .NET Core 3.1
Obtener la aplicación de ejemplo.

git clone https://github.com/dotnet/dotnet-docker/

Navegue al repositorio de forma local y abra el área de trabajo en un editor.

NOTE
Si quiere usar parámetros de dotnet publish para recortar la implementación, tendrá que asegurarse de que se incluyan las
dependencias adecuadas para admitir los certificados SSL. Actualice dotnet-docker\samples\aspnetapp\aspnetapp.csproj para
asegurarse de que los ensamblados adecuados están incluidos en el contenedor. Como referencia, compruebe cómo
actualizar el archivo .csproj para admitir certificados SSL al usar el recorte para las implementaciones independientes.

Asegúrese de que aspnetapp.csproj incluye la plataforma de destino adecuada:

 <Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>
<TargetFramework>.netcoreapp3.1</TargetFramework>
<!--Other Properties-->
</PropertyGroup>

</Project>

Modifique el Dockerfile para asegurarse de que el entorno de ejecución apunta a .NET Core 3.1:

# https://hub.docker.com/_/microsoft-dotnet-core
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /source

# copy csproj and restore as distinct layers

COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore

# copy everything else and build app

COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore

# final stage/image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Asegúrese de que apunta a la aplicación de ejemplo.

cd .\dotnet-docker\samples\aspnetapp

Cree el contenedor para realizar las pruebas localmente.

docker build -t aspnetapp:my-sample -f Dockerfile .

Aplicación de ejemplo de .NET 5

En esta guía, se debe comprobar .NET 5 en el archivo aspnetapp de ejemplo.
Compruebe que en el Dockerfile de la aplicación de ejemplo se usa .NET 5.
En función del sistema operativo del host, es posible que sea necesario actualizar el entorno de ejecución de
ASP.NET. Por ejemplo, el cambio de mcr.microsoft.com/dotnet/aspnet:5.0-nanoservercore-2009 AS runtime a
mcr.microsoft.com/dotnet/aspnet:5.0-windowsservercore-ltsc2019 AS runtime en el Dockerfile ayudará a establecer
como destino el entorno de ejecución de Windows adecuado.
Por ejemplo, esto ayudará a probar los certificados en Windows:
 # https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /source

# copy csproj and restore as distinct layers

COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore -r win-x64

# copy everything else and build app

COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app -r win-x64 --self-contained false --no-restore

# final stage/image
# Uses the 2009 release; 2004, 1909, and 1809 are other choices
FROM mcr.microsoft.com/dotnet/aspnet:5.0-windowsservercore-ltsc2019 AS runtime
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["aspnetapp"]

Si se van a probar los certificados en Linux, puede usar el Dockerfile existente.

Asegúrese de que aspnetapp.csproj incluye la plataforma de destino adecuada:

<Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<!--Other Properties-->
</PropertyGroup>

</Project>

NOTE
Si quiere usar parámetros dotnet publish para recortar la implementación, asegúrese de que se incluyan las dependencias
adecuadas para admitir los certificados SSL. Actualice dotnet-docker\samples\aspnetapp\aspnetapp.csproj para asegurarse
de que los ensamblados adecuados están incluidos en el contenedor. Como referencia, compruebe cómo actualizar el archivo
.csproj para admitir certificados SSL al usar el recorte para las implementaciones independientes.

Asegúrese de que apunta a la aplicación de ejemplo.

cd .\dotnet-docker\samples\aspnetapp

Cree el contenedor para realizar las pruebas localmente.

docker build -t aspnetapp:my-sample -f Dockerfile .

Creación de un certificado autofirmado

Puede crear un certificado autofirmado:
Con dotnet dev-certs
Con PowerShell
 Con OpenSSL
Con dotnet dev-certs
Puede usar dotnet dev-certs para trabajar con certificados autofirmados. En este ejemplo se usa una consola de
PowerShell.

dotnet dev-certs https -ep $env:USERPROFILE\.aspnet\https\aspnetapp.pfx -p crypticpassword

dotnet dev-certs https --trust

NOTE
El nombre del certificado, en este caso aspnetapp.pfx debe coincidir con el nombre del ensamblado del proyecto.
crypticpassword se usa como sustituto de una contraseña que elija. Si la consola devuelve "Ya hay un certificado HTTPS
válido.", ya existe un certificado de confianza en el almacén. Se puede exportar mediante la consola de MMC.

Configure los secretos de la aplicación para el certificado:

dotnet user-secrets -p aspnetapp\aspnetapp.csproj set "Kestrel:Certificates:Development:Password"

"crypticpassword"

NOTE
Nota: La contraseña debe coincidir con la contraseña usada para el certificado.

Ejecute la imagen de contenedor con ASP.NET Core configurado para HTTPS:

docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e

ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -v
$env:APPDATA\microsoft\UserSecrets\:C:\Users\ContainerUser\AppData\Roaming\microsoft\UserSecrets -v
$env:USERPROFILE\.aspnet\https:C:\Users\ContainerUser\AppData\Roaming\ASP.NET\Https
mcr.microsoft.com/dotnet/samples:aspnetapp

Una vez que se inicie la aplicación, vaya a https://localhost:8001 en el explorador web.

Limpieza
Si los secretos y certificados no están en uso, asegúrese de limpiarlos.

dotnet user-secrets remove "Kestrel:Certificates:Development:Password" -p aspnetapp\aspnetapp.csproj

dotnet dev-certs https --clean

Con PowerShell
Puede usar PowerShell para generar certificados autofirmados. El cliente PKI se puede usar para generar un
certificado autofirmado.

$cert = New-SelfSignedCertificate -DnsName @("contoso.com", "www.contoso.com") -CertStoreLocation

"cert:\LocalMachine\My"

El certificado se generará, pero se debe colocar en un almacén de certificados para realizar las pruebas en un
explorador.
 $certKeyPath = "c:\certs\contoso.com.pfx"
$password = ConvertTo-SecureString 'password' -AsPlainText -Force
$cert | Export-PfxCertificate -FilePath $certKeyPath -Password $password
$rootCert = $(Import-PfxCertificate -FilePath $certKeyPath -CertStoreLocation 'Cert:\LocalMachine\Root' -
Password $password)

En este momento, los certificados deben ser visibles desde un complemento MMC.
Puede ejecutar el contenedor de ejemplo en el Subsistema de Windows para Linux (WSL):

docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e

ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e
ASPNETCORE_Kestrel__Certificates__Default__Password="password" -e
ASPNETCORE_Kestrel__Certificates__Default__Path=/https/contoso.com.pfx -v /c/certs:/https/
mcr.microsoft.com/dotnet/samples:aspnetapp

NOTE
Tenga en cuenta que, con el montaje del volumen, la ruta de acceso del archivo se podría controlar de otra manera en
función del host. Por ejemplo, en WSL se podría reemplazar /c/certs por /mnt/c/certs.

Si usa el contenedor compilado anteriormente para Windows, el comando run tendría el siguiente aspecto:

docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e

ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e
ASPNETCORE_Kestrel__Certificates__Default__Password="password" -e
ASPNETCORE_Kestrel__Certificates__Default__Path=c:\https\contoso.com.pfx -v c:\certs:C:\https aspnetapp:my-
sample

Una vez que la aplicación esté activa, vaya a contoso.com:8001 en un explorador.

Asegúrese de que las entradas del host se actualizan para que contoso.com responda en la dirección IP adecuada
(por ejemplo, 127.0.0.1). Si no se reconoce el certificado, asegúrese de que el certificado que se carga con el
contenedor también sea de confianza en el host y de que existan entradas SAN/DNS adecuadas para contoso.com .
Limpieza

$cert | Remove-Item
Get-ChildItem $certFilePath | Remove-Item
$rootCert | Remove-item

Con OpenSSL
Puede usar OpenSSL para crear certificados autofirmados. En este ejemplo se usará WSL / Ubuntu y un shell de
bash con OpenSSL .
Esto generará un archivo .crt y otro .key.
 PARENT="contoso.com"
openssl req \
-x509 \
-newkey rsa:4096 \
-sha256 \
-days 365 \
-nodes \
-keyout $PARENT.key \
-out $PARENT.crt \
-subj "/CN=${PARENT}" \
-extensions v3_ca \
-extensions v3_req \
-config <( \
echo '[req]'; \
echo 'default_bits= 4096'; \
echo 'distinguished_name=req'; \
echo 'x509_extension = v3_ca'; \
echo 'req_extensions = v3_req'; \
echo '[v3_req]'; \
echo 'basicConstraints = CA:FALSE'; \
echo 'keyUsage = nonRepudiation, digitalSignature, keyEncipherment'; \
echo 'subjectAltName = @alt_names'; \
echo '[ alt_names ]'; \
echo "DNS.1 = www.${PARENT}"; \
echo "DNS.2 = ${PARENT}"; \
echo '[ v3_ca ]'; \
echo 'subjectKeyIdentifier=hash'; \
echo 'authorityKeyIdentifier=keyid:always,issuer'; \
echo 'basicConstraints = critical, CA:TRUE, pathlen:0'; \
echo 'keyUsage = critical, cRLSign, keyCertSign'; \
echo 'extendedKeyUsage = serverAuth, clientAuth')

openssl x509 -noout -text -in $PARENT.crt

Para obtener un archivo .pfx, use el comando siguiente:

openssl pkcs12 -export -out $PARENT.pfx -inkey $PARENT.key -in $PARENT.crt

NOTE
En el ejemplo .aspnetcore 3.1 se usará .pfx y una contraseña. A partir del entorno de ejecución .net 5 , Kestrel también
puede tomar archivos .crt y .key con codificación PEM.

En función del sistema operativo del host, el certificado tendrá que ser de confianza. En un host de Linux, la
"confianza" en el certificado es diferente y depende de la distribución.
Para los fines de esta guía, este es un ejemplo de Windows con PowerShell:

Import-Certificate -FilePath $certFilePath -CertStoreLocation 'Cert:\LocalMachine\Root'

Para .NET Core 3.1, ejecute el comando siguiente en WSL:

docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e

ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e
ASPNETCORE_Kestrel__Certificates__Default__Password="password" -e
ASPNETCORE_Kestrel__Certificates__Default__Path=/https/contoso.com.pfx -v /c/path/to/certs/:/https/
mcr.microsoft.com/dotnet/samples:aspnetapp
A partir de .NET 5, Kestrel puede tomar los archivos .crt y .key con codificación PEM. Puede ejecutar el ejemplo
con el comando siguiente para .NET 5:

docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e

ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e
ASPNETCORE_Kestrel__Certificates__Default__Path=/https/contoso.com.crt -e
ASPNETCORE_Kestrel__Certificates__Default__KeyPath=/https/contoso.com.key -v /c/path/to/certs:/https/
mcr.microsoft.com/dotnet/samples:aspnetapp

NOTE
Tenga en cuenta que en WSL, la ruta de montaje del volumen puede cambiar en función de la configuración.

Para .NET Core 3.1 en Windows, ejecute el comando siguiente en Powershell :

docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e

ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e
ASPNETCORE_Kestrel__Certificates__Default__Password="password" -e
ASPNETCORE_Kestrel__Certificates__Default__Path=c:\https\contoso.com.pfx -v c:\certs:C:\https aspnetapp:my-
sample

Para .NET 5 en Windows, ejecute el comando siguiente en PowerShell:

docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e

ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e
ASPNETCORE_Kestrel__Certificates__Default__Path=c:\https\contoso.com.crt -e
ASPNETCORE_Kestrel__Certificates__Default__KeyPath=c:\https\contoso.com.key -v c:\certs:C:\https aspnetapp:my-
sample

Una vez que la aplicación esté activa, vaya a contoso.com:8001 en un explorador.

Asegúrese de que las entradas del host se actualizan para que contoso.com responda en la dirección IP adecuada
(por ejemplo, 127.0.0.1). Si no se reconoce el certificado, asegúrese de que el certificado que se carga con el
contenedor también sea de confianza en el host y de que existan entradas SAN/DNS adecuadas para contoso.com .
Limpieza
Asegúrese de limpiar los certificados autofirmados una vez que se hayan realizado las pruebas.

Get-ChildItem $certFilePath | Remove-Item

 Uso de la herramienta WCF Web Service Reference
Provider
18/12/2020 • 6 minutes to read • Edit Online

Durante años, muchos desarrolladores de Visual Studio han disfrutado de la productividad que ofrecía la
herramienta Agregar referencia de ser vicio cuando sus proyectos de .NET Framework necesitaban acceder a
servicios web. La herramienta WCF Web Ser vice Reference Provider es una extensión de servicio conectada
de Visual Studio que proporciona una experiencia similar a la función Agregar referencia de servicio para
proyectos de .NET Core y ASP.NET Core. Esta herramienta recupera metadatos de un servicio web en la solución
actual, en una ubicación de red o desde un archivo WSDL, y genera un archivo de origen compatible con .NET
Core. El archivo contiene el código de proxy de cliente e Windows Communication Foundation (WCF) y podrá
usarlo para acceder al servicio web.

IMPORTANT
Solo debe hacer referencia a servicios desde un origen de confianza. Si agrega referencias desde un origen que no es de
confianza podría poner en peligro la seguridad.

Requisitos previos
Visual Studio 2017, versión 15.5 o versiones posteriores

Cómo utilizar la extensión

NOTE
La opción WCF Web Ser vice Reference (Referencia de servicio web de WCF) se puede aplicar a proyectos creados
mediante las siguientes plantillas de proyecto:
Visual C# > .NET Core
Visual C# > .NET Standard
Visual C# > Web > Aplicación web de ASP.NET Core

En este artículo se usa la plantilla de proyecto Aplicación web de ASP.NET Core para explicar cómo agregar
una referencia de servicio web de WCF al proyecto:
1. En el Explorador de soluciones, haga doble clic en el nodo Ser vicios conectados del proyecto (para un
proyecto de .NET Core o .NET Standard, esta opción está disponible cuando hace clic con el botón derecho
en el nodo Dependencias del proyecto en el Explorador de soluciones).
Aparece la página Ser vicios conectados , como se muestra en esta imagen:
2. En la página Ser vicios conectados , haga clic en Microsoft WCF Web Ser vice Reference Provider .
Se abrirá el asistente para Configurar referencia de ser vicio web de WCF :

3. Seleccione un servicio.
3a. Hay varias opciones de búsqueda de servicios disponibles en el asistente para Configurar referencia
de ser vicio web de WCF :
Para buscar servicios definidos en la solución actual, haga clic en el botón Detectar .
Para buscar servicios hospedados en una dirección específica, escriba la dirección URL del servicio en el
cuadro Dirección y haga clic en el botón Ir .
Para seleccionar un archivo WSDL que contiene la información de metadatos del servicio web, haga clic
en el botón Examinar .
3b. Seleccione el servicio de la lista de resultados de búsqueda en el cuadro Ser vicios . Si es necesario,
 escriba el espacio de nombres para el código generado en el cuadro de texto Espacio de nombres
correspondiente.
3c. Haga clic en el botón Siguiente para abrir las páginas Opciones de tipo de datos y Opciones de
cliente . O bien, haga clic en el botón Finalizar para usar las opciones predeterminadas.
4. El formulario Opciones de tipo de datos permite ajustar los valores de configuración de la referencia de
servicio generada:

NOTE
La opción de la casilla Reutilizar tipos en los ensamblados a los que se hace referencia es útil cuando se
definen los tipos de datos necesarios para la generación de código de referencia de servicio en uno de los
ensamblados de referencia del proyecto. Es importante volver a usar esos tipos de datos existentes para evitar
problemas de tiempo de ejecución o conflictos de tipo de tiempo de compilación.

Puede haber un retraso mientras se carga la información de tipo, en función del número de dependencias
del proyecto y otros factores de rendimiento del sistema. El botón Finalizar está deshabilitado durante la
carga, a menos que la casilla Reutilizar tipos en los ensamblados a los que se hace referencia esté
desactivada.
5. Haga clic en Finalizar cuando haya terminado.
Mientras muestra el progreso, la herramienta:
Descarga los metadatos del servicio WCF.
Genera el código de referencia de servicio en un archivo con el nombre reference.cs y lo agrega al proyecto
bajo el nodo Ser vicios conectados .
Actualiza el archivo de proyecto (.csproj) con las referencias del paquete NuGet necesarias para compilarlo y
ejecutarlo en la plataforma de destino.
Cuando se completan estos procesos, puede crear una instancia del tipo de cliente WCF generado e invocar las
operaciones del servicio.

Vea también
Introducción a las aplicaciones de Windows Communication Foundation
Servicios de Windows Communication Foundation y servicios de datos WCF en Visual Studio
Características compatibles con WCF en .NET Core

Preguntas y comentarios
Si tiene algún comentario sobre el producto, notifíquelo en la Comunidad de desarrolladores mediante la
herramienta Notificar un problema.

Notas de la versión
Eche un vistazo a las notas de la versión para obtener información actualizada sobre la versión, incluidos los
problemas conocidos.
 Herramienta dotnet-svcutil de WCF para .NET Core
02/11/2020 • 6 minutes to read • Edit Online

La herramienta dotnet-svcutil de Windows Communication Foundation (WCF) es una herramienta de .NET que
recupera metadatos de un servicio web en una ubicación de red o de un archivo WSDL, y genera una clase de WCF
que contiene métodos de proxy de cliente que acceden a las operaciones del servicio web.
Similar a la herramienta de utilidad de metadatos de Ser viceModel (Svcutil.exe) para proyectos de .NET
Framework, dotnet-svcutil es una herramienta de línea de comandos para generar una referencia de servicio
web compatible con proyectos de .NET Core y .NET Standard.
La herramienta dotnet-svcutil es una alternativa al proveedor de servicios conectados de Visual Studio WCF
Web Ser vice Reference que se distribuyó por primera vez en la versión 15.5 de Visual Studio 2017. La
herramienta multiplataforma dotnet-svcutil , como herramienta de .NET, está disponible en Linux, macOS y
Windows.

IMPORTANT
Solo debe hacer referencia a servicios desde un origen de confianza. Si agrega referencias desde un origen que no es de
confianza podría poner en peligro la seguridad.

Requisitos previos
dotnet-svcutil 2.x
dotnet-svcutil 1.x
SDK de .NET Core 2.1 o versiones posteriores
Su editor de código favorito

Introducción
En el ejemplo siguiente se le guía por los pasos necesarios para agregar una referencia de servicio web a un
proyecto web de .NET Core e invocar el servicio. Creará una aplicación web de .NET Core denominada HelloSvcutil
y agregará una referencia a un servicio web que implementa el siguiente contrato:

[ServiceContract]
public interface ISayHello
{
[OperationContract]
string Hello(string name);
}

En este ejemplo, se da por hecho que el servicio web se hospedará en la siguiente dirección:
http://contoso.com/SayHello.svc

Desde una ventana de comandos de Windows, Mac OS o Linux, siga estos pasos:
1. Cree un directorio denominado HelloSvcutil para el proyecto y hágalo su directorio actual, como en el
ejemplo siguiente:
 mkdir HelloSvcutil
cd HelloSvcutil

2. Cree un nuevo proyecto web de C# en ese directorio mediante el comando dotnet new del modo siguiente:

dotnet new web

3. Instale el paquete NuGet dotnet-svcutil como herramienta CLI:

dotnet-svcutil 2.x
dotnet-svcutil 1.x

dotnet tool install --global dotnet-svcutil

4. Ejecute el comando dotnet-svcutil para generar el archivo de referencia del servicio web de la siguiente
manera:
dotnet-svcutil 2.x
dotnet-svcutil 1.x

dotnet-svcutil http://contoso.com/SayHello.svc

El archivo generado se guarda como HelloSvcutil/ServiceReference1/Reference.cs. La herramienta dotnet_svcutil

también agrega al proyecto los paquetes de WCF adecuados que necesita el código de proxy como referencias del
paquete.

Uso de la referencia de servicio

1. Restaure los paquetes de WCF mediante el comando dotnet restore como sigue:

dotnet restore

2. Busque el nombre de la clase de cliente y la operación que quiera usar. Reference.cs contendrá una clase
que se hereda de System.ServiceModel.ClientBase , con métodos que pueden usarse para llamar a las
operaciones del servicio. En este ejemplo, quiere llamar a la operación Hello del servicio SayHello.
ServiceReference.SayHelloClient es el nombre de la clase de cliente, y tiene un método llamado
HelloAsync que se puede usar para llamar a la operación.

3. Abra el archivo Startup.cs en el editor y agregue una directiva using al espacio de nombres de la
referencia de servicio en la parte superior:

using ServiceReference;

4. Edite el método Configure para invocar el servicio web. Para ello, cree una instancia de la clase que se
hereda de ClientBase y llame al método en el objeto de cliente:
 public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}

app.Run(async (context) =>

{
var client = new SayHelloClient();
var response = await client.HelloAsync();
await context.Response.WriteAsync(response);
});
}

5. Ejecute la aplicación con el comando dotnet run como sigue:

dotnet run

6. Vaya a la dirección URL indicada en la consola (por ejemplo, http://localhost:5000 ) en el explorador web.
Debería ver los siguientes resultados: "Hello dotnet-svcutil!"
Para obtener una descripción detallada de los parámetros de la herramienta dotnet-svcutil , invoque la
herramienta pasando el parámetro de ayuda del siguiente modo:
dotnet-svcutil 2.x
dotnet-svcutil 1.x

dotnet-svcutil --help

Preguntas y comentarios
Si tiene preguntas o comentarios, abra un problema en GitHub. También puede revisar las preguntas o problemas
que ya se han planteado en el repositorio de WCF en GitHub.

Notas de la versión
Eche un vistazo a las notas de la versión para obtener información actualizada sobre la versión, incluidos los
problemas conocidos.

Información
Paquete NuGet svcutil dotnet
 Uso de dotnet-svcutil.xmlserializer en .NET Core
02/11/2020 • 3 minutes to read • Edit Online

El paquete NuGet dotnet-svcutil.xmlserializer puede generar previamente un ensamblado de serialización para

los proyectos de .NET Core. Genera previamente código de serialización de C# para los tipos de la aplicación
cliente que usa el contrato de servicio de WCF y que puede serializar XmlSerializer. Esto mejora el rendimiento de
inicio de la serialización de XML al serializar o deserializar objetos de esos tipos.

Requisitos previos
SDK de .NET Core 2.1 o versiones posteriores
Su editor de código favorito
Puede usar el comando dotnet --info para comprobar qué versiones del SDK de .NET Core y del Runtime ya ha
instalado.

Introducción
Para usar dotnet-svcutil.xmlserializer en una aplicación de consola de .NET Core:
1. Crea un servicio WCF denominado "MyWCFService" mediante la plantilla predeterminada "Aplicación del
servicio WCF" en .NET Framework. Agregue el atributo [XmlSerializerFormat] al método de servicio similar
al siguiente:

[ServiceContract]
public interface IService1
{
[XmlSerializerFormat]
[OperationContract(Action = "http://tempuri.org/IService1/GetData", ReplyAction =
"http://tempuri.org/IService1/GetDataResponse")]
string GetData(int value);
}

2. Cree una aplicación de consola de .NET Core como aplicación cliente de WCF que tenga como destino .NET
Core 2.1 o versiones posteriores. Por ejemplo, cree una aplicación denominada "MyWCFClient" con el
comando siguiente:

dotnet new console --name MyWCFClient

Para asegurarse de que el proyecto está destinado a .NET Core 2.1 o una versión posterior, inspeccione el
elemento XML TargetFramework del archivo de proyecto:

<TargetFramework>netcoreapp2.1</TargetFramework>

3. Ejecute el comando siguiente para agregar una referencia de paquete a System.ServiceModel.Http :

dotnet add package System.ServiceModel.Http

4. Agregue el código del cliente WCF:

 using System.ServiceModel;

class Program
{
static void Main(string[] args)
{
var myBinding = new BasicHttpBinding();
var myEndpoint = new EndpointAddress("http://localhost:2561/Service1.svc"); //Fill your
service url here
var myChannelFactory = new ChannelFactory<IService1>(myBinding, myEndpoint);
IService1 client = myChannelFactory.CreateChannel();
string s = client.GetData(1);
((ICommunicationObject)client).Close();
}
}

[ServiceContract]
public interface IService1
{
[XmlSerializerFormat]
[OperationContract(Action = "http://tempuri.org/IService1/GetData", ReplyAction =
"http://tempuri.org/IService1/GetDataResponse")]
string GetData(int value);
}

5. Agregue una referencia al paquete dotnet-svcutil.xmlserializer mediante la ejecución del comando

siguiente:

dotnet add package dotnet-svcutil.xmlserializer

Al ejecutar el comando se debería agregar una entrada al archivo de proyecto similar a la siguiente:

<ItemGroup>
<DotNetCliToolReference Include="dotnet-svcutil.xmlserializer" Version="1.0.0" />
</ItemGroup>

6. Compile la aplicación ejecutando dotnet build . Si todo se realiza correctamente, se genera un ensamblado
denominado MyWCFClient.XmlSerializers.dll en la carpeta de salida. Si la herramienta no pudo generar el
ensamblado, verá advertencias en la salida de la compilación.
7. Inicie el servicio WCF, por ejemplo, mediante la ejecución de http://localhost:2561/Service1.svc en el
explorador. Después, inicie la aplicación cliente, que se cargará automáticamente y utilizará los
serializadores generados previamente en tiempo de ejecución.
 Usar el generador de serializador XML de Microsoft
en .NET Core
02/11/2020 • 5 minutes to read • Edit Online

Este tutorial muestra cómo usar el generador de serializador XML de Microsoft en una aplicación .NET Core de C#.
Este tutorial ayuda a:
Cómo crear una aplicación .NET Core
Cómo agregar una referencia al paquete Microsoft.XmlSerializer.Generator
Cómo editar MyApp.csproj para agregar dependencias
Cómo agregar una clase y un XmlSerializer
Cómo compilar y ejecutar la aplicación
Tal y como sucede con el generador de serializador de XML (sgen.exe) para .NET Framework, el paquete
Microsoft.XmlSerializer.Generator de NuGet es el equivalente para proyectos de .NET Core y .NET Standard. Crea un
ensamblado de serialización de XML para los tipos contenidos en un ensamblado para mejorar el rendimiento de
inicio de la serialización XML al serializar o deserializar objetos de esos tipos con XmlSerializer.

Requisitos previos
Para realizar este tutorial:
SDK de .NET Core 2.1 o versiones posteriores.
Su editor de código favorito.

TIP
¿Es necesario instalar un editor de código? Pruebe Visual Studio.

Usar el generador de serializador de XML de Microsoft en una

aplicación de consola .NET Core
Las instrucciones siguientes muestran cómo usar el generador de serializador XML en una aplicación de consola
.NET Core.
Creación de una aplicación de consola .NET Core
Abra un símbolo del sistema y cree una carpeta denominada MyApp. Vaya a la carpeta que creó y escriba estos
comandos:

dotnet new console

Agregue una referencia al paquete Microsoft.XmlSerializer.Generator en el proyecto de MyApp

Use el comando dotnet add package para agregar la referencia en el proyecto.
Tipo:

dotnet add package Microsoft.XmlSerializer.Generator -v 1.0.0

Comprobar los cambios en MyApp.csproj después de agregar el paquete
Abra el editor de código para empezar. Todavía estamos trabajando desde el directorio MyApp en el que hemos
compilado la aplicación.
Abra MyApp.csproj en el editor de texto.
Después de ejecutar el comando dotnet add package , se agregan estas líneas al archivo de proyecto MyApp.csproj:

<ItemGroup>
<PackageReference Include="Microsoft.XmlSerializer.Generator" Version="1.0.0" />
</ItemGroup>

Agregar otra sección ItemGroup para admitir la herramienta CLI de .NET Core
Agregue estas líneas después de la sección ItemGroup que hemos inspeccionado:

<ItemGroup>
<DotNetCliToolReference Include="Microsoft.XmlSerializer.Generator" Version="1.0.0" />
</ItemGroup>

Agregar una clase en la aplicación

Abra Program.cs en el editor de texto. Agregue la clase con el nombre MyClass en Program.cs.

public class MyClass

{
public int Value;
}

Crear un XmlSerializer para MyClass

Agregue esta línea dentro de Main para crear un XmlSerializer para MyClass:

var serializer = new System.Xml.Serialization.XmlSerializer(typeof(MyClass));

Compilar y ejecutar la aplicación

Seguimos en la carpeta MyApp, desde donde vamos a ejecutar la aplicación mediante dotnet run . Se carga
automáticamente y usa los serializadores generados previamente en tiempo de ejecución.
Escriba el siguiente comando en la ventana de consola:

dotnet run

NOTE
dotnet run llama a dotnet build para asegurarse de que los destinos de la compilación se han creado y, después, llama a
dotnet <assembly.dll> para ejecutar la aplicación de destino.

IMPORTANT
Los comandos y los pasos que se muestran en este tutorial para ejecutar la aplicación se usan solo durante el desarrollo. Una
vez que esté listo para implementar la aplicación, eche un vistazo a las diferentes estrategias de implementación para
aplicaciones .NET Core y al comando dotnet publish .
Si todo se realiza correctamente, se genera un ensamblado con el nombre .dll MyApp.XmlSerializers.dll en la
carpeta de salida.
¡Enhorabuena! Acaba de:
Crear una aplicación .NET Core.
Agregar una referencia al paquete Microsoft.XmlSerializer.Generator.
Editar MyApp.csproj para agregar dependencias.
Agregue una clase y un XmlSerializer.
Compilar y ejecutar la aplicación.

Recursos relacionados
Introducción a la serialización XML
Serialización con XmlSerializer (C#)
Cómo: Serializar con XmlSerializer (Visual Basic)
 ¿Qué herramientas de diagnóstico están disponibles
en .NET Core?
18/12/2020 • 6 minutes to read • Edit Online

El comportamiento del software no siempre es el esperado, pero .NET Core tiene herramientas y API que lo
ayudarán a diagnosticar estos problemas de manera rápida y eficaz.
Este artículo lo ayuda a encontrar las distintas herramientas que necesita.

Depuradores administrados
Los depuradores administrados le permiten interactuar con el programa. Pausar, ejecutar de manera incremental,
examinar y reanudar le proporcionan información sobre el comportamiento del código. Un depurador es la
primera opción para diagnosticar problemas funcionales que se pueden reproducir de manera fácil.

Registro y seguimiento
El registro y seguimiento son técnicas relacionadas. Hacen referencia a la instrumentación del código para crear
archivos de registro. Los archivos registran los detalles de lo que hace un programa. Estos detalles se pueden usar
para diagnosticar los problemas más complejos. Cuando se combinan con marcas de tiempo, estas técnicas
también son valiosas para investigaciones de rendimiento.

Pruebas unitarias
Las pruebas unitarias son un componente clave de la integración continua y la implementación de software de alta
calidad. Las pruebas unitarias están diseñadas para brindarle una advertencia temprana cuando se daña algo.

Volcados
Un volcado es un archivo que contiene una instantánea del proceso en el momento de la creación. Pueden ser
útiles para examinar el estado de la aplicación con fines de depuración.

Recopilación de diagnósticos en contenedores

Las herramientas de diagnóstico que se usan en los entornos de Linux que no están en contenedores también se
pueden utilizar para recopilar diagnósticos en contenedores. Solo es necesario realizar algunos cambios en la
utilización para asegurarse de que las herramientas funcionan en un contenedor de Docker.

Depuración de volcados de Linux

Depuración de volcados de Linux explica cómo recopilar y analizar volcados en Linux.

Herramientas globales de diagnóstico de .NET Core

dotnet-counters
dotnet-counters es una herramienta diseñada para la investigación del rendimiento y la supervisión del estado de
primer nivel. Permite observar los valores del contador de rendimiento que se publican a través de la API
EventCounter. Por ejemplo, puede supervisar rápidamente elementos como el uso de la CPU o la tasa de
excepciones que se generan en su aplicación .NET Core.
dotnet-dump
La herramienta dotnet-dump permite recopilar y analizar los volcados de Windows y Linux sin necesidad de un
depurador nativo.
dotnet-gcdump
La herramienta dotnet-gcdump permite recopilar volcados de memoria de GC (recolector de elementos no
utilizados) de procesos de .NET dinámicos.
dotnet-trace
.NET Core incluye lo que se denomina EventPipe , a través del cual se exponen los datos de diagnóstico. La
herramienta dotnet-trace permite consumir datos interesantes sobre la generación de perfiles a partir de su
aplicación, lo cual puede resultar útil para analizar la causa principal de que una aplicación se ejecute con lentitud.
dotnet-symbol
dotnet-symbol descarga archivos (símbolos, DAC/DBI, archivos de host, etc.) necesarios para abrir un volcado de
núcleo o minivolcado. Use esta herramienta si necesita símbolos y módulos para depurar un archivo de volcado
capturado en otro equipo.
dotnet-sos
dotnet-SOS se usa para instalar la extensión de depuración de SOS en Linux o MacOS (o en Windows si se usan
herramientas de depuración anteriores).
PerfCollect
PerfCollect es un script de bash que se puede usar para recopilar seguimientos con perf y LTTng para un análisis
de rendimiento más detallado de las aplicaciones .NET que se ejecutan en distribuciones de Linux.

Tutoriales de diagnóstico de .NET Core

Depuración de una fuga de memoria
Tutorial: Depuración de una fuga de memoria le guía a través de la búsqueda de una fuga de memoria. La
herramienta dotnet-counters se usa para confirmar la fuga, y la herramienta dotnet-dump, para diagnosticarla.
Depuración del uso elevado de CPU
Tutorial: Depuración del uso elevado de CPU le guía a través de la investigación del uso elevado de CPU. Utiliza la
herramienta dotnet-counters para confirmar ese uso elevado. A continuación, se explica el uso del seguimiento de
la utilidad de análisis del rendimiento ( dotnet-trace ) o de Linux perf para recopilar y ver el perfil de uso de la
CPU.
Depuración de interbloqueo
Tutorial: Depuración de interbloqueo muestra cómo usar la herramienta dotnet-dump para investigar los
subprocesos y bloqueos.
Medición del rendimiento mediante EventCounters
Tutorial: Medición del rendimiento mediante EventCounters en .NET muestra cómo usar la API EventCounter para
medir el rendimiento de la aplicación .NET.
 Depuradores administrados de .Net Core
02/11/2020 • 2 minutes to read • Edit Online

Los depuradores permiten a los programas pausarse o ejecutarse paso a paso. Cuando se pausa, se puede ver el
estado actual del proceso. Al recorrer las secciones clave, se entiende mejor el código y el motivo por el que genera
determinado resultado.
Microsoft proporciona depuradores para código administrado en Visual Studio y Visual Studio Code .

Depurador administrado de Visual Studio

Visual Studio es un entorno de desarrollo integrado con el depurador más completo disponible. Visual Studio es
una opción excelente para los desarrolladores que trabajan en Windows.
Tutorial: Depuración de una aplicación .NET Core en Windows con Visual Studio
Aunque Visual Studio es una aplicación de Windows, se puede usar para depurar aplicaciones de Linux y macOS
de forma remota.
Depuración de una aplicación .NET Core en Linux/OSX con Visual Studio
La depuración de aplicaciones ASP.NET Core requiere instrucciones ligeramente distintas.
Depuración de aplicaciones ASP.NET Core en Visual Studio

Depurador administrado de Visual Studio Code

Visual Studio Code es un editor de código ligero y multiplataforma. Usa la misma implementación de depurador
de .NET Core que Visual Studio, pero con una interfaz de usuario simplificada.
Tutorial: Depuración de una aplicación .NET Core con Visual Studio
Debugging in Visual Studio Code (Depuración en Visual Studio Code)
 Volcados
18/12/2020 • 6 minutes to read • Edit Online

Un volcado de memoria es un archivo que contiene una instantánea del proceso en el momento en que se ha
creado y puede ser útil para examinar el estado de la aplicación. Los volcados de memoria se pueden usar para
depurar la aplicación de .NET cuando es difícil asociarle un depurador, como los entornos de producción o de CI. El
uso de volcados de memoria permite capturar el estado del proceso con problemas y examinarlo sin tener que
detener la aplicación.

Recopilación de volcados de memoria

Los volcados de memoria se pueden recopilar de varias maneras, en función de la plataforma en la que se ejecute
la aplicación.

NOTE
La recopilación de un volcado de memoria dentro de un contenedor requiere la funcionalidad PTRACE, que se puede agregar
a través de --cap-add=SYS_PTRACE o --privileged .

NOTE
Los volcados de memoria pueden incluir información confidencial, ya que pueden contener la memoria completa del proceso
en ejecución. Para controlarlos, siga las restricciones e instrucciones de seguridad.

Recopilación de volcados de memoria durante un bloqueo

Puede usar variables de entorno a fin de configurar la aplicación para que recopile un volcado de memoria tras un
bloqueo. Esto resulta útil si quiere comprender por qué se ha producido un bloqueo. Por ejemplo, la captura de un
volcado de memoria cuando se inicia una excepción le ayuda a identificar un problema mediante el examen del
estado de la aplicación en el momento del bloqueo.
En la tabla siguiente se muestran las variables de entorno que se pueden configurar para la recopilación de
volcados de memoria en caso de bloqueo.

VA RIA B L E DE EN TO RN O DESC RIP C IÓ N VA LO R P REDET ERM IN A DO

COMPlus_DbgEnableMiniDump Si se establece en 1, se habilita la 0

generación de volcado de memoria
principal.

COMPlus_DbgMiniDumpType Tipo de volcado de memoria que se va 2(

a recopilar. Para obtener más MiniDumpWithPrivateReadWriteMemory
información, vea la tabla siguiente. )

COMPlus_DbgMiniDumpName Ruta de acceso a un archivo en el que /tmp/coredump.<pid>

se escribirá el volcado de memoria.

COMPlus_CreateDumpDiagnostics Si se establece en 1, se habilita el 0

registro de diagnóstico del proceso de
volcado.
En la tabla siguiente se muestran todas las opciones que puede usar para COMPlus_DbgMiniDumpType que se pueden
especificar como un valor. Por ejemplo, si COMPlus_DbgMiniDumpType se establece en 1, significa que el volcado de
tipo MiniDumpNormal se recopilará al producirse un bloqueo.

VA L UE N O M B RE DESC RIP C IÓ N

1 MiniDumpNormal Incluya solo la información necesaria

para capturar seguimientos de pila para
todos los subprocesos existentes en un
proceso. Información y memoria del
montón de GC limitadas.

2 MiniDumpWithPrivateReadWriteMemory Incluye la información y los montones

de GC necesarios para capturar
seguimientos de pila para todos los
subprocesos existentes en un proceso.

3 MiniDumpFilterTriage Incluya solo la información necesaria

para capturar seguimientos de pila para
todos los subprocesos existentes en un
proceso. Información y memoria del
montón de GC limitadas.

4 MiniDumpWithFullMemory Incluya toda la memoria accesible en el

proceso. Los datos de memoria sin
procesar se incluyen al final, de modo
que las estructuras iniciales se pueden
asignar directamente sin la información
de memoria sin procesar. Esta opción
puede dar lugar a un archivo muy
grande.

Recopilación de volcados de memoria en un momento dado

Es posible que quiera recopilar un volcado de memoria cuando la aplicación todavía no se ha bloqueado. Por
ejemplo, si quiere examinar el estado de una aplicación que parece estar en un interbloqueo, la configuración de
las variables de entorno para recopilar volcados de memoria al producirse un bloqueo no será útil porque la
aplicación todavía está en ejecución.
Para recopilar el volcado de memoria cuando prefiera, puede usar dotnet-dump , que es una herramienta de la CLI
para la recopilación y el análisis de volcados de memoria. Para obtener más información sobre cómo usarla para
recopilar volcados de memoria con dotnet-dump , vea Utilidad de recopilación y análisis de volcados de memoria.

Análisis de volcados de memoria

Los volcados de memoria se pueden analizar mediante dotnet-dump .

Consulte también
Obtenga más información sobre cómo puede aprovechar los volcados de memoria para ayudar a diagnosticar
problemas en la aplicación de .NET.
En el tutorial Depuración de volcados de Linux se le guía a través de la depuración de un volcado de
memoria recopilado en Linux.
En el tutorial Depuración de interbloqueo se le guía a través de la depuración de un interbloqueo en la
aplicación de .NET mediante volcados de memoria.
 Depuración de volcados de memoria de Linux
18/12/2020 • 8 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores

Recopilación de volcados de memoria en Linux

Las dos formas recomendadas de recopilar volcados en Linux es mediante las herramientas dotnet-dump o
createdump .

Volcados administrados con dotnet-dump

La herramienta dotnet-dump es fácil de usar y no depende de ningún depurador nativo. dotnet-dump funciona en
una amplia variedad de plataformas Linux (como Alpine o ARM32/ARM64) donde las herramientas tradicionales
de depuración pueden no estar disponibles. Pero dotnet-dump solo captura el estado administrado, por lo que no
se puede usar para la depuración de problemas en código nativo. Los volcados de memoria recopilados por
dotnet-dump se analizan en un entorno con el mismo sistema operativo y la misma arquitectura con los que se ha
creado el volcado de memoria. La herramienta dotnet-gcdump se puede usar como alternativa, ya que solo captura
información del montón de recolección de elementos no utilizados (GC), pero genera volcados que se puedan
analizar en Windows.
Volcados de núcleo con createdump

Como alternativa a dotnet-dump , que crea volcados solo de información administrada, createdump es la
herramienta recomendada para crear volcados de núcleo en Linux que contienen tanto información nativa como
administrada. También se pueden usar otras herramientas como gdb o gcore para crear volcados de núcleo, pero
puede omitir el estado necesario para la depuración administrada, lo que puede dar lugar a nombres de función o
de tipo desconocidos durante el análisis.
La herramienta createdump se instala con el entorno de ejecución de .NET y se puede encontrar junto a
libcoreclr.so (normalmente en "/usr/share/dotnet/shared/Microsoft.NETCore.App/[versión]"). Esta herramienta
toma un identificador de proceso para recopilar un volcado de su argumento principal, y también puede tomar
parámetros opcionales que especifican el tipo de volcado que se va a recopilar (el valor predeterminado es un
minivolcado con montón). Las opciones son:
<input-filename>

Archivo de seguimiento de entrada que se va a convertir. El valor predeterminado es trace.nettrace.

Opciones
-f|--name <output-filename>

Archivo en el que se escribirá el volcado. El valor predeterminado es "/tmp/coredump.%p", donde "%p" es

el identificador del proceso de destino.
-n|--normal

Creación de un minivolcado.
-h|--withheap

Creación de un minivolcado con montón (valor predeterminado).

-t|--triage
 Creación de un minivolcado de evaluación de prioridades.
-u|--full

Creación de un volcado de núcleo completo.

-d|--diag

Habilitación de mensajes de diagnóstico.

La recopilación de volcados de núcleo requiere la capacidad SYS_PTRACE o la ejecución de createdump con sudo o
su.

Análisis de volcados de memoria en Linux

Los volcados de memoria recopilados con dotnet-dump y los volcados de núcleo recopilados con createdump se
pueden analizar con la herramienta dotnet-dump mediante el comando dotnet-dump analyze . dotnet dump
requiere que el entorno que analiza el volcado tenga el mismo sistema operativo y la misma arquitectura que el
entorno en el que se capturó el volcado.
Como alternativa, se puede usar LLDB para analizar los volcados de núcleo en Linux, ya que permite el análisis de
marcos administrados y nativos. LLDB usa la extensión SOS para depurar el código administrado. La herramienta
de la CLI dotnet-sos se puede usar para instalar SOS, que tiene muchos comandos útiles para depurar código
administrado. Para poder analizar los volcados de .NET Core, LLDB y SOS requieren los siguientes archivos
binarios de .NET Core del entorno en el que se creó el volcado:
1. libmscordaccore.so
2. libcoreclr.so
3. dotnet (host usado para iniciar la aplicación)
En la mayoría de los casos, estos archivos binarios se pueden descargar mediante la herramienta dotnet-symbol .
Si no se pueden descargar los archivos binarios necesarios con dotnet-symbol (por ejemplo, si está en uso una
versión privada de .NET Core creada a partir de un origen), puede que sea necesario copiar los archivos
enumerados anteriormente desde el entorno en el que se creó el volcado. Si los archivos no se encuentran junto al
archivo de volcado de memoria, puede usar el comando setclrpath <path> de LLDB/SOS para establecer la ruta
de acceso desde la que se deben cargar, y setsymbolserver -directory <path> para establecer la ruta de acceso de
los archivos de símbolos.
Una vez que están disponibles los archivos necesarios, el volcado de memoria se puede cargar en LLDB
especificando el host de dotnet como el ejecutable que se va a depurar:

lldb --core <dump-file> <host-program>

En la línea de comandos anterior, <dump-file> es la ruta de acceso del volcado que se va a analizar y
<host-program> es el programa nativo que inició la aplicación .NET Core. Este suele ser el archivo binario dotnet ,
a menos que la aplicación sea independiente, en cuyo caso es el nombre de la aplicación sin la extensión .dll.
Una vez que se inicia LLDB, puede que sea necesario usar el comando setsymbolserver para apuntar a la
ubicación de los símbolos correcta ( setsymbolserver -ms para usar el servidor de símbolos de Microsoft o
setsymbolserver -directory <path> para especificar una ruta de acceso local). Los símbolos nativos se pueden
cargar mediante la ejecución de loadsymbols . En este punto, se pueden usar comandos SOS para analizar el
volcado de memoria.

Consulte también
dotnet-sos para obtener más información sobre la instalación de la extensión SOS.
dotnet-symbol para obtener más información sobre la instalación y el uso de la herramienta de descarga de
símbolos.
Repositorio de diagnósticos de .NET Core para obtener más información sobre la depuración, incluidas las
preguntas más frecuentes.
Instalación de LLDB para obtener instrucciones sobre la instalación de LLDB en Linux o Mac.
 EventCounters de .NET Core
18/12/2020 • 24 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores
Los EventCounters son las API de .NET Core que se usan para la recopilación ligera, multiplataforma y casi en
tiempo real de métricas de rendimiento. Los EventCounters se agregaron como una alternativa multiplataforma a
los "contadores de rendimiento" de .NET Framework en Windows. En este artículo se aprende qué son los
EventCounters, cómo se implementan y cómo se usan.
El entorno de ejecución de .NET Core y algunas bibliotecas de .NET publican información de diagnóstico básica
mediante EventCounters a partir de .NET Core 3.0. Además de los EventCounters proporcionados por el entorno de
ejecución de .NET, puede implementar sus propios EventCounters. Los EventCounters se pueden usar para realizar
el seguimiento de diversas métricas.
Los EventCounters existen como parte de EventSource y se insertan automáticamente en las herramientas de
escucha de forma periódica. Al igual que todos los demás eventos de EventSource, se pueden consumir en proceso
y fuera de proceso mediante EventListener y EventPipe. Este artículo se centra en las capacidades multiplataforma
de los EventCounters y excluye de forma deliberada a PerfView y ETW (seguimiento de eventos para Windows),
aunque ambos se pueden usar con los EventCounters.

Out-of-proc

dotnet-counters
EventSource
EventPipe
dotnet-trace
EventCounter

EventCounter In-proc

EventCounter EventListener

Available counters
Throughout various .NET packages, basic metrics on Garbage Collection (GC), Just-in-Time (JIT), assemblies,
exceptions, threading, networking, and web requests are published using EventCounters.
"System.Runtime" counters
The following counters are published as part of .NET runtime, and are maintained in the RuntimeEventSource.cs .

C O UN T ER DESC RIP T IO N

% Time in GC since last GC ( time-in-gc ) The percent of time in GC since the last GC

Allocation Rate ( alloc-rate ) The number of bytes allocated per update interval

CPU Usage ( cpu-usage ) The percent of CPU usage of the process

C O UN T ER DESC RIP T IO N

Exception Count ( exception-count ) The number of exceptions that have occurred

GC Heap Size ( gc-heap-size ) The number of bytes thought to be allocated based on

GC.GetTotalMemory(Boolean)

Gen 0 GC Count ( gen-0-gc-count ) The number of times GC has occurred for Gen 0

Gen 0 Size ( gen-0-size ) The number of bytes for Gen 0 GC

Gen 1 GC Count ( gen-1-gc-count ) The number of times GC has occurred for Gen 1

Gen 1 Size ( gen-1-size ) The number of bytes for Gen 1 GC

Gen 2 GC Count ( gen-2-gc-count ) The number of times GC has occurred for Gen 2

Gen 2 Size ( gen-2-size ) The number of bytes for Gen 2 GC

LOH Size ( loh-size ) The number of bytes for Gen 3 GC

POH Size ( poh-size ) The number of bytes for the pinned object heap (available on
.NET 5 and later versions)

GC Fragmentation ( gc-fragmentation ) The GC Heap Fragmentation (available on .NET 5 and later

versions)

Monitor Lock Contention Count ( The number of times there was contention when trying to
monitor-lock-contention-count ) take the monitor's lock, based on
Monitor.LockContentionCount

Number of Active Timers ( active-timer-count ) The number of Timer instances that are currently active, based
on Timer.ActiveCount

Number of Assemblies Loaded ( assembly-count ) The number of Assembly instances loaded into a process at a
point in time

ThreadPool Completed Work Item Count ( The number of work items that have been processed so far in
threadpool-completed-items-count ) the ThreadPool

ThreadPool Queue Length ( threadpool-queue-length ) The number of work items that are currently queued to be
processed in the ThreadPool

ThreadPool Thread Count ( threadpool-thread-count ) The number of thread pool threads that currently exist in the
ThreadPool, based on ThreadPool.ThreadCount

Working Set ( working-set ) The amount of physical memory mapped to the process
context at a point in time base on Environment.WorkingSet

IL Bytes Jitted ( il-bytes-jitted ) The total size of ILs that are JIT-compiled, in bytes (available
on .NET 5 and later versions)

Method Jitted Count ( method-jitted-count ) The number of methods that are JIT-compiled (available on
.NET 5 and later versions)
"Microsoft.AspNetCore.Hosting" counters
The following counters are published as part of ASP.NET Core and are maintained in HostingEventSource.cs .

C O UN T ER DESC RIP T IO N

Current Requests ( current-requests ) The total number of requests that have started, but not yet
stopped

Failed Requests ( failed-requests ) The total number of failed requests that have occurred for the
life of the app

Request Rate ( requests-per-second ) The number of requests that occur per update interval

Total Requests ( total-requests ) The total number of requests that have occurred for the life of
the app

"Microsoft.AspNetCore.Http.Connections" counters
The following counters are published as part of ASP.NET Core SignalR and are maintained in
HttpConnectionsEventSource.cs .

C O UN T ER DESC RIP T IO N

Average Connection Duration ( connections-duration ) The average duration of a connection in milliseconds

Current Connections ( current-connections ) The number of active connections that have started, but not
yet stopped

Total Connections Started ( connections-started ) The total number of connections that have started

Total Connections Stopped ( connections-stopped ) The total number of connections that have stopped

Total Connections Timed Out ( connections-timed-out ) The total number of connections that have timed out

"Microsoft-AspNetCore -Server-Kestrel" counters

The following counters are published as part of the ASP.NET Core Kestrel web server and are maintained in
KestrelEventSource.cs .

C O UN T ER DESC RIP T IO N

Connection Queue Length ( connection-queue-length ) The current length of the connection queue

Connection Rate ( connections-per-second ) The number of connections per update interval to the web
server

Current Connections ( current-connections ) The current number of active connections to the web server

Current TLS Handshakes ( current-tls-handshakes ) The current number of TLS handshakes

Current Upgraded Requests (WebSockets) ( The current number of upgraded requests (WebSockets)
current-upgraded-requests )

Failed TLS Handshakes ( failed-tls-handshakes ) The total number of failed TLS handshakes
 C O UN T ER DESC RIP T IO N

Request Queue Length ( request-queue-length ) The current length of the request queue

TLS Handshake Rate ( tls-handshakes-per-second ) The number of TLS handshakes per update interval

Total Connections ( total-connections ) The total number of connections to the web server

Total TLS Handshakes ( total-tls-handshakes ) The total number of TLS handshakes with the web server

Información general sobre la API EventCounter

Hay dos categorías principales de contadores. Algunos contadores son para valores de tipo "tasa", como el número
total de excepciones, el número total de GC y el número total de solicitudes. Otros contadores son valores de tipo
"instantánea", como el uso del montón, el uso de la CPU y el tamaño del espacio de trabajo. Dentro de cada una de
estas categorías de contadores, hay dos tipos de contadores que varían según el modo en que obtienen su valor.
Los contadores de sondeo recuperan su valor por medio de una devolución de llamada, mientras que los
contadores que no son de sondeo tienen sus valores establecidos directamente en la instancia de contador.
Los contadores se representan mediante las siguientes implementaciones:
EventCounter
IncrementingEventCounter
IncrementingPollingCounter
PollingCounter
Una escucha de eventos especifica la duración de los intervalos de medición. Al final de cada intervalo se transmite
un valor a la escucha de cada contador. Las implementaciones de un contador determinan las API y los cálculos que
se usan para generar el valor de cada intervalo.
1. EventCounter registra un conjunto de valores. El método EventCounter.WriteMetric agrega un nuevo valor al
conjunto. Con cada intervalo se calcula un resumen estadístico del conjunto, como valor mínimo, máximo y
medio. La herramienta dotnet-counters siempre muestra el valor medio. EventCounter es útil para describir
un conjunto discreto de operaciones. Su uso habitual puede incluir la supervisión del tamaño medio en
bytes de operaciones de E/S recientes o el valor monetario medio de un conjunto de transacciones
financieras.
2. IncrementingEventCounter registra un total acumulado de cada intervalo de tiempo. El método
IncrementingEventCounter.Increment agrega al total. Por ejemplo, si se llama a Increment() tres veces
durante un intervalo con valores 1 , 2 y 5 , el total acumulado de 8 se comunica como valor del
contador de este intervalo. La herramienta dotnet-counters muestra la tasa como el total / tiempo
registrado. IncrementingEventCounter resulta útil para medir la frecuencia con que se produce una acción,
como el número de solicitudes procesadas por segundo.
3. PollingCounter usa una devolución de llamada para determinar el valor que se comunica. Con cada intervalo
de tiempo se invoca a la función de devolución de llamada proporcionada por el usuario y se usa el valor
devuelto como valor del contador. PollingCounter se puede usar para consultar una métrica de un origen
externo, por ejemplo, para obtener los bytes libres actuales en un disco. También se puede usar para
notificar estadísticas personalizadas que una aplicación puede calcular a petición. Los ejemplos incluyen los
informes del percentil 95 de las latencias de solicitud recientes o la proporción de aciertos o errores actual
de una caché.
4. IncrementingPollingCounter usa una devolución de llamada para determinar el valor de incremento
comunicado. Con cada intervalo de tiempo se invoca a la devolución de llamada y la diferencia entre la
 invocación actual y la última es el valor comunicado. La herramienta dotnet-counters siempre muestra la
diferencia como una tasa, el valor / tiempo comunicado. Este contador es útil cuando no resulta factible
llamar a una API en cada repetición, pero es posible consultar el número total de repeticiones. Por ejemplo,
puede notificar el número de bytes escritos en un archivo por segundo, incluso sin una notificación cada vez
que se escribe un byte.

Implementación de un EventSource
En el código siguiente se implementa un ejemplo EventSource expuesto como proveedor
"Sample.EventCounter.Minimal" con nombre. Este origen contiene un EventCounter que representa el tiempo de
procesamiento de la solicitud. Un contador de este tipo tiene un nombre (es decir, su identificador único en el
origen) y un nombre para mostrar, ambos usados por herramientas de escucha como dotnet-counter.

using System.Diagnostics.Tracing;

[EventSource(Name = "Sample.EventCounter.Minimal")]
public sealed class MinimalEventCounterSource : EventSource
{
public static readonly MinimalEventCounterSource Log = new MinimalEventCounterSource();

private EventCounter _requestCounter;

private MinimalEventCounterSource() =>

_requestCounter = new EventCounter("request-time", this)
{
DisplayName = "Request Processing Time",
DisplayUnits = "ms"
};

public void Request(string url, float elapsedMilliseconds)

{
WriteEvent(1, url, elapsedMilliseconds);
_requestCounter?.WriteMetric(elapsedMilliseconds);
}

protected override void Dispose(bool disposing)

{
_requestCounter?.Dispose();
_requestCounter = null;

base.Dispose(disposing);
}
}

Use dotnet-counters ps para mostrar una lista de los procesos de .NET que se pueden supervisar:

dotnet-counters ps
1398652 dotnet C:\Program Files\dotnet\dotnet.exe
1399072 dotnet C:\Program Files\dotnet\dotnet.exe
1399112 dotnet C:\Program Files\dotnet\dotnet.exe
1401880 dotnet C:\Program Files\dotnet\dotnet.exe
1400180 sample-counters C:\sample-counters\bin\Debug\netcoreapp3.1\sample-counters.exe

Pase el nombre EventSource a la opción --counters para empezar a supervisar el contador:

dotnet-counters monitor --process-id 1400180 --counters Sample.EventCounter.Minimal

En el siguiente ejemplo se muestra la salida de la supervisión:

 Press p to pause, r to resume, q to quit.
Status: Running

[Samples-EventCounterDemos-Minimal]
Request Processing Time (ms) 0.445

Presione q para detener el comando de supervisión.

Contadores condicionales
Al implementar un EventSource, se puede crear de forma condicional una instancia de los contadores contenedores
al llamar al método EventSource.OnEventCommand con un valor Command de EventCommand.Enable . Para crear
una instancia de un contador de forma segura solo si es null , use el operador de asignación de uso combinado de
NULL. Además, los métodos personalizados pueden evaluar el método IsEnabled para determinar si el origen del
evento actual está habilitado o no.

using System.Diagnostics.Tracing;

[EventSource(Name = "Sample.EventCounter.Conditional")]
public sealed class ConditionalEventCounterSource : EventSource
{
public static readonly ConditionalEventCounterSource Log = new ConditionalEventCounterSource();

private EventCounter _requestCounter;

private ConditionalEventCounterSource() { }

protected override void OnEventCommand(EventCommandEventArgs args)

{
if (args.Command == EventCommand.Enable)
{
_requestCounter ??= new EventCounter("request-time", this)
{
DisplayName = "Request Processing Time",
DisplayUnits = "ms"
};
}
}

public void Request(string url, float elapsedMilliseconds)

{
if (IsEnabled())
{
_requestCounter?.WriteMetric(elapsedMilliseconds);
}
}

protected override void Dispose(bool disposing)

{
_requestCounter?.Dispose();
_requestCounter = null;

base.Dispose(disposing);
}
}

TIP
Los contadores condicionales son contadores de los que se crean instancias de forma condicional, una microoptimización. El
entorno de ejecución adopta este patrón para los escenarios en los que normalmente no se usan contadores, para ahorrar
una fracción de un milisegundo.
Contadores de ejemplo del entorno de ejecución de .NET Core
Hay muchas implementaciones de ejemplo excelentes del entorno de ejecución de .NET Core. Esta es la
implementación del entorno de ejecución del contador que realiza el seguimiento del tamaño del espacio de
trabajo de la aplicación.

var workingSetCounter = new PollingCounter(

"working-set",
this,
() => (double)(Environment.WorkingSet / 1_000_000))
{
DisplayName = "Working Set",
DisplayUnits = "MB"
};

PollingCounter comunica la cantidad actual de memoria física asignada al proceso (espacio de trabajo) de la
aplicación, ya que captura una métrica en un momento dado. La devolución de llamada del sondeo de un valor es
la expresión lambda proporcionada, que es simplemente una llamada a la API System.Environment.WorkingSet.
DisplayName y DisplayUnits son propiedades opcionales que se pueden establecer para ayudar al lado del
consumidor del contador a mostrar el valor con más claridad. Por ejemplo, dotnet-counters usa estas propiedades
para mostrar la versión más descriptiva de los nombres de contador.

IMPORTANT
Las propiedades DisplayName no están traducidas.

En el caso de PollingCounter e IncrementingPollingCounter, no es necesario hacer nada más. Ambos sondean los
valores por sí mismos en un intervalo solicitado por el consumidor.
Este es un ejemplo de un contador de entorno de ejecución implementado mediante IncrementingPollingCounter.

var monitorContentionCounter = new IncrementingPollingCounter(

"monitor-lock-contention-count",
this,
() => Monitor.LockContentionCount
)
{
DisplayName = "Monitor Lock Contention Count",
DisplayRateTimeScale = TimeSpan.FromSeconds(1)
};

IncrementingPollingCounter usa la API Monitor.LockContentionCount para comunicar el incremento del recuento

total de contenciones de bloqueo. La propiedad DisplayRateTimeScale es opcional pero, cuando se usa, puede
proporcionar una sugerencia sobre el intervalo de tiempo en el que se muestra mejor el contador. Por ejemplo, el
recuento de contenciones de bloqueo se muestra mejor como recuento por segundo, por lo que
DisplayRateTimeScale se establece en un segundo. La tasa de presentación se puede ajustar a diferentes tipos de
contadores de tasa.

NOTE
dotnet-counters no usa DisplayRateTimeScale, y no es necesario que las escuchas de eventos lo usen.

Hay más implementaciones de contador que se pueden usar como referencia en el repositorio del entorno de
ejecución de .NET.
Simultaneidad
TIP
La API de EventCounters no garantiza la seguridad para subprocesos. Cuando varios subprocesos llaman a los delegados
pasados a instancias PollingCounter o IncrementingPollingCounter, es responsabilidad suya garantizar la seguridad para
subprocesos de los delegados.

Por ejemplo, considere el siguiente EventSource para realizar un seguimiento de las solicitudes.

using System;
using System.Diagnostics.Tracing;

public class RequestEventSource : EventSource

{
public static readonly RequestEventSource Log = new RequestEventSource();

private IncrementingPollingCounter _requestRateCounter;

private long _requestCount = 0;

private RequestEventSource() =>

_requestRateCounter = new IncrementingPollingCounter("request-rate", this, () => _requestCount)
{
DisplayName = "Request Rate",
DisplayRateTimeScale = TimeSpan.FromSeconds(1)
};

public void AddRequest() => ++ _requestCount;

protected override void Dispose(bool disposing)

{
_requestRateCounter?.Dispose();
_requestRateCounter = null;

base.Dispose(disposing);
}
}

Se puede llamar al método AddRequest() desde un controlador de solicitudes y RequestRateCounter sondea el

valor en el intervalo especificado por el consumidor del contador. Pero varios subprocesos pueden llamar al
método AddRequest() a la vez, con lo que se coloca una condición de carrera sobre _requestCount . Una manera
alternativa segura para subprocesos de incrementar _requestCount es usar Interlocked.Increment.

public void AddRequest() => Interlocked.Increment(ref _requestCount);

Para evitar lecturas rasgadas (en arquitecturas de 32 bits) del campo _requestCount de tipo long , use
Interlocked.Read.

_requestRateCounter = new IncrementingPollingCounter("request-rate", this, () => Interlocked.Read(ref

_requestCount))
{
DisplayName = "Request Rate",
DisplayRateTimeScale = TimeSpan.FromSeconds(1)
};

Uso de EventCounters
Hay dos formas principales de usar EventCounters, en proceso o fuera de proceso. El uso de EventCounters se
puede clasificar en tres capas de distintas tecnologías de uso.
Transporte de eventos en una secuencia sin formato a través de ETW o EventPipe:
Las API de ETW están incluidas en el sistema operativo Windows y se puede acceder a EventPipe como
una API de .NET o el protocolo IPC de diagnóstico.
Descodificación del flujo de eventos binario en eventos:
La biblioteca TraceEvent controla los formatos de flujo de ETW y EventPipe.
Herramientas de línea de comandos y GUI:
Herramientas como PerfView (ETW o EventPipe), dotnet-counters (solo EventPipe) y dotnet-monitor (solo
EventPipe).
Uso fuera de proceso
El uso de EventCounters fuera de proceso es un enfoque muy común. Puede usar dotnet-counters para
consumirlos a modo multiplataforma a través de un EventPipe. La herramienta dotnet-counters es una
herramienta global de CLI de dotnet multiplataforma que se puede usar para supervisar los valores de los
contadores. Para obtener información sobre cómo usar dotnet-counters para supervisar los contadores, vea
dotnet-counters o trabaje con el tutorial Medición del rendimiento mediante EventCounters.
dotnet-trace
La herramienta dotnet-trace se puede usar para consumir los datos del contador a través de EventPipe. Este es un
ejemplo de uso de dotnet-trace para recopilar datos del contador.

dotnet-trace collect --process-id <pid> Sample.EventCounter.Minimal:0:0:EventCounterIntervalSec=1

Para obtener más información sobre cómo recopilar valores de un contador a lo largo del tiempo, vea la
documentación de dotnet-trace.
Azure Application Insights
Azure Monitor puede usar EventCounters, en concreto Azure Application Insights. Los contadores se pueden
agregar y quitar; además, el usuario puede especificar contadores personalizados o contadores conocidos. Para
obtener más información, vea Personalización de los contadores que se van a recopilar.
dotnet-monitor
dotnet-monitor es una herramienta experimental que facilita el acceso a la información de diagnóstico de un
proceso de .NET. Esta herramienta sirve como superconjunto de todas las herramientas de diagnóstico. Además de
ofrecer seguimientos, permite supervisar métricas, así como recopilar volcados de memoria y de memoria GC. Se
distribuye tanto como herramienta de la CLI como imagen de Docker. Expone una API de REST, y la recopilación de
artefactos de diagnóstico se produce a través de llamadas REST.
Para obtener más información, vea Presentación de dotnet-monitor, una herramienta experimental.
Uso en proceso
Puede usar los valores de un contador por medio de la API EventListener. EventListener es una forma en proceso
de usar los eventos escritos por todas las instancias de un EventSource en la aplicación. Para obtener más
información sobre cómo usar la API EventListener , vea EventListener.
En primer lugar, es necesario habilitar el EventSource que genera el valor del contador. Invalide el método
EventListener.OnEventSourceCreated para obtener una notificación cuando se cree un EventSource y, si es el
EventSource correcto con los EventCounters, puede llamar a EventListener.EnableEvents en él. Esta es una
invalidación de ejemplo:
 protected override void OnEventSourceCreated(EventSource source)
{
if (!source.Name.Equals("System.Runtime"))
{
return;
}

EnableEvents(source, EventLevel.Verbose, EventKeywords.All, new Dictionary<string, string>()

{
["EventCounterIntervalSec"] = _intervalSec.ToString()
});
}

Código de ejemplo
Esta es una clase EventListener de ejemplo que imprime todos los nombres y valores de contador del EventSource
del entorno de ejecución de .NET, para publicar sus contadores internos ( System.Runtime ) en algún intervalo.
 using System;
using System.Collections.Generic;
using System.Diagnostics.Tracing;

public class SimpleEventListener : EventListener

{
private readonly int _intervalSec;

public int EventCount { get; private set; }

public SimpleEventListener(int intervalSec = 1) =>

_intervalSec = intervalSec <= 0
? throw new ArgumentException("Interval must be at least 1 second.", nameof(intervalSec))
: intervalSec;

protected override void OnEventSourceCreated(EventSource source)

{
if (!source.Name.Equals("System.Runtime"))
{
return;
}

EnableEvents(source, EventLevel.Verbose, EventKeywords.All, new Dictionary<string, string>()

{
["EventCounterIntervalSec"] = _intervalSec.ToString()
});
}

protected override void OnEventWritten(EventWrittenEventArgs eventData)

{
if (!eventData.EventName.Equals("EventCounters"))
{
return;
}

for (int i = 0; i < eventData.Payload.Count; ++ i)

{
if (eventData.Payload[i] is IDictionary<string, object> eventPayload)
{
var (counterName, counterValue) = GetRelevantMetric(eventPayload);
Console.WriteLine($"{counterName} : {counterValue}");
}
}
}

private static (string counterName, string counterValue) GetRelevantMetric(

IDictionary<string, object> eventPayload)
{
var counterName = "";
var counterValue = "";

if (eventPayload.TryGetValue("DisplayName", out object displayValue))

{
counterName = displayValue.ToString();
}
if (eventPayload.TryGetValue("Mean", out object value) ||
eventPayload.TryGetValue("Increment", out value))
{
counterValue = value.ToString();
}

return (counterName, counterValue);

}
}

Como se ha mostrado anteriormente, debe asegurarse de que el argumento "EventCounterIntervalSec" esté

establecido en el argumento filterPayload al llamar a EnableEvents. De lo contrario, los contadores no pueden
vaciar valores, ya que no saben en qué intervalo se debe hacer.

Consulte también
dotnet-counters
dotnet-trace
EventCounter
EventListener
EventSource
 EventPipe
18/12/2020 • 9 minutes to read • Edit Online

EventPipe es un componente en tiempo de ejecución similar a ETW o LTTng que se puede usar para recopilar
datos de seguimiento. El objetivo de EventPipe es permitir a los desarrolladores de .NET realizar un seguimiento
sencillo de sus aplicaciones .NET sin tener que depender de componentes nativos del sistema operativo
específicos de la plataforma como ETW o LTTng.
EventPipe es el mecanismo subyacente de muchas de las herramientas de diagnóstico y se puede usar para
consumir eventos emitidos por el entorno de ejecución, así como eventos personalizados escritos con
EventSource.
Este artículo es una introducción general a EventPipe que describe cuándo y cómo usar EventPipe y cómo
configurarlo para que se adapte mejor a sus necesidades.

Aspectos básicos de EventPipe

EventPipe agrega eventos emitidos por componentes en tiempo de ejecución (por ejemplo, el compilador Just-in-
Time o el recolector de elementos no utilizados) y eventos escritos desde instancias de EventSource en las
bibliotecas y el código de usuario.
Luego los eventos se serializan y pueden escribirse directamente en un archivo o consumirse por medio de un
puerto de diagnóstico desde fuera de proceso. En Windows, los puertos de diagnóstico se implementan como
elementos NamedPipe . En plataformas que no son de Windows, como Linux o macOS, se implementan mediante
sockets de dominio Unix. Para obtener más información sobre el puerto de diagnóstico y cómo interactuar con él
mediante su protocolo de comunicación entre procesos personalizado, vea la documentación del protocolo IPC de
diagnóstico.
Luego EventPipe escribe los eventos serializados en el formato de archivo .nettrace , ya sea como una secuencia
mediante puertos de diagnóstico o directamente en un archivo. Para obtener más información sobre el formato
de serialización de EventPipe, vea la documentación de formato de EventPipe.

EventPipe frente a ETW/LTTng

EventPipe forma parte del entorno de ejecución .NET (CoreCLR) y está diseñado para funcionar de la misma
manera en todas las plataformas compatibles con .NET Core. Esto permite que herramientas de seguimiento
basadas en EventPipe, como dotnet-counters , dotnet-gcdump y dotnet-trace , funcionen sin problemas entre
plataformas.
Pero, dado que EventPipe es un componente integrado en tiempo de ejecución, su ámbito se limita al código
administrado y al propio entorno de ejecución. EventPipe no se puede usar para realizar el seguimiento de
algunos eventos de nivel inferior, como resolver la pila de código nativo u obtener distintos eventos de kernel. Si
usa interoperabilidad de C/C++ en la aplicación, quiere realizar un seguimiento del propio entorno de ejecución
(que está escrito en C++) o quiere un diagnóstico más profundo sobre el comportamiento de la aplicación que
requiera eventos de kernel (es decir, eventos de cambio de contexto de subprocesos nativos), debe usar ETW o
perf/LTTng.
Otra diferencia importante entre EventPipe y ETW/LTTng es el requisito de privilegios de administrador o raíz. Para
realizar el seguimiento de una aplicación mediante ETW o LTTng, debe ser administrador o raíz. Con EventPipe
puede realizar un seguimiento de las aplicaciones siempre que el seguimiento (por ejemplo, dotnet-trace ) se
ejecute como el mismo usuario que el que ha iniciado la aplicación.
En la tabla siguiente se presenta un resumen de las diferencias entre EventPipe y ETW/LTTng.

C A RA C T ERÍST IC A EVEN T P IP E ET W LT T N G

Multiplataforma Sí No (solo en Windows) No (solo en distribuciones

Linux compatibles)

Requiere privilegios de No Sí Sí
administrador o raíz

Puede obtener eventos de No Sí Sí

SO o kernel

Puede resolver pilas de No Sí Sí

llamadas nativas

Uso de EventPipe para el seguimiento de la aplicación .NET

Puede usar EventPipe para realizar un seguimiento de la aplicación .NET de muchas maneras:
Use alguna de las herramientas de diagnóstico que se basan en EventPipe.
Use la biblioteca Microsoft.Diagnostics.NETCore.Client para escribir su propia herramienta a fin de
configurar e iniciar las sesiones de EventPipe por sí mismo.
Use variables de entorno para iniciar EventPipe.
Después de haber creado un archivo nettrace que contenga los eventos de EventPipe, puede verlo en PerfView
o Visual Studio. En las plataformas que no son de Windows, puede convertir el archivo nettrace a un formato de
seguimiento de speedscope o Chromium mediante el comando dotnet-trace convert y verlo con speedscope o
Chrome DevTools.
También puede analizar los seguimientos de EventPipe mediante programación con TraceEvent.
Herramientas que usan EventPipe
Esta es la forma más sencilla de usar EventPipe para realizar un seguimiento de la aplicación. Para obtener más
información sobre cómo usar cada una de estas herramientas, vea la documentación de cada una de ellas.
dotnet-counters permite supervisar y recopilar diversas métricas emitidas por el entorno de ejecución .NET
y las bibliotecas principales, así como métricas personalizadas que se pueden escribir.
dotnet-gcdump permite recopilar volcados de memoria del montón de GC de procesos en vivo para
analizar el montón administrado de una aplicación.
dotnet-trace permite recopilar seguimientos de aplicaciones para analizar el rendimiento.

Seguimiento mediante variables de entorno

El mecanismo preferido para usar EventPipe es dotnet-trace o la biblioteca
Microsoft.Diagnostics.NETCore.Client ,

pero puede usar las siguientes variables de entorno para configurar una sesión de EventPipe en una aplicación y
hacer que escriba el seguimiento directamente en un archivo. Para detener el seguimiento, salga de la aplicación.
COMPlus_EnableEventPipe : establezca en 1 para iniciar una sesión de EventPipe que escriba directamente
en un archivo. El valor predeterminado es 0 .
COMPlus_EventPipeOutputPath : ruta de acceso al archivo de seguimiento de EventPipe de salida cuando está
configurado para ejecutarse mediante COMPlus_EnableEventPipe . El valor predeterminado es
trace.nettrace , que se crea en el mismo directorio desde el que se ejecuta la aplicación.

COMPlus_CircularBufferMB: tamaño del búfer interno usado por EventPipe cuando se configura para
ejecutarse mediante COMPlus_EnableEventPipe .
COMPlus_EventPipeConfig: establece la configuración de sesión de EventPipe al iniciar una sesión de
EventPipe con COMPlus_EnableEventPipe .
La sintaxis es la siguiente:
<provider>:<keyword>:<level>

También puede especificar varios proveedores si los concatena con una coma:
<provider1>:<keyword1>:<level1>,<provider2>:<keyword2>:<level2>

Si no se establece esta variable de entorno sino que EventPipe se habilita por medio de
COMPlus_EnableEventPipe , comienza el seguimiento mediante la habilitación de los siguientes proveedores
con las siguientes palabras clave y niveles:
Microsoft-Windows-DotNETRuntime:4c14fccbd:5
Microsoft-Windows-DotNETRuntimePrivate:4002000b:5
Microsoft-DotNETCore-SampleProfiler:0:5
 Registro y seguimiento de .NET Core
18/12/2020 • 7 minutes to read • Edit Online

El registro y el seguimiento son en realidad dos nombres para la misma técnica. Esta sencilla técnica se ha usado
desde el inicio de la era de la informática. Simplemente implica instrumentar una aplicación para escribir la
salida que se va a consumir más adelante.

Motivos para usar el registro y seguimiento

Esta técnica sencilla es sorprendentemente eficaz. Se puede usar en situaciones en las que se produzca un error
en un depurador:
Las incidencias que se producen durante largos períodos de tiempo pueden ser difíciles de depurar con un
depurador tradicional. Los registros permiten una revisión detallada de evaluación que abarca períodos
largos de tiempo. En cambio, los depuradores están restringidos a análisis en tiempo real.
Las aplicaciones multiproceso y las aplicaciones distribuidas a menudo son difíciles de depurar. Adjuntar un
depurador tiende a modificar los comportamientos. Los registros detallados se pueden analizar, según sea
necesario, para comprender sistemas complejos.
Las incidencias en las aplicaciones distribuidas pueden surgir de una interacción compleja entre muchos
componentes y puede que no sea razonable conectar un depurador en todas las partes del sistema.
Muchos servicios no deben estar detenidos. Al adjuntar un depurador a menudo se producen errores de
tiempo de expiración.
Las incidencias no siempre están previstas. El registro y seguimiento están diseñados para una baja
sobrecarga, de modo que los programas siempre pueden grabarse en caso de que se produzca una
incidencia.

API de .NET Core

API de estilo de impresión
Cada una de las clases System.Console, System.Diagnostics.Trace y System.Diagnostics.Debug proporcionan API
de estilo de impresión parecidas para el registro.
La elección de la API de estilo de impresión que se va a usar depende de usted. Las diferencias clave son:
System.Console
Siempre está habilitada y siempre escribe en la consola.
Resulta útil para la información que es posible que el cliente necesite ver en la versión.
Dado que es el enfoque más sencillo, a menudo se usa para la depuración temporal ad hoc. Este
código de depuración a veces no se registra nunca en el control de código fuente.
System.Diagnostics.Trace
Solo se habilita cuando se define TRACE .
Escribe en el elemento Listeners adjuntado, de forma predeterminada, DefaultTraceListener.
Use esta API cuando cree registros que se vayan a habilitar en la mayoría de compilaciones.
System.Diagnostics.Debug
Solo se habilita cuando se define DEBUG .
Escribe en un depurador adjuntado.
En *nix , escribe en stderr si se establece COMPlus_DebugWriteToStdErr .
Use esta API cuando cree registros que se vayan a habilitar solo en las compilaciones de depuración.
Eventos de registro
Las siguientes API están más orientadas a eventos. En lugar de registrar cadenas sencillas, registran objetos de
evento.
System.Diagnostics.Tracing.EventSource
EventSource es la API de seguimiento de .NET Core de raíz principal.
Disponible en todas las versiones .NET Standard.
Solo permite el seguimiento de objetos serializables.
Se puede consumir durante el proceso por medio de cualquier instancia de EventListener que se haya
configurado para consumir el objeto EventSource.
Se puede consumir fuera de proceso mediante lo siguiente:
EventPipe de .NET Core en todas las plataformas
Seguimiento de eventos para Windows (ETW)
Marco de seguimiento de LTTng para Linux
Tutorial: Recopilación de un seguimiento de LTTng con PerfCollect.
System.Diagnostics.DiagnosticSource
Se incluye en .NET Core y como un paquete NuGet para .NET Framework.
Permite el seguimiento en curso de objetos no serializables.
Incluye un puente para permitir que los campos seleccionados de objetos registrados se escriban en
un elemento EventSource.
System.Diagnostics.Activity
Proporciona una manera definitiva de identificar los mensajes de registro resultantes de una actividad
o transacción específica. Este objeto se puede utilizar para correlacionar los registros entre distintos
servicios.
System.Diagnostics.EventLog
Solo Windows.
Escribe mensajes en el registro de eventos de Windows.
Los administradores del sistema esperan que aparezcan mensajes de error grave de aplicación en el
registro de eventos de Windows.

Plataformas de registro y de ILogger

Es posible que las API de bajo nivel no sean la opción adecuada para sus necesidades de registro. Puede que
quiera considerar la posibilidad de usar una plataforma de registro.
La interfaz de ILogger se ha utilizado para crear una interfaz de registro común en la que se pueden insertar los
registradores mediante la inserción de dependencias.
Por ejemplo, para que pueda elegir la mejor opción para la aplicación, .NET ofrece compatibilidad con una
selección de marcos integrados y de terceros:
Proveedores de registro integrados de .NET
Proveedores de registro de terceros de .NET

Referencias relacionadas de registro

Compilación condicional con Trace y Debug
Adición de instrucciones de seguimiento al código de la aplicación
El registro de .NET proporciona información general sobre las técnicas de registro que admite.
 La interpolación de cadenas de C# puede simplificar la escritura de código de registro.
Lista de eventos del proveedor en tiempo de ejecución
La propiedad Exception.Message es útil para las excepciones de registro.
La clase System.Diagnostics.StackTrace puede ser útil para proporcionar información de pila en los
registros.

Consideraciones sobre el rendimiento

El formato de cadena puede tomar un tiempo de procesamiento de la CPU considerable.
En las aplicaciones críticas de rendimiento, se recomienda lo siguiente:
Evitar muchos registros cuando no haya nadie escuchando. Evitar la construcción de mensajes de registro
costosos comprobando en primer lugar si el registro está habilitado.
Registrar únicamente lo que sea útil.
Aplazar el formato sofisticado a la fase de análisis.
 Eventos de tiempo de ejecución de .NET
18/12/2020 • 2 minutes to read • Edit Online

El entorno de tiempo de ejecución de .NET (CoreCLR) emite varios eventos que se pueden usar para diagnosticar
problemas con la aplicación .NET que se pueden consumir a través de varios mecanismos como ETW , LTTng y
EventPipe .

Este documento sirve como referencia en los eventos desencadenados por el tiempo de ejecución de .NET Core.
Para eventos en tiempo de ejecución en .NET Framework, vea eventos ETW de CLR.

En esta sección
Eventos de contención
Estos eventos recopilan información acerca de las contenciones de bloqueo de monitor.
Eventos de recolección de elementos no utilizados
Estos eventos recopilan información sobre la recolección de elementos no utilizados. Ayudan en el diagnóstico y la
depuración, incluida la determinación de cuántas veces se realizó la recolección de elementos no utilizados, cuánta
memoria se liberó durante la recolección de elementos no utilizados, etc.
Eventos de excepción
Estos eventos en tiempo de ejecución capturan información sobre las excepciones que se producen.
Eventos de interoperabilidad
Estos eventos en tiempo de ejecución capturan información sobre la generación de código auxiliar del lenguaje
intermedio común (CIL).
Eventos de cargador y enlazador
Estos eventos recopilan información relacionada con la carga y descarga de ensamblados y módulos.
Eventos de método
Estos eventos recopilan información que es específica de los métodos. La carga de estos eventos es necesaria para
la resolución de símbolos. Además, estos eventos proporcionan información útil como el número de veces que se
llama a un método.
Eventos de subproceso
Estos eventos recopilan información sobre los subprocesos de E/S y de trabajo.
Eventos de tipo
Estos eventos recopilan información sobre el sistema de tipos.
 Eventos de contención en tiempo de ejecución de
.NET
18/12/2020 • 2 minutes to read • Edit Online

Estos eventos en tiempo de ejecución capturan información sobre las contenciones de bloqueo de monitor como
con Monitor.Enter o la palabra clave Lock de C#. Para obtener más información sobre cómo usar estos eventos
con fines de diagnóstico, consulte registro y seguimiento de aplicaciones .net

Evento ContentionStart_V1
Este evento se genera al inicio de una contención de bloqueo de monitor.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ContentionKeyword (0x4000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ContentionStart_V1 81 Se inicia una contención de bloqueo de

monitor.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Flags win:UInt8 0 para administrado; 1 para nativo.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ContentionStop_V1
Este evento se emite al final de una contención de bloqueo de monitor.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ContentionKeyword (0x4000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ContentionStop_V1 91 Finaliza una contención de bloqueo de

monitor.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Flags win:UInt8 0 para administrado; 1 para nativo.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

DurationNs win:Double Duración de la contención en

nanosegundos.
 Eventos de excepción en tiempo de ejecución de
.NET
18/12/2020 • 6 minutes to read • Edit Online

Estos eventos en tiempo de ejecución capturan información sobre las excepciones que se producen. Para obtener
más información sobre cómo usar estos eventos con fines de diagnóstico, consulte registro y seguimiento de
aplicaciones .net

Evento ExceptionThrown_V1
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Error (1)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionThrown_V1 80 Se genera una excepción administrada.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ExceptionType win:UnicodeString Tipo de la excepción; por ejemplo,

System.NullReferenceException .

ExceptionMessage win:UnicodeString Mensaje actual de la excepción.

EIPCodeThrow win:Pointer Puntero de instrucción donde se ha

producido la excepción.

ExceptionHR win:UInt32 Excepción HRESULT.

ExceptionFlags win:UInt16 0x01 : HasInnerException.

0x02 : IsNestedException.

0x04 : IsRethrownException.

0x08 : IsCorruptedStateException
(indica que el estado del proceso está
dañado; consulte control de
excepciones de estado dañadas).

0x10 : IsCLSCompliant (una excepción

que se deriva de Exception es conforme
a CLS; en caso contrario, no es
conforme a CLS).

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.
Evento ExceptionCatchStart
Este evento se genera cuando comienza un controlador Catch administrado.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionCatchStart 250 El tiempo de ejecución controla una

excepción administrada.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

EIPCodeThrow win:Pointer Puntero de instrucción donde se ha

producido la excepción.

MethodID win:Pointer Puntero al descriptor de método en el

método en el que se produjo la
excepción.

MethodName win:UnicodeString Nombre del método en el que se

produjo la excepción.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ExceptionCatchStop
Este evento se genera cuando finaliza un controlador Catch administrado.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionCatchStop 251 Se realiza un controlador catch de

excepción administrada.

Evento ExceptionFinallyStart
Este evento se genera cuando comienza un controlador final de excepción administrada.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

 EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionFinallyStart 252 El tiempo de ejecución controla una

excepción administrada.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

EIPCodeThrow win:Pointer Puntero de instrucción donde se ha

producido la excepción.

MethodID win:Pointer Puntero al descriptor de método en el

método en el que se produjo la
excepción.

MethodName win:UnicodeString Nombre del método en el que se

produjo la excepción.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ExceptionFinallyStop
Este evento se genera cuando finaliza un controlador Catch administrado.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionFinallyStop 253 Se realiza un controlador Finally de

excepción administrada.

Evento ExceptionFilterStart
Este evento se genera cuando comienza un filtrado de excepciones administrado.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionFilterStart 254 Comienza un filtrado de excepciones

administradas.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

EIPCodeThrow win:Pointer Puntero de instrucción donde se ha

producido la excepción.

MethodID win:Pointer Puntero al descriptor de método en el

método en el que se produjo la
excepción.

MethodName win:UnicodeString Nombre del método en el que se

produjo la excepción.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ExceptionFilterStop
Este evento se genera cuando finaliza un filtrado de excepciones administrado.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionFilteringStart 255 Finaliza un filtrado de excepción

administrado.

Evento ExceptionThrownStop
Este evento se genera cuando el motor en tiempo de ejecución realiza el control de una excepción administrada
que se produjo.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ExceptionKeyword (0x8000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ExceptionThrownStop 256 Finaliza un filtrado de excepción

administrado.
 Eventos de recolección de elementos no utilizados de
.NET Runtime
18/12/2020 • 23 minutes to read • Edit Online

Estos eventos recopilan información sobre la recolección de elementos no utilizados. Ayudan en el diagnóstico y la
depuración, incluida la determinación de cuántas veces se realizó la recolección de elementos no utilizados, cuánta
memoria se liberó durante la recolección de elementos no utilizados, etc. Para obtener más información sobre
cómo usar estos eventos con fines de diagnóstico, consulte registro y seguimiento de aplicaciones .net

Evento GCStart_V2
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCStart_V1 1 Se ha iniciado una recolección de

elementos no utilizados.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt32 Recolección de elementos no utilizados

número n.

Depth win:UInt32 Generación que se está recopilando.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Reason win:UInt32 ¿Por qué se desencadenó la recolección

de elementos no utilizados:

0x0 -Asignación del montón de

objetos pequeños.

0x1 Inducida.

0x2 -Memoria insuficiente.

0x3 Vacía.

0x4 -Asignación del montón de

objetos grandes.

0x5-Espacio insuficiente (para el

montón de objetos pequeños).

0x6 -Espacio insuficiente (para el

montón de objetos grandes).

0x7 -Inducido pero no forzado como

bloqueo.

Type win:UInt32 0x0 -La recolección de elementos no

utilizados bloqueada fuera de la
recolección de elementos no utilizados.

0x1 -Recolección de elementos no

utilizados en segundo plano.

0x2 -La recolección de elementos no

utilizados bloqueada durante la
recolección de elementos no utilizados
en segundo plano

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento GCEnd_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCEnd_V1 2 La recolección de elementos no

utilizados ha finalizado.

En la siguiente tabla, se muestran los datos del evento:

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt32 Recolección de elementos no utilizados

número n.

Depth win:UInt32 Generación que se recopiló.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento GCHeapStats_V2
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

GCHeapStats_V2 4 Muestra las estadísticas del montón al

final de cada recolección de elementos
no utilizados.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

GenerationSize0 win:UInt64 Tamaño, en bytes, de la memoria de la

generación 0.

TotalPromotedSize0 win:UInt64 Número de bytes que se promueven de

generación 0 a generación 1.

GenerationSize1 win:UInt64 Tamaño, en bytes, de la memoria de la

generación 1.

TotalPromotedSize1 win:UInt64 Número de bytes que se promueven de

generación 1 a generación 2.

GenerationSize2 win:UInt64 Tamaño, en bytes, de la memoria de la

generación 2.

TotalPromotedSize2 win:UInt64 Número de bytes que sobrevivieron en

la generación 2 después de la última
recolección.

GenerationSize3 win:UInt64 Tamaño, en bytes, del montón de

objetos grandes.

TotalPromotedSize3 win:UInt64 Número de bytes que sobrevivieron en

el montón de objetos grandes después
de la última recolección.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

FinalizationPromotedSize win:UInt64 Tamaño total, en bytes, de los objetos

que están listos para la finalización.

FinalizationPromotedCount win:UInt64 Número de objetos que están listos

para la finalización.

PinnedObjectCount win:UInt32 Número de objetos anclados

(inamovibles).

SinkBlockCount win:UInt32 Número de bloques de sincronización

en uso.

GCHandleCount win:UInt32 Número de controles de recolección de

elementos no utilizados en uso.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

GenerationSize4 win:UInt64 Tamaño, en bytes, del montón de

objetos anclados.

TotalPromotedSize4 win:UInt64 Número de bytes que sobrevivieron en

el montón de objetos anclados después
de la última recolección.

Evento GCCreateSegment_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCCreateSegment_V1 5 Se ha creado un nuevo segmento de

recopilación de elementos no utilizados.
Además, si se habilita el seguimiento en
un proceso que ya se está ejecutando,
se genera este evento para cada
segmento existente.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Address win:UInt64 Dirección del segmento.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Size win:UInt64 Tamaño del segmento.

Type win:UInt32 0x0: montón de objetos pequeños.

0x1: montón de objetos grandes.

0x2: montón de solo lectura.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Tenga en cuenta que el tamaño de los segmentos asignados por el recolector de elementos no utilizados es
específico de la implementación y está sujeto a cambios en cualquier momento, incluso en las actualizaciones
periódicas. La aplicación nunca debe realizar suposiciones sobre el tamaño de un sector determinado ni depender
de él, y tampoco debe intentar configurar la cantidad de memoria disponible para las asignaciones de segmentos.

Evento GCFreeSegment_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCFreeSegment_V1 6 Se ha liberado un segmento de

recolección de elementos no utilizados.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Address win:UInt64 Dirección del segmento.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento GCRestartEEBegin_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

 EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCRestartEEBegin_V1 7 Ha comenzado la reanudación de la

suspensión de Common Language
Runtime.

Este evento no tiene datos de evento.

Evento GCRestartEEEnd_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCRestartEEEnd_V1 3 Ha finalizado la reanudación de la

suspensión de Common Language
Runtime.

Este evento no tiene datos de evento.

Evento GCSuspendEEEnd_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCSuspendEEEnd_V1 8 Final de la suspensión del motor de

ejecución de la recolección de
elementos no utilizados.

Este evento no tiene datos de evento.

Evento GCSuspendEEBegin_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

 EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCSuspendEEBegin_V1 8 Inicio de la suspensión del motor de

ejecución de la recolección de
elementos no utilizados.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt32 Recolección de elementos no utilizados

número n.

Reason win:UInt32 Motivo de la suspensión de EE.

0x0 : Suspender para otros

0x1 : Suspender para GC.

0x2: Suspender para el cierre de

AppDomain.

0x3 : Suspender para el paso del

código.

0x4 : Suspender para apagar.

0x5 : Suspender para el depurador.

0x6 : Suspend para la preparación de

GC.

0x7 : Suspender el barrido del

depurador

Evento GCAllocationTick_V3
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Verbose (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCAllocationTick_V3 10 Cada vez se asignan aproximadamente

100 KB.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AllocationAmount win:UInt32 Tamaño de la asignación, en bytes. Este

valor es preciso para las asignaciones
que son menores que la longitud de
ULONG (4.294.967.295 bytes). Si la
asignación es mayor, este campo
contiene un valor truncado. Use
AllocationAmount64 para
asignaciones muy grandes.

AllocationKind win:UInt32 0x0 -Asignación de objetos pequeños

(la asignación está en un montón de
objetos pequeños).

0x1 -Asignación de objetos grandes

(la asignación está en un montón de
objetos grandes).

AllocationAmount64 win:UInt64 Tamaño de la asignación, en bytes. Este

valor es preciso para asignaciones muy
grandes.

TypeId win:Pointer Dirección de la MethodTable. Cuando

durante este evento se asignaron varios
tipos de objetos, esta es la dirección de
la MethodTable que corresponde al
último objeto asignado (es decir, el
objeto que hizo que se supere el umbral
de 100 KB).

TypeName win:UnicodeString Nombre del tipo que se asignó. Cuando

durante este evento se asignaron varios
tipos de objetos, este es el tipo del
último objeto asignado (es decir, el
objeto que hizo que se supere el umbral
de 100 KB).

HeapIndex win:UInt32 Montón al que se ha asignado el

objeto. Este valor es 0 (cero) cuando se
ejecuta con la recolección de elementos
no utilizados de estación de trabajo.

Address win:Pointer Dirección del último objeto asignado.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento GCCreateConcurrentThread_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCCreateConcurrentThread_V1 11 El subproceso de recolección de

elementos no utilizados simultánea se
creó.

Este evento no tiene datos de evento.

Evento GCTerminateConcurrentThread_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCTerminateConcurrentThread_V1 12 El subproceso de recolección de

elementos no utilizados simultánea
finalizó.

Este evento no tiene datos de evento.

Evento GCFinalizersBegin_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCFinalizersBegin_V1 14 Inicio de los finalizadores en ejecución.

Este evento no tiene datos de evento.

Evento GCFinalizersEnd_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCFinalizersEnd_V1 13 Final de los finalizadores en ejecución.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt32 Número de finalizadores que se ejecutó.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento SetGCHandle
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCHandleKeyword 0X2 Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

SetGCHandle 30 Se ha establecido un identificador de

GC.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

HandleID win:Pointer Dirección del identificador asignado.

ObjectID win:Pointer Dirección del objeto cuyo identificador

se creó.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Kind win:UInt32 El tipo de identificador de GC que se

estableció.

0x0 : WeakShort

0x1 : WeakLong

0x2 : Strong

0x3 : Anclado

0x4 : Variable

0x5 : RefCounted

0x6 : Dependiente

0x7 : AsyncPinned

0x8 : Identificador sizedref

Generation win:UInt32 La generación del objeto cuyo

identificador se creó.

AppDomainID win:UInt64 IDENTIFICADOR de AppDomain.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento DestroyGCHandle
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCHandleKeyword 0X2 Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

DestroyGCHandle 31 Se destruye un identificador de GC.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

HandleID win:Pointer Dirección del identificador destruido.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento PinObjectAtGCTime
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

PinObjectAtGCTime 33 Se ancló un objeto durante un GC.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

HandleID win:Pointer Dirección del identificador.

ObjectID win:Pointer Dirección del objeto anclado.

ObjectSize win:UInt64 Tamaño del objeto anclado.

TypeName win:UnicodeString Nombre del tipo del objeto anclado.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento GCTriggered
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCTriggered 33 Se ha desencadenado un GC.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Reason win:UInt32 Motivo por el que se desencadenó un

GC.

0x0 : AllocSmall

0x1 : Inducido

0x2 : LowMemory

0x3 : Vacío

0x4 : AllocLarge

0x5 : OutOfSpaceSmallObjectHeap

0x6 : OutOfSpaceLargeObjectHeap

0x7 :InducedNoForce

0x8 : Stress

0x9 : InducedLowMemory

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento IncreaseMemoryPressure
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Información (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

IncreaseMemoryPressure 200 Se aumentó la presión de memoria.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento DecreaseMemoryPressure
En la tabla siguiente se muestra la palabra clave y el nivel.
 PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Información (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

DecreaseMemoryPressure 201 Se disminuyó la presión de memoria.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

BytesFreed win:UInt32 Bytes liberados.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento GCMarkWithType
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Información (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCMarkWithType 202 Se ha marcado una raíz de GC durante

la fase de marca de GC.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

HeapNum win:UInt32 El número de montón.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Type win:UInt32 Tipo raíz del GC.

0x0 : Stack

0x1 : Finalizador

0x2 : Handle

0x3 : Anterior

0x4 : Identificador sizedref

0x5 : Desbordamiento

Bytes win:UInt64 Número de bytes marcados como.

Evento GCJoin_V2
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

GCKeyword (0x1) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

GCJoin_V2 203 Un subproceso GC combinado.

En la siguiente tabla, se muestran los datos del evento:

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Heap win:UInt32 El número de montón

JoinTime win:UInt32 Indica si este evento se desencadena al

principio de una combinación o el final
de una combinación (para el inicio de la
combinación 0x0 , para el extremo de
la 0x1 combinación)
N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

JoinType win:UInt32 Tipo de combinación.

0x0 : Última combinación

0x1 : Join

0x2 : Reiniciar

0x3 : Primera combinación inversa

0x4 : Combinación inversa

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.
 Eventos de interoperabilidad de .NET Runtime
18/12/2020 • 2 minutes to read • Edit Online

Estos eventos en tiempo de ejecución capturan información sobre la generación de código auxiliar del lenguaje
intermedio común (CIL). Para obtener más información sobre cómo usar estos eventos con fines de diagnóstico,
consulte registro y seguimiento de aplicaciones .net

Evento ILStubGenerated
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

InteropKeyword (0 x 2000) Informativo (4)

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

ILStubGenerated 88 Se genera un código auxiliar de IL.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleID win:UInt16 Identificador del módulo.

StubMethodID win:UInt64 Identificador del método de código

auxiliar.

StubFlags win:UInt32 Marcas para el código auxiliar:

0x1 -Interoperabilidad inversa.

0x2 -Interoperabilidad COM.

0x4 -Código auxiliar generado por

NGen.exe.

0x8 Delegado.

0x10 -Argumento variable.

0x20 -Destinatario no administrado.

0x40 -Serialización de struct

ManagedInteropMethodToken win:UInt32 Token del método de interoperabilidad

administrado.

ManagedInteropMethodNameSpace win:UnicodeString El espacio de nombres y el tipo de

inclusión del método de
interoperabilidad administrado.

ManagedInteropMethodName win:UnicodeString Nombre del método de

interoperabilidad administrado.
N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ManagedInteropMethodSignature win:UnicodeString Firma del método de interoperabilidad

administrado.

NativeMethodSignature win:UnicodeString Firma del método nativo.

StubMethodSignature win:UnicodeString Firma del método de código auxiliar.

StubMethodILCode win:UnicodeString Código de lenguaje intermedio común

(CIL) del método de código auxiliar.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.
 Cargador de tiempo de ejecución de .NET y eventos
del enlazador
18/12/2020 • 18 minutes to read • Edit Online

Estos eventos recopilan información relacionada con la carga y descarga de ensamblados y módulos. Para obtener
más información sobre cómo usar estos eventos con fines de diagnóstico, consulte registro y seguimiento de
aplicaciones .net

PA L A B RA C L AVE PA RA GEN ERA R EL

EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

DomainModuleLoad_V1 151 Se genera cuando se carga un módulo

para un dominio de aplicación.

Evento ModuleLoad_V2
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ModuleLoad_V2 152 Se genera cuando se carga un módulo

durante la duración de un proceso.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleID win:UInt64 Identificador único para el módulo.

AssemblyID win:UInt64 Identificador del ensamblado en el que

reside este módulo.

ModuleFlags win:UInt32 0x1: módulo neutro de dominio.

0x2: módulo con una imagen nativa.

0x4: módulo dinámico.

0x8: módulo de manifiesto.

Reserved1 win:UInt32 Campo reservado.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleILPath win:UnicodeString Ruta de acceso de la imagen de

lenguaje intermedio común (CIL) para el
módulo, o nombre de módulo dinámico
si es un ensamblado dinámico
(terminado en null).

ModuleNativePath win:UnicodeString Ruta de acceso de la imagen nativa de

módulo, si está presente (terminado en
null).

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

ManagedPdbSignature win:GUID Firma GUID de la base de datos de

programa (PDB) administrada que
coincide con este módulo.

ManagedPdbAge win:UInt32 Número de antigüedad escrito en la

PDB administrada que coincide con este
módulo.

ManagedPdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB administrada que coincide
con este módulo. En algunos casos,
puede tratarse simplemente de un
nombre de archivo.

NativePdbSignature win:GUID Firma GUID del PDB del generador de

imágenes nativas (NGen) que coincide
con este módulo, en su caso.

NativePdbAge win:UInt32 Número de antigüedad escrito en la

PDB de NGen que coincide con este
módulo, en su caso.

NativePdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB de NGen que coincide con
este módulo, en su caso. En algunos
casos, puede tratarse simplemente de
un nombre de archivo.

Evento ModuleUnload_V2
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ModuleUnload_V2 153 Se genera cuando se descarga un

módulo durante la duración de un
proceso.
N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleID win:UInt64 Identificador único para el módulo.

AssemblyID win:UInt64 Identificador del ensamblado en el que

reside este módulo.

ModuleFlags win:UInt32 0x1: módulo neutro de dominio.

0x2: módulo con una imagen nativa.

0x4: módulo dinámico.

0x8: módulo de manifiesto.

Reserved1 win:UInt32 Campo reservado.

ModuleILPath win:UnicodeString Ruta de acceso de la imagen de

lenguaje intermedio común (CIL) para el
módulo, o nombre de módulo dinámico
si es un ensamblado dinámico
(terminado en null).

ModuleNativePath win:UnicodeString Ruta de acceso de la imagen nativa de

módulo, si está presente (terminado en
null).

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

ManagedPdbSignature win:GUID Firma GUID de la base de datos de

programa (PDB) administrada que
coincide con este módulo.

ManagedPdbAge win:UInt32 Número de antigüedad escrito en la

PDB administrada que coincide con este
módulo.

ManagedPdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB administrada que coincide
con este módulo. En algunos casos,
puede tratarse simplemente de un
nombre de archivo.

NativePdbSignature win:GUID Firma GUID del PDB del generador de

imágenes nativas (NGen) que coincide
con este módulo, en su caso.

NativePdbAge win:UInt32 Número de antigüedad escrito en la

PDB de NGen que coincide con este
módulo, en su caso.

NativePdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB de NGen que coincide con
este módulo, en su caso. En algunos
casos, puede tratarse simplemente de
un nombre de archivo.
Evento ModuleDCStart_V2
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ModuleDCStart_V2 153 Enumera los módulos durante una

detención de inicio.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleID win:UInt64 Identificador único para el módulo.

AssemblyID win:UInt64 Identificador del ensamblado en el que

reside este módulo.

ModuleFlags win:UInt32 0x1: módulo neutro de dominio.

0x2: módulo con una imagen nativa.

0x4: módulo dinámico.

0x8: módulo de manifiesto.

Reserved1 win:UInt32 Campo reservado.

ModuleILPath win:UnicodeString Ruta de acceso de la imagen de

lenguaje intermedio común (CIL) para el
módulo, o nombre de módulo dinámico
si es un ensamblado dinámico
(terminado en null).

ModuleNativePath win:UnicodeString Ruta de acceso de la imagen nativa de

módulo, si está presente (terminado en
null).

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

ManagedPdbSignature win:GUID Firma GUID de la base de datos de

programa (PDB) administrada que
coincide con este módulo.

ManagedPdbAge win:UInt32 Número de antigüedad escrito en la

PDB administrada que coincide con este
módulo.

ManagedPdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB administrada que coincide
con este módulo. En algunos casos,
puede tratarse simplemente de un
nombre de archivo.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

NativePdbSignature win:GUID Firma GUID del PDB del generador de

imágenes nativas (NGen) que coincide
con este módulo, en su caso.

NativePdbAge win:UInt32 Número de antigüedad escrito en la

PDB de NGen que coincide con este
módulo, en su caso.

NativePdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB de NGen que coincide con
este módulo, en su caso. En algunos
casos, puede tratarse simplemente de
un nombre de archivo.

Evento ModuleDCEnd_V2
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ModuleDCEnd_V2 154 Enumera los módulos durante una

detención de finalización.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleID win:UInt64 Identificador único para el módulo.

AssemblyID win:UInt64 Identificador del ensamblado en el que

reside este módulo.

ModuleFlags win:UInt32 0x1: módulo neutro de dominio.

0x2: módulo con una imagen nativa.

0x4: módulo dinámico.

0x8: módulo de manifiesto.

Reserved1 win:UInt32 Campo reservado.

ModuleILPath win:UnicodeString Ruta de acceso de la imagen de

lenguaje intermedio común (CIL) para el
módulo, o nombre de módulo dinámico
si es un ensamblado dinámico
(terminado en null).

ModuleNativePath win:UnicodeString Ruta de acceso de la imagen nativa de

módulo, si está presente (terminado en
null).
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

ManagedPdbSignature win:GUID Firma GUID de la base de datos de

programa (PDB) administrada que
coincide con este módulo.

ManagedPdbAge win:UInt32 Número de antigüedad escrito en la

PDB administrada que coincide con este
módulo.

ManagedPdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB administrada que coincide
con este módulo. En algunos casos,
puede tratarse simplemente de un
nombre de archivo.

NativePdbSignature win:GUID Firma GUID del PDB del generador de

imágenes nativas (NGen) que coincide
con este módulo, en su caso.

NativePdbAge win:UInt32 Número de antigüedad escrito en la

PDB de NGen que coincide con este
módulo, en su caso.

NativePdbBuildPath win:UnicodeString Ruta de acceso a la ubicación donde se

creó la PDB de NGen que coincide con
este módulo, en su caso. En algunos
casos, puede tratarse simplemente de
un nombre de archivo.

Evento AssemblyLoad_V1
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

AssemblyLoad_V1 154 Se genera cuando se carga un

ensamblado.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyID win:UInt64 Identificador único para el ensamblado.

AppDomainID win:UInt64 Identificador del dominio de este

ensamblado.

BindingID win:UInt64 Identificador que identifica de forma

exclusiva el enlace de ensamblado.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyFlags win:UInt32 0x1: ensamblado neutro de dominio.

0x2: ensamblado dinámico.

0x4: ensamblado con una imagen

nativa.

0x8: ensamblado recopilable.

AssemblyName win:UnicodeString Nombre completo del ensamblado.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento AssemblyUnload_V1
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

FireAssemblyUnload_V1 155 Se genera cuando se carga un

ensamblado.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyID win:UInt64 Identificador único para el ensamblado.

AppDomainID win:UInt64 Identificador del dominio de este

ensamblado.

BindingID win:UInt64 Identificador que identifica de forma

exclusiva el enlace de ensamblado.

AssemblyFlags win:UInt32 0x1: ensamblado neutro de dominio.

0x2: ensamblado dinámico.

0x4: ensamblado con una imagen

nativa.

0x8: ensamblado recopilable.

AssemblyName win:UnicodeString Nombre completo del ensamblado.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento AssemblyDCStart_V1
 PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

LoaderKeyword (0x8) DomainModuleLoad_V1 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

AssemblyDCStart_V1 155 Enumera los ensamblados durante una

detención de inicio.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyID win:UInt64 Identificador único para el ensamblado.

AppDomainID win:UInt64 Identificador del dominio de este

ensamblado.

BindingID win:UInt64 Identificador que identifica de forma

exclusiva el enlace de ensamblado.

AssemblyFlags win:UInt32 0x1: ensamblado neutro de dominio.

0x2: ensamblado dinámico.

0x4: ensamblado con una imagen

nativa.

0x8: ensamblado recopilable.

AssemblyName win:UnicodeString Nombre completo del ensamblado.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento AssemblyLoadStart
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

Binder 0x4 AssemblyLoadStart Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

AssemblyLoadStart 290 Se ha solicitado una carga de

ensamblado.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyName win:UnicodeString Nombre del nombre del ensamblado.

AssemblyPath win:UnicodeString Ruta de acceso del nombre del

ensamblado.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

RequestingAssembly win:UnicodeString Nombre del ensamblado que solicita

("primario").

AssemblyLoadContext win:UnicodeString Contexto de carga del ensamblado.

RequestingAssemblyLoadContext win:UnicodeString Contexto de carga del ensamblado de

solicitud ("primario").

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento AssemblyLoadStop
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

Binder 0x4 AssemblyLoadStart Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

AssemblyLoadStart 291 Se ha solicitado una carga de

ensamblado.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyName win:UnicodeString Nombre del nombre del ensamblado.

AssemblyPath win:UnicodeString Ruta de acceso del nombre del

ensamblado.

RequestingAssembly win:UnicodeString Nombre del ensamblado que solicita

("primario").

AssemblyLoadContext win:UnicodeString Contexto de carga del ensamblado.

RequestingAssemblyLoadContext win:UnicodeString Contexto de carga del ensamblado de

solicitud ("primario").

Success win:Boolean Si la carga del ensamblado se realizó

correctamente.

ResultAssemblyName win:UnicodeString Nombre del ensamblado que se cargó.

ResultAssemblyPath win:UnicodeString Ruta de acceso del ensamblado que se

cargó desde.

Cached win:UnicodeString Indica si la carga se almacenó en caché.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.
Evento ResolutionAttempted
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

Binder 0x4 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ResolutionAttempted 292 Se ha solicitado una carga de

ensamblado.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyName win:UnicodeString Nombre del nombre del ensamblado.

Stage win:UInt16 La fase de resolución.

0: buscar en la carga.

1: contexto de carga de ensamblado

2: ensamblados de la aplicación.

3: Reserva de contexto de carga de

ensamblado predeterminada.

4: resolución del ensamblado satélite.

5: resolución del contexto de carga de

ensamblado.

6: resolución de ensamblados de
AppDomain.

AssemblyLoadContext win:UnicodeString Contexto de carga del ensamblado.

Result win:UInt16 Resultado del intento de resolución.

0: correcto

1: ensamblado NotFound

2: versión incompatible

3: nombre de ensamblado no
coincidente

4: error

5: excepción

ResultAssemblyName win:UnicodeString Nombre del ensamblado que se

resolvió.

ResultAssemblyPath win:UnicodeString Ruta de acceso del ensamblado que se

resolvió a partir de.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ErrorMessage win:UnicodeString Mensaje de error si hay una excepción.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento AssemblyLoadContextResolvingHandlerInvoked
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

Binder 0x4 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

293
AssemblyLoadContextResolvingHandlerInvoked Se ha invocado un controlador de
AssemblyLoadContext. resolviendo .

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyName win:UnicodeString Nombre del nombre del ensamblado.

HandlerName win:UnicodeString Nombre del controlador invocado.

AssemblyLoadContext win:UnicodeString Contexto de carga del ensamblado.

ResultAssemblyName win:UnicodeString Nombre del ensamblado que se

resolvió.

ResultAssemblyPath win:UnicodeString Ruta de acceso del ensamblado que se

resolvió a partir de.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento AppDomainAssemblyResolveHandlerInvoked
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

Binder 0x4 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

AppDomainAssemblyResolveHandlerInvoked 294 Se ha AppDomain.AssemblyResolve

invocado un controlador.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyName win:UnicodeString Nombre del nombre del ensamblado.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

HandlerName win:UnicodeString Nombre del controlador invocado.

ResultAssemblyName win:UnicodeString Nombre del ensamblado que se

resolvió.

ResultAssemblyPath win:UnicodeString Ruta de acceso del ensamblado que se

resolvió a partir de.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento AssemblyLoadFromResolveHandlerInvoked
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

Binder 0x4 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

AssemblyLoadFromResolveHandlerInvoked 295 Se ha Assembly.LoadFrom invocado un

controlador.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AssemblyName win:UnicodeString Nombre del nombre del ensamblado.

IsTrackedLoad win:Boolean Indica si se realiza un seguimiento de la

carga del ensamblado.

RequestingAssemblyPath win:UnicodeString Ruta de acceso del ensamblado que se

solicita.

ComputedRequestedAssemblyPath win:UnicodeString Ruta de acceso del ensamblado que se

solicitó.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento KnownPathProbed
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

Binder 0x4 Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

KnownPathProbed 296 Se sondeó una ruta de acceso conocida

para un ensamblado.
N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

FilePath win:UnicodeString Ruta de acceso sondeada.

Source win:UInt16 Origen de la ruta de acceso sondeada.

0X0: ensamblados de aplicación.

0x1: ruta de acceso de imagen nativa de

la aplicación.

0X2: ruta de acceso de la aplicación.

0X3: raíces de recursos de la plataforma.

0x4: subdirectorio satélite.

Result win:UInt32 HRESULT para el sondeo.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.
 Eventos de métodos en tiempo de ejecución de .NET
18/12/2020 • 23 minutes to read • Edit Online

Estos eventos recopilan información que es específica de los métodos. La carga de estos eventos es necesaria para
la resolución de símbolos. Además, estos eventos proporcionan información útil, como los métodos que se cargan
y descargan. Para obtener más información sobre cómo usar estos eventos con fines de diagnóstico, consulte
registro y seguimiento de aplicaciones .net
Todos los eventos de método tienen un nivel de “Informativo (4)”. Todos los eventos detallados de método tienen
un nivel de “Detallado (5)”.
Todos los eventos de método se generan mediante la palabra clave JITKeyword (0x10) o la palabra clave
NGenKeyword (0x20) con el proveedor de runtime, o JitRundownKeyword (0x10) o NGENRundownKeyword (0x20) con el
proveedor de detención.
Las versiones V2 de estos eventos incluyen ReJITID, las versiones v1 no.

Evento MethodLoad_V1
En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodLoad_V1 141 Se genera cuando un método se carga

just-in-time (carga JIT) o se carga una
imagen NGEN. Los métodos dinámicos
y genéricos no usan esta versión para
cargas de método. Los asistentes de JIT
nunca usan esta versión.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0x10) Informativo (4)

NGenKeyword (0x20) Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único de un método. Para

los métodos del asistente JIT, se
establece en la dirección de inicio del
método.

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).

MethodStartAddress win:UInt64 Dirección de inicio del método.

MethodSize win:UInt32 Tamaño del método.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0x4: método de código compilado JIT

(en caso contrario, código de imagen
nativa de NGEN).

0x8: método del asistente.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodLoad_V2
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodLoad_V2 141 Se genera cuando un método se carga

just-in-time (carga JIT) o se carga una
imagen NGEN. Los métodos dinámicos
y genéricos no usan esta versión para
cargas de método. Los asistentes de JIT
nunca usan esta versión.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0x10) Informativo (4)

NGenKeyword (0x20) Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único de un método. Para

los métodos del asistente JIT, se
establece en la dirección de inicio del
método.

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).

MethodStartAddress win:UInt64 Dirección de inicio del método.

MethodSize win:UInt32 Tamaño del método.

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0x4: método de código compilado JIT

(en caso contrario, código de imagen
nativa de NGEN).

0x8: método del asistente.

ReJITID win:UInt64 IDENTIFICADOR de ReJIT del método.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodUnLoad_V1
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodUnLoad_V1 142 Se genera cuando se descarga un

módulo o se destruye un dominio de
aplicación. Los métodos dinámicos
nunca usan esta versión para descargas
de método.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único de un método. Para

los métodos del asistente JIT, se
establece en la dirección de inicio del
método.

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).

MethodStartAddress win:UInt64 Dirección de inicio del método.

MethodSize win:UInt32 Tamaño del método.

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0x4: método de código compilado JIT

(en caso contrario, código de imagen
nativa de NGEN).

0x8: método del asistente.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodUnLoad_V2
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodUnLoad_V2 142 Se genera cuando se descarga un

módulo o se destruye un dominio de
aplicación. Los métodos dinámicos
nunca usan esta versión para descargas
de método.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único de un método. Para

los métodos del asistente JIT, se
establece en la dirección de inicio del
método.

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).

MethodStartAddress win:UInt64 Dirección de inicio del método.

MethodSize win:UInt32 Tamaño del método.

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0x4: método de código compilado JIT

(en caso contrario, código de imagen
nativa de NGEN).

0x8: método del asistente.

ReJITID win:UInt64 IDENTIFICADOR de ReJIT del método.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento R2RGetEntryPoint
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

R2RGetEntryPoint 159 Se genera cuando finaliza una búsqueda

de punto de entrada R2R.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único de un método R2R.

MethodNamespace win:UnicodeString Espacio de nombres del método que se

va a buscar.

MethodName win:UnicodeString Nombre del método que se va a buscar.

MethodSignature win:UnicodeString Signatura del método (lista separada

por comas de nombres de tipo).

EntryPoint win:UInt64 Puntero al punto de entrada del

método R2R.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento R2RGetEntryPointStart
 EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

R2RGetEntryPointStart 160 Se genera cuando se inicia una

búsqueda de punto de entrada R2R.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único de un método R2R.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodLoadVerbose_V1
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodLoadVerbose_V1 143 Se genera cuando la carga de un

método es JIT o se carga una imagen
NGEN. Los métodos dinámicos y
genéricos siempre usan esta versión
para cargas de método. Los asistentes
de JIT siempre usan esta versión.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único del método. Para los

métodos del asistente JIT, se establece
en la dirección de inicio del método.

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).

MethodStartAddress win:UInt64 Dirección de inicio.

MethodSize win:UInt32 Longitud de método.

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0 x 4: método compilado JIT (de lo

contrario, generado por NGen.exe)

0x8: método del asistente.

MethodNameSpace win:UnicodeString Nombre del espacio de nombres

completo que está asociado al método.

MethodName win:UnicodeString Nombre de clase completo que está

asociado al método.

MethodSignature win:UnicodeString Signatura del método (lista separada

por comas de nombres de tipo).

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodLoadVerbose_V2
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodLoadVerbose_V1 143 Se genera cuando la carga de un

método es JIT o se carga una imagen
NGEN. Los métodos dinámicos y
genéricos siempre usan esta versión
para cargas de método. Los asistentes
de JIT siempre usan esta versión.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único del método. Para los

métodos del asistente JIT, se establece
en la dirección de inicio del método.

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).

MethodStartAddress win:UInt64 Dirección de inicio.

MethodSize win:UInt32 Longitud de método.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0 x 4: método compilado JIT (de lo

contrario, generado por NGen.exe)

0x8: método del asistente.

MethodNameSpace win:UnicodeString Nombre del espacio de nombres

completo que está asociado al método.

MethodName win:UnicodeString Nombre de clase completo que está

asociado al método.

MethodSignature win:UnicodeString Signatura del método (lista separada

por comas de nombres de tipo).

ReJITID win:UInt64 IDENTIFICADOR de ReJIT del método.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodUnLoadVerbose_V1
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodUnLoadVerbose_V1 144 Se genera cuando se destruye un

método dinámico, se descarga un
módulo o se destruye un dominio de
aplicación. Los métodos dinámicos
siempre usan esta versión para
descargas de método.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único del método. Para los

métodos del asistente JIT, se establece
en la dirección de inicio del método.

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodStartAddress win:UInt64 Dirección de inicio.

MethodSize win:UInt32 Longitud de método.

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0 x 4: método compilado JIT (de lo

contrario, generado por NGen.exe)

0x8: método del asistente.

MethodNameSpace win:UnicodeString Nombre del espacio de nombres

completo que está asociado al método.

MethodName win:UnicodeString Nombre de clase completo que está

asociado al método.

MethodSignature win:UnicodeString Signatura del método (lista separada

por comas de nombres de tipo).

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodUnLoadVerbose_V2
EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodUnLoadVerbose_V2 144 Se genera cuando se destruye un

método dinámico, se descarga un
módulo o se destruye un dominio de
aplicación. Los métodos dinámicos
siempre usan esta versión para
descargas de método.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Informativo (4)

NGenKeyword 0x20 Informativo (4)

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único del método. Para los

métodos del asistente JIT, se establece
en la dirección de inicio del método.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método (0 para
asistentes de JIT).

MethodStartAddress win:UInt64 Dirección de inicio.

MethodSize win:UInt32 Longitud de método.

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.

MethodFlags win:UInt32 0x1: método dinámico.

0x2: método genérico.

0 x 4: método compilado JIT (de lo

contrario, generado por NGen.exe)

0x8: método del asistente.

MethodNameSpace win:UnicodeString Nombre del espacio de nombres

completo que está asociado al método.

MethodName win:UnicodeString Nombre de clase completo que está

asociado al método.

MethodSignature win:UnicodeString Signatura del método (lista separada

por comas de nombres de tipo).

ReJITID win:UInt64 IDENTIFICADOR de ReJIT del método.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodJittingStarted_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITKeyword (0 x 10) Detallado (5)

NGenKeyword 0x20 Detallado (5)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodJittingStarted_V1 145 Se genera cuando se está realizando la

compilación JIT de un método.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único del método.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ModuleID win:UInt64 Identificador del módulo al que

pertenece este método.

MethodToken win:UInt32 0 para métodos dinámicos y asistentes

de JIT.

MethodILSize win:UInt32 Tamaño del lenguaje intermedio común

(CIL) del método que se va a compilar
con JIT.

MethodNameSpace win:UnicodeString Nombre de clase completo que está

asociado al método.

MethodName win:UnicodeString Nombre del método.

MethodSignature win:UnicodeString Signatura del método (lista separada

por comas de nombres de tipo).

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodJitInliningSucceeded
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITTracingKeyword 0x1000 Detallado (5)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodJitInliningSucceeded 185 Se genera cuando el compilador JIT

inserta correctamente un método.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodBeingCompiledNamespace win:UnicodeString Espacio de nombres del método que se

está compilando.

MethodBeingCompiledName win:UnicodeString Nombre del método que se está

compilando.

MethodBeingCompiledNameSignature win:UnicodeString Firma del método (lista separada por

comas de nombres de tipo) que se está
compilando.

InlinerNamespace win:UnicodeString Espacio de nombres del método

insertado ("primario").

InlinerName win:UnicodeString Nombre del método del insertador

("primario").
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

InlinerNameSignature win:UnicodeString Firma del método insertado ("Parent")

(lista separada por comas de nombres
de tipo).

InlineeNamespace win:UnicodeString Espacio de nombres del método inline

("Child").

InlineeName win:UnicodeString Nombre del método insertado

("secundario").

InlineeNameSignature win:UnicodeString Firma del método inline ("Child") (lista

separada por comas de nombres de
tipo).

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodJitInliningFailed
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITTracingKeyword 0x1000 Detallado (5)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodJitInliningFailed 192 Se genera cuando el compilador JIT no

pudo insertar un método.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodBeingCompiledNamespace win:UnicodeString Espacio de nombres del método que se

está compilando.

MethodBeingCompiledName win:UnicodeString Nombre del método que se está

compilando.

MethodBeingCompiledNameSignature win:UnicodeString Firma del método (lista separada por

comas de nombres de tipo) que se está
compilando.

InlinerNamespace win:UnicodeString Espacio de nombres del método

insertado ("primario").

InlinerName win:UnicodeString Nombre del método del insertador

("primario").

InlinerNameSignature win:UnicodeString Firma del método insertado ("Parent")

(lista separada por comas de nombres
de tipo).

InlineeNamespace win:UnicodeString Espacio de nombres del método inline

("Child").
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

InlineeName win:UnicodeString Nombre del método insertado

("secundario").

InlineeNameSignature win:UnicodeString Firma del método inline ("Child") (lista

separada por comas de nombres de
tipo).

FailAlways win:Boolean Indica si el método está marcado como

no pueda insertar.

FailReason win:UnicodeString No se pudo insertar el motivo.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodJitTailCallSucceeded
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITTracingKeyword 0x1000 Detallado (5)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodJitTailCallSucceeded 192 Generado por el compilador JIT cuando

se puede llamar a un método
correctamente.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodBeingCompiledNamespace win:UnicodeString Espacio de nombres del método que se

está compilando.

MethodBeingCompiledName win:UnicodeString Nombre del método que se está

compilando.

MethodBeingCompiledNameSignature win:UnicodeString Firma del método (lista separada por

comas de nombres de tipo) que se está
compilando.

CallerNamespace win:UnicodeString Espacio de nombres del método de

llamada.

CallerName win:UnicodeString Nombre del método de llamada.

CallerNameSignature win:UnicodeString Firma del método de llamada (lista

separada por comas de nombres de
tipo).

CalleeNamespace win:UnicodeString Espacio de nombres del método de

destinatario.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

CalleeName win:UnicodeString Nombre del método de destinatario.

CalleeNameSignature win:UnicodeString Firma del método de destinatario (lista

separada por comas de nombres de
tipo).

TailPrefix win:Boolean Indica si se trata de una instrucción de

prefijo de cola.

TailCallType win:UInt32 El tipo de llamada de cola.

0: llamada de cola optimizada (epílogo

+ JMP)

1: llamada de cola recursiva (método,

llamadas a la cola)

2: llamada a la cola asistida del

ayudante

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodJitTailCallFailed
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JITTracingKeyword 0x1000 Detallado (5)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodJitTailCallFailed 191 Generado por el compilador JIT cuando

no se pudo llamar a un método.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodBeingCompiledNamespace win:UnicodeString Espacio de nombres del método que se

está compilando.

MethodBeingCompiledName win:UnicodeString Nombre del método que se está

compilando.

MethodBeingCompiledNameSignature win:UnicodeString Firma del método (lista separada por

comas de nombres de tipo) que se está
compilando.

CallerNamespace win:UnicodeString Espacio de nombres del método de

llamada.

CallerNam e win:UnicodeString Nombre del método de llamada.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

CallerNameSignature win:UnicodeString Firma del método de llamada (lista

separada por comas de nombres de
tipo).

CalleeNamespace win:UnicodeString Espacio de nombres del método de

destinatario.

CalleeName win:UnicodeString Nombre del método de destinatario.

CalleeNameSignature win:UnicodeString Firma del método de destinatario (lista

separada por comas de nombres de
tipo).

TailPrefix win:Boolean Indica si se trata de una instrucción de

prefijo de cola.

FailReason win:UnicodeString Motivo del error de llamada de cola.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento MethodILToNativeMap
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

JittedMethodILToNativeMapKeyword (0x20000) Detallado (5)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

MethodILToNativeMap 190 Asigna el evento de asignación de IL a

nativo para métodos compilados JIT.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

MethodID win:UInt64 Identificador único de un método.

ReJITID win:UInt64 IDENTIFICADOR de ReJIT del método.

MethodExtent win:UInt8 La extensión del método JIT.

CountOfMapEntries win:UInt8 Número de entradas de mapa

ILOffsets win:UInt32 Desplazamiento IL.

NativeOffsets win:UInt32 Desplazamiento del código nativo.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.
 Eventos de grupo de subprocesos en tiempo de
ejecución .NET
18/12/2020 • 17 minutes to read • Edit Online

Estos eventos recopilan información sobre el trabajo y los subprocesos de e/s en ThreadPool. Para obtener más
información sobre cómo usar estos eventos con fines de diagnóstico, consulte registro y seguimiento de
aplicaciones .net

Evento IOThreadCreate_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

IOThreadCreate_V1 44 Se crea un subproceso de E/S en el

grupo de subprocesos.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt64 Número de subprocesos de E/S, incluido

el subproceso recién creado.

NumRetired win:UInt64 Número de subprocesos de trabajo

retirados.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento IOThreadTerminate_V1
En la tabla siguiente se muestra la palabra clave y el nivel

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

 EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

IOThreadTerminate 45 Se termina un subproceso de e/s en el

grupo de subprocesos.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt64 Número de subprocesos de E/S

restantes en el grupo de subprocesos.

NumRetired win:UInt64 Número de subprocesos de E/S

retirados.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento IOThreadRetire_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

IOThreadRetire_V1 46 Un subproceso de E/S se convierte en

un candidato para la retirada.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt64 Número de subprocesos de E/S

restantes en el grupo de subprocesos.

NumRetired win:UInt64 Número de subprocesos de E/S

retirados.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento IOThreadUnretire_V1
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO SE GEN ERA C UA N DO

IOThreadUnretire_V1 47 La retirada de un subproceso de E/S se

anula debido a que llega una E/S dentro
de un período de espera y después de
que el subproceso se convierte en un
candidato para la retirada.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Count win:UInt64 Número de subprocesos de E/S en el

grupo de subprocesos, incluido este.

NumRetired win:UInt64 Número de subprocesos de E/S

retirados.

ClrInstanceID Win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadStart
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolWorkerThreadStart 50 Se crea un subproceso de trabajo.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ActiveWorkerThreadCount win:UInt32 Número de subprocesos de trabajo

disponibles para procesar trabajo,
incluidos los que ya están procesando
trabajo.

RetiredWorkerThreadCount win:UInt32 Número de subprocesos de trabajo que

no están disponibles para procesar
trabajo, pero que se mantienen en
reserva en caso de que posteriormente
se necesiten más subprocesos.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadStop
 PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolWorkerThreadStop 51 Se detiene un subproceso de trabajo.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ActiveWorkerThreadCount win:UInt32 Número de subprocesos de trabajo

disponibles para procesar trabajo,
incluidos los que ya están procesando
trabajo.

RetiredWorkerThreadCount win:UInt32 Número de subprocesos de trabajo que

no están disponibles para procesar
trabajo, pero que se mantienen en
reserva en caso de que posteriormente
se necesiten más subprocesos.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadWait
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolWorkerThreadWait 57 Un subproceso de trabajo inicia la

espera de trabajo.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ActiveWorkerThreadCount win:UInt32 Número de subprocesos de trabajo

disponibles para procesar trabajo,
incluidos los que ya están procesando
trabajo.

RetiredWorkerThreadCount win:UInt32 Número de subprocesos de trabajo que

no están disponibles para procesar
trabajo, pero que se mantienen en
reserva en caso de que posteriormente
se necesiten más subprocesos.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadRetirementStart
 PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolWorkerThreadRetirementStart 52 Se retira un subproceso de trabajo.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ActiveWorkerThreadCount win:UInt32 Número de subprocesos de trabajo

disponibles para procesar trabajo,
incluidos los que ya están procesando
trabajo.

RetiredWorkerThreadCount win:UInt32 Número de subprocesos de trabajo que

no están disponibles para procesar
trabajo, pero que se mantienen en
reserva en caso de que posteriormente
se necesiten más subprocesos.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadRetirementStop
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolWorkerThreadRetirementStop 53 Un subproceso de trabajo retirado se

vuelve activo.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ActiveWorkerThreadCount win:UInt32 Número de subprocesos de trabajo

disponibles para procesar trabajo,
incluidos los que ya están procesando
trabajo.

RetiredWorkerThreadCount win:UInt32 Número de subprocesos de trabajo que

no están disponibles para procesar
trabajo, pero que se mantienen en
reserva en caso de que posteriormente
se necesiten más subprocesos.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadAdjustmentSample
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolWorkerThreadAdjustmentSample 54 Se refiere a la recopilación de

información para un ejemplo; es decir,
una medición del rendimiento con un
determinado nivel de simultaneidad en
un instante de tiempo.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Throughput win:Double Número de finalizaciones por unidad de

tiempo.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadAdjustmentAdjustment
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

55
ThreadPoolWorkerThreadAdjustmentAdjustment Registra un cambio en el control,
cuando el algoritmo de inserción de
subproceso (hill-climbing) determina
que tiene lugar un cambio en el nivel de
simultaneidad.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AverageThroughput win:Double Rendimiento medio de un ejemplo de

mediciones.

NewWorkerThreadCount win:UInt32 Nuevo número de subprocesos de

trabajo activos.
 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Reason win:UInt32 Razón para el ajuste.

0x0 Preparación.

0x1 Inicial.

0x2 -Movimiento aleatorio.

0x3 -Movimiento de subida.

0x4 -Cambiar punto.

0x5 Estabilización.

0x6 Colapso.

0x7 -El subproceso agotó el tiempo

de espera.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolWorkerThreadAdjustmentStats
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolWorkerThreadAdjustmentStats 56 Recopila datos en el grupo de

subprocesos.

En la tabla siguiente se muestran los datos del evento

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

Duration win:Double Cantidad de tiempo, en segundos,

durante el que se recopilaron estas
estadísticas.

Throughput win:Double Promedio de finalizaciones por segundo

durante este intervalo.

ThreadWave win:Double Reservado para uso interno.

ThroughputWave win:Double Reservado para uso interno.

ThroughputErrorEstimate win:Double Reservado para uso interno.

 N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

AverageThroughputErrorEstimate win:Double Reservado para uso interno.

ThroughputRatio win:Double Mejora relativa en el rendimiento

producida por variaciones en el número
de subprocesos de trabajo activos
durante este intervalo.

Confidence win:Double Medida de la validez del campo

ThroughputRatio.

NewcontrolSetting win:Double El número de subprocesos de trabajo

activos que servirá de línea de base
para las variaciones futuras en el
recuento de subprocesos activos.

NewThreadWaveMagnitude win:UInt16 La magnitud de variaciones futuras en

el recuento de subprocesos activos.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento ThreadPoolEnqueue
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolEnqueue 61 Se puso en cola un elemento de trabajo

en la cola del grupo de subprocesos.

En la tabla siguiente se muestran los datos del evento

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

WorkID win:Pointer Puntero a la solicitud de trabajo.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ThreadPoolDequeue
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolDequeue 62 Se quitó la cola de un elemento de

trabajo de la cola del grupo de
subprocesos.

En la tabla siguiente se muestran los datos del evento

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

WorkID win:Pointer Puntero a la solicitud de trabajo.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ThreadPoolIOEnqueue
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolIOEnqueue 63 Un subproceso pone en cola una

notificación de finalización de e/s
cuando se produce una finalización de
e/s asincrónica.

En la tabla siguiente se muestran los datos del evento

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

NativeOverlapped win:Pointer Reservado para uso interno.

Overlapped win:Pointer Reservado para uso interno.

MultiDequeues win:Boolean Reservado para uso interno.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ThreadPoolIODequeue
En la tabla siguiente se muestra la palabra clave y el nivel.
 PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolIODequeue 64 Un subproceso quita la cola de

finalización de e/s.

En la tabla siguiente se muestran los datos del evento

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

NativeOverlapped win:Pointer Reservado para uso interno.

Overlapped win:Pointer Reservado para uso interno.

MultiDequeues win:Boolean Reservado para uso interno.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ThreadPoolIOPack
En la tabla siguiente se muestra la palabra clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Detallado (5)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadPoolIOPack 65 Se llama al módulo de e/s superpuesta

de ThreadPool.

En la tabla siguiente se muestran los datos del evento

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

NativeOverlapped win:Pointer Reservado para uso interno.

Overlapped win:Pointer Reservado para uso interno.

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ThreadCreating
En la tabla siguiente se muestran las palabras clave y el nivel.
 PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadCreating 70 Se ha creado el subproceso.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ID win:Pointer Id. de subproceso

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.

Evento ThreadRunning
En la tabla siguiente se muestran las palabras clave y el nivel.

PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

ThreadingKeyword (0x10000) Informativo (4)

En la siguiente tabla se muestra la información del evento.

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

ThreadRunning 71 El subproceso ha empezado a

ejecutarse.

En la siguiente tabla se muestran los datos del evento.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ID win:Pointer Id. de subproceso

ClrInstanceID win:UInt16 IDENTIFICADOR único de la instancia

de CoreCLR.
 Eventos de tipo en tiempo de ejecución .NET
18/12/2020 • 2 minutes to read • Edit Online

Estos eventos recopilan información relacionada con la carga de tipos. Para obtener más información sobre cómo
usar estos eventos con fines de diagnóstico, consulte registro y seguimiento de aplicaciones .net

Evento TypeLoadStart
PA L A B RA C L AVE PA RA GEN ERA R EL
EVEN TO EVEN TO N IVEL

TypeDiagnosticKeyword Informativo (4)

(0x8000000000)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

TypeLoadStart 73 Se ha iniciado una carga de tipos.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

TypeLoadStartID win:UInt32 IDENTIFICADOR de la operación de

carga de tipo.

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.

Evento TypeLoadStop
PA L A B RA C L AVE PA RA GEN ERA R EL EVEN TO N IVEL

TypeDiagnosticKeyword (0x8000000000) Informativo (4)

EVEN TO ID. DE EVEN TO DESC RIP C IÓ N

TypeLoadStop 74 Se ha completado una carga de tipos.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

TypeLoadStartID win:UInt32 IDENTIFICADOR de la operación de

carga de tipo (coincide con el
TypeLoadStartID del evento
TypeLoadStart correspondiente).

LoadLevel win:UInt16 Nivel de carga de tipo.

TypeID win:UInt64 Puntero al identificador de tipo.

TypeName win:UnicodeString Nombre del tipo.

N O M B RE DEL C A M P O T IP O DE DATO S DESC RIP C IÓ N

ClrInstanceID win:UInt16 Identificador único para la instancia de

CLR o CoreCLR.
 Recopilación de diagnósticos en contenedores
18/12/2020 • 8 minutes to read • Edit Online

Las mismas herramientas de diagnóstico que son útiles para diagnosticar problemas de .NET Core en otros
escenarios también funcionan en contenedores de Docker. Sin embargo, algunas de las herramientas requieren
pasos especiales para funcionar en un contenedor. En este artículo se explica cómo se pueden usar herramientas
para reunir seguimientos del rendimiento y recopilar volcados en contenedores de Docker.

Uso de herramientas de CLI de .NET Core en un contenedor

Estas herramientas se aplican a: ✔
️ SDK de .NET Core 3.0 y versiones posteriores
Las herramientas de diagnóstico de la CLI global de .NET Core ( dotnet-counters , dotnet-dump , dotnet-gcdump y
dotnet-trace ) están diseñadas para funcionar en una amplia variedad de entornos y deberían funcionar
directamente en contenedores de Docker. Por este motivo, estas herramientas son el método preferido para
recopilar información de diagnóstico para escenarios de .NET Core que tienen como destino .NET Core 3.0 o
superior (o 3.1 o superior en el caso de dotnet-gcdump ) en contenedores.
El único factor que complica el uso de estas herramientas en un contenedor es que se instalan con el SDK de
.NET Core y muchos contenedores de Docker se ejecutan sin el SDK de .NET Core presente. Una solución sencilla a
este problema es instalar las herramientas en la imagen inicial de Docker. Las herramientas no necesitan que el
SDK de .NET Core se ejecute, solo que esté instalado. Por lo tanto, es posible crear un Dockerfile con una
compilación de varias fases que instale las herramientas en una fase de compilación (donde esté presente el SDK
de .NET Core) y, a continuación, copie los archivos binarios en la imagen final. El único inconveniente de este
enfoque es el aumento del tamaño de la imagen de Docker.

# In build stage
# Install desired .NET CLI diagnostics tools
RUN dotnet tool install --tool-path /tools dotnet-trace
RUN dotnet tool install --tool-path /tools dotnet-counters
RUN dotnet tool install --tool-path /tools dotnet-dump

...

# In final stage
# Copy diagnostics tools
WORKDIR /tools
COPY --from=build /tools .

Como alternativa, el SDK de .NET Core se puede instalar en un contenedor cuando sea necesario para instalar las
herramientas de la CLI. Tenga en cuenta que la instalación del SDK de .NET Core tendrá como efecto secundario la
reinstalación del entorno de ejecución de .NET Core. Asegúrese de instalar la versión del SDK que coincida con el
entorno de ejecución presente en el contenedor.
Uso de las herramientas de la CLI global de .NET Core en un contenedor sidecar
Si desea usar las herramientas de diagnóstico de la CLI global de .NET Core para diagnosticar los procesos en otro
contenedor, tenga en cuenta los siguientes requisitos adicionales:
1. Los contenedores deben compartir un espacio de nombres de proceso (de modo que las herramientas del
contenedor sidecar puedan acceder a los procesos del contenedor de destino).
2. Las herramientas de diagnóstico de la CLI global de .NET Core necesitan acceso a los archivos que el entorno
de ejecución de .NET Core escribe en el directorio /tmp, por lo que el directorio /tmp debe compartirse entre el
 contenedor de destino y sidecar a través de un montaje de volumen. Esto puede hacerse, por ejemplo,
haciendo que los contenedores compartan un volumen común o un volumen emptyDir de Kubernetes. Si
intenta usar las herramientas de diagnóstico desde un contenedor sidecar sin compartir el directorio /tmp,
obtendrá un error que indica que el proceso "no está ejecutando un entorno de ejecución de .NET compatible".

Uso de PerfCollect en un contenedor

Esta herramienta se aplica a: ✔
️ .NET Core 2.1 y versiones posteriores
El script PerfCollect resulta útil para recopilar seguimientos del rendimiento y es la herramienta recomendada
para recopilar seguimientos anteriores a .NET Core 3.0. Si utiliza PerfCollect en un contenedor, tenga en cuenta
los siguientes requisitos:
1. PerfCollect requiere la funcionalidad SYS_ADMIN (para ejecutar la herramienta perf ), por lo que debe
asegurarse de que el contenedor se inicia con esa capacidad.
2. PerfCollect requiere que se establezcan algunas variables de entorno antes de que se inicie la generación de
perfiles de la aplicación. Se pueden establecer en un Dockerfile o cuando se inicia el contenedor. Dado que
estas variables no deben establecerse en entornos de producción normales, es habitual simplemente
agregarlas al iniciar un contenedor del que se va a crear un perfil. Las dos variables que requiere PerfCollect
son:
a. COMPlus_PerfMapEnabled=1
b. COMPlus_EnableEventLog=1
Uso de PerfCollect en un contenedor sidecar
Si desea ejecutar PerfCollect en un contenedor para generar perfiles de un proceso de .NET Core en un
contenedor diferente, la experiencia es prácticamente la misma, con la salvedad de estas diferencias:
1. Las variables de entorno mencionadas previamente (COMPlus_PerfMapEnabled y COMPlus_EnableEventLog)
se deben establecer para el contenedor de destino (no el que ejecuta PerfCollect ).
2. El contenedor que ejecuta PerfCollect debe tener la funcionalidad SYS_ADMIN (no el contenedor de destino).
3. Los dos contenedores deben compartir un espacio de nombres de proceso.

Uso de createdump en un contenedor

Esta herramienta se aplica a: ✔
️ .NET Core 2.1 y versiones posteriores
Alternativa a dotnet-dump , createdump se puede usar para crear volcados principales en Linux que contienen
información nativa y administrada. La herramienta createdump se instala con el entorno de ejecución de .NET y se
puede encontrar junto a libcoreclr.so (normalmente en
"/usr/share/dotnet/shared/Microsoft.NETCore.App/[versión]"). La herramienta funciona de la misma forma en un
contenedor que en entornos de Linux no contenedores con la única excepción de que la herramienta requiere la
capacidad SYS_PTRACE , por lo que el contenedor de Docker debe iniciarse con esa capacidad.
Uso de createdump en un contenedor sidecar
Si desea usar createdump para crear un volcado de memoria a partir de un proceso en un contenedor diferente, la
experiencia es prácticamente la misma, con la salvedad de estas diferencias:
1. El contenedor que ejecuta createdump debe tener la funcionalidad SYS_PTRACE (no el contenedor de destino).
2. Los dos contenedores deben compartir un espacio de nombres de proceso.
 Investigación de los contadores de rendimiento
(dotnet-counters)
18/12/2020 • 16 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores

Instalar
Hay dos maneras de descargar e instalar dotnet-counters :
Herramienta global dotnet:
Para instalar la versión de lanzamiento más reciente del paquete NuGet de dotnet-counters , use
el comando dotnet tool install:

dotnet tool install --global dotnet-counters

Descarga directa:
descargue el archivo ejecutable de la herramienta que coincida con la plataforma:

SO P L ATA F O RM A

Windows x86 | x64 | arm | arm-x64

macOS x64

Linux x64 | arm | arm64 | musl-x64 | musl-arm64

Sinopsis
dotnet-counters [-h|--help] [--version] <command>

Descripción
dotnet-counters es una herramienta de supervisión de rendimiento diseñada para la investigación del
rendimiento y la supervisión del estado de primer nivel ad hoc. Puede observar los valores del contador
de rendimiento que se publican a través de la API EventCounter. Por ejemplo, se pueden supervisar
rápidamente cosas como el uso de la CPU o la velocidad de las excepciones que se producen en la
aplicación .NET Core para ver si hay algo sospechoso antes de profundizar en una investigación de
rendimiento más seria mediante PerfView o dotnet-trace .

Opciones
--version

Muestra la versión de la utilidad dotnet-counters.

 -h|--help

Muestra la ayuda de la línea de comandos.

Comandos
C O M A N DO

dotnet-counters collect

dotnet-counters list

dotnet-counters monitor

dotnet-counters ps

dotnet-counters collect
Recopila periódicamente los valores de contador seleccionados y los exporta a un formato de archivo
especificado para su posterior procesamiento.
Sinopsis

dotnet-counters collect [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-port] [--refresh-

interval] [--counters <COUNTERS>] [--format] [-o|--output] [-- <command>]

Opciones
-p|--process-id <PID>

Id. del proceso del que se van a recopilar datos de contador.

-n|--name <name>

Nombre del proceso del que se van a recopilar datos de contador.

--diagnostic-port

Nombre del puerto de diagnóstico que se va a crear. Vea Uso del puerto de diagnóstico para
saber cómo usar esta opción a fin de iniciar los contadores de supervisión desde el inicio de la
aplicación.
--refresh-interval <SECONDS>

Número de segundos de retraso entre la actualización de los contadores mostrados.

--counters <COUNTERS>

Una lista de contadores separados por comas. Los contadores pueden ser
provider_name[:counter_name] especificados. Si se usa provider_name sin una lista de contadores
que cumplan los requisitos, se mostrarán todos los contadores del proveedor. Para descubrir los
nombres del proveedor y del contador, use el comando dotnet-counters list.
--format <csv|json>

Formato que se va a exportar. Actualmente disponibles: csv, json.

-o|--output <output>
 Nombre del archivo de salida.
-- <command> (solo para seleccionar como destino aplicaciones que ejecutan .NET 5.0
o versiones posteriores)
Después de los parámetros de configuración de la colección, el usuario puede anexar --
seguido de un comando para iniciar una aplicación de .NET con un entorno de ejecución de 5.0
como mínimo. dotnet-counters iniciará un proceso con el comando proporcionado y recopilará
las métricas solicitadas. Esto suele ser útil para recopilar métricas de la ruta de acceso de inicio de
la aplicación y se puede usar para diagnosticar o supervisar los problemas que se producen
antes o poco después del punto de entrada principal.

NOTE
El uso de esta opción supervisa el primer proceso de .NET 5.0 que se comunica con la herramienta, lo
que significa que, si el comando inicia varias aplicaciones de .NET, solo recopilará la primera. Por tanto, se
recomienda usar esta opción en aplicaciones independientes, o bien utilizar la opción
dotnet exec <app.dll> .

NOTE
El inicio de un archivo ejecutable de .NET por medio de dotnet-counters redirigirá su entrada o salida, y
no podrá interactuar con su stdin/stdout. La salida de la herramienta por medio de Ctrl + C o SIGTERM
finalizará con seguridad la herramienta y el proceso secundario. Si el proceso secundario termina antes
que la herramienta, la herramienta también se cerrará y el seguimiento se debe poder ver de forma
segura. Si necesita usar stdin/stdout, puede usar la opción --diagnostic-port . Para obtener más
información, vea Uso del puerto de diagnóstico.

Ejemplos
Recopilación de todos los contadores en un intervalo de actualización de tres segundos y
generación de un archivo CSV como salida:

> dotnet-counters collect --process-id 1902 --refresh-interval 3 --format csv

counter_list is unspecified. Monitoring all counters by default.

Starting a counter session. Press Q to quit.

Inicie dotnet mvc.dll como un proceso secundario y comience a recopilar contadores de tiempo
de ejecución y contadores de hospedaje de ASP.NET Core del inicio, y guárdelo como una salida
JSON:

> dotnet-counters collect --format json --counters

System.Runtime,Microsoft.AspNetCore.Hosting -- dotnet mvc.dll
Starting a counter session. Press Q to quit.
File saved to counter.json

dotnet-counters list
Muestra una lista de nombres y descripciones de contador, agrupada por proveedor.
Sinopsis
 dotnet-counters list [-h|--help]

Ejemplo

> dotnet-counters list

Showing well-known counters only. Specific processes may support additional counters.

System.Runtime
cpu-usage Amount of time the process has utilized the CPU
(ms)
working-set Amount of working set used by the process (MB)
gc-heap-size Total heap size reported by the GC (MB)
gen-0-gc-count Number of Gen 0 GCs / min
gen-1-gc-count Number of Gen 1 GCs / min
gen-2-gc-count Number of Gen 2 GCs / min
time-in-gc % time in GC since the last GC
gen-0-size Gen 0 Heap Size
gen-1-size Gen 1 Heap Size
gen-2-size Gen 2 Heap Size
loh-size LOH Heap Size
alloc-rate Allocation Rate
assembly-count Number of Assemblies Loaded
exception-count Number of Exceptions / sec
threadpool-thread-count Number of ThreadPool Threads
monitor-lock-contention-count Monitor Lock Contention Count
threadpool-queue-length ThreadPool Work Items Queue Length
threadpool-completed-items-count ThreadPool Completed Work Items Count
active-timer-count Active Timers Count

Microsoft.AspNetCore.Hosting
requests-per-second Request rate
total-requests Total number of requests
current-requests Current number of requests
failed-requests Failed number of requests

NOTE
Los contadores de Microsoft.AspNetCore.Hosting se muestran cuando hay procesos identificados que
admiten estos contadores, por ejemplo, cuando una aplicación ASP.NET Core se está ejecutando en el equipo
host.

dotnet-counters monitor
Muestra la actualización periódica de los valores de los contadores seleccionados.
Sinopsis

dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-port] [--refresh-

interval] [--counters] [-- <command>]

Opciones
-p|--process-id <PID>

Id. del proceso que se va a supervisar.

-n|--name <name>

Nombre del proceso que se va a supervisar.

 --diagnostic-port

Nombre del puerto de diagnóstico que se va a crear. Vea Uso del puerto de diagnóstico para
saber cómo usar esta opción a fin de iniciar los contadores de supervisión desde el inicio de la
aplicación.
--refresh-interval <SECONDS>

Número de segundos de retraso entre la actualización de los contadores mostrados.

--counters <COUNTERS>

Una lista de contadores separados por comas. Los contadores pueden ser
provider_name[:counter_name] especificados. Si se usa provider_name sin una lista de contadores
que cumplan los requisitos, se mostrarán todos los contadores del proveedor. Para descubrir los
nombres del proveedor y del contador, use el comando dotnet-counters list.
-- <command>(solo para seleccionar como destino aplicaciones que ejecutan .NET 5.0 o
versiones posteriores)
Después de los parámetros de configuración de la colección, el usuario puede anexar -- seguido de un
comando para iniciar una aplicación de .NET con un entorno de ejecución de 5.0 como mínimo.
dotnet-counters iniciará un proceso con el comando proporcionado y supervisará las métricas
solicitadas. Esto suele ser útil para recopilar métricas de la ruta de acceso de inicio de la aplicación y se
puede usar para diagnosticar o supervisar los problemas que se producen antes o poco después del
punto de entrada principal.

NOTE
El uso de esta opción supervisa el primer proceso de .NET 5.0 que se comunica con la herramienta, lo que
significa que, si el comando inicia varias aplicaciones de .NET, solo recopilará la primera. Por tanto, se recomienda
usar esta opción en aplicaciones independientes, o bien utilizar la opción dotnet exec <app.dll> .

NOTE
El inicio de un archivo ejecutable de .NET por medio de dotnet-counters redirigirá su entrada o salida, y no podrá
interactuar con su stdin/stdout. La salida de la herramienta por medio de Ctrl + C o SIGTERM finalizará con
seguridad la herramienta y el proceso secundario. Si el proceso secundario termina antes que la herramienta, la
herramienta también se cerrará y el seguimiento se debe poder ver de forma segura. Si necesita usar
stdin/stdout, puede usar la opción --diagnostic-port . Para obtener más información, vea Uso del puerto de
diagnóstico.

Ejemplos
Supervisión de todos los contadores de System.Runtime con un intervalo de actualización de 3
segundos:
 > dotnet-counters monitor --process-id 1902 --refresh-interval 3 --counters System.Runtime
Press p to pause, r to resume, q to quit.
Status: Running

[System.Runtime]
% Time in GC since last GC (%) 0
Allocation Rate (B / 1 sec) 5,376
CPU Usage (%) 0
Exception Count (Count / 1 sec) 0
GC Fragmentation (%) 48.467
GC Heap Size (MB) 0
Gen 0 GC Count (Count / 1 sec) 1
Gen 0 Size (B) 24
Gen 1 GC Count (Count / 1 sec) 1
Gen 1 Size (B) 24
Gen 2 GC Count (Count / 1 sec) 1
Gen 2 Size (B) 272,000
IL Bytes Jitted (B) 19,449
LOH Size (B) 19,640
Monitor Lock Contention Count (Count / 1 sec) 0
Number of Active Timers 0
Number of Assemblies Loaded 7
Number of Methods Jitted 166
POH (Pinned Object Heap) Size (B) 24
ThreadPool Completed Work Item Count (Count / 1 sec) 0
ThreadPool Queue Length 0
ThreadPool Thread Count 2
Working Set (MB) 19

Supervisión de únicamente el uso de la CPU y el tamaño del montón de GC de System.Runtime :

> dotnet-counters monitor --process-id 1902 --counters System.Runtime[cpu-usage,gc-heap-size]

Press p to pause, r to resume, q to quit.

Status: Running

[System.Runtime]
CPU Usage (%) 24
GC Heap Size (MB) 811

Supervisión de los valores EventCounter del elemento EventSource definido por el usuario. Para
obtener más información, consulte Tutorial: Medición del rendimiento mediante EventCounters
en .NET Core.

> dotnet-counters monitor --process-id 1902 --counters Samples-EventCounterDemos-Minimal

Press p to pause, r to resume, q to quit.

request 100

Inicie my-aspnet-server.exe y supervise el número de ensamblados cargados desde su inicio

(solo para .NET 5.0 o versiones posteriores):

IMPORTANT
Esto solo funciona para las aplicaciones que ejecutan .NET 5.0 o una versión posterior.
 > dotnet-counters monitor --counters System.Runtime[assembly-count] -- my-aspnet-server.exe

Press p to pause, r to resume, q to quit.

Status: Running

[System.Runtime]
Number of Assemblies Loaded 24

Inicie my-aspnet-server.exe con arg1 y arg2 como argumentos de la línea de comandos y

supervise su espacio de trabajo y el tamaño del montón de GC desde su inicio (solo para .NET 5.0
o versiones posteriores):

IMPORTANT
Esto solo funciona para las aplicaciones que ejecutan .NET 5.0 o una versión posterior.

> dotnet-counters monitor --counters System.Runtime[working-set,gc-heap-size] -- my-aspnet-

server.exe arg1 arg2

Press p to pause, r to resume, q to quit.

Status: Running

[System.Runtime]
GC Heap Size (MB) 39
Working Set (MB) 59

dotnet-counters ps
Muestra una lista de los procesos de dotnet que se pueden supervisar.
Sinopsis

dotnet-counters ps [-h|--help]

Ejemplo

> dotnet-counters ps

15683 WebApi /home/user/repos/WebApi/WebApi

16324 dotnet /usr/local/share/dotnet/dotnet

Uso del puerto de diagnóstico

IMPORTANT
Esto solo funciona para las aplicaciones que ejecutan .NET 5.0 o una versión posterior.

El puerto de diagnóstico es una característica nueva del entorno de ejecución que se ha agregado en
.NET 5 y permite iniciar la supervisión o la recopilación de contadores desde el inicio de la aplicación.
Para hacer esto con dotnet-counters , puede usar dotnet-counters <collect|monitor> -- <command> , tal
como se describe en los ejemplos anteriores, o bien la opción --diagnostic-port .
El uso de dotnet-counters <collect|monitor> -- <command> para iniciar la aplicación como un proceso
secundario es la manera más sencilla de realizar una supervisión rápida desde el inicio.
Sin embargo, si quiere obtener un control más preciso sobre la vigencia de la aplicación supervisada
(por ejemplo, supervisar la aplicación solo durante los primeros 10 minutos y continuar la ejecución), o
si necesita interactuar con la aplicación mediante la CLI, el uso de la opción --diagnostic-port le
permite controlar la aplicación de destino que se supervisa y dotnet-counters .
1. El comando siguiente hace que dotnet-counters cree un socket de diagnóstico denominado
myport.sock y que espere a una conexión.

dotnet-counters collect --diagnostic-port myport.sock

Salida:

Waiting for connection on myport.sock

Start an application with the following environment variable:
DOTNET_DiagnosticPorts=/home/user/myport.sock

2. En una consola independiente, inicie la aplicación de destino con la variable de entorno

DOTNET_DiagnosticPorts establecida en el valor de la salida de dotnet-counters .

export DOTNET_DiagnosticPorts=/home/user/myport.sock
./my-dotnet-app arg1 arg2

Esto debe habilitar dotnet-counters para empezar a recopilar contadores en my-dotnet-app :

Waiting for connection on myport.sock

Start an application with the following environment variable:
DOTNET_DiagnosticPorts=myport.sock
Starting a counter session. Press Q to quit.

IMPORTANT
Iniciar la aplicación con dotnet run puede resultar problemático porque la CLI de dotnet puede
generar muchos procesos secundarios que no sean la aplicación. Además, dichos procesos secundarios
pueden conectarse a dotnet-counters antes que la aplicación, lo que causa que esta se suspenda en
tiempo de ejecución. Se recomienda usar directamente una versión independiente de la aplicación o
dotnet exec para iniciar la aplicación.
 Utilidad de recopilación y análisis de volcado de
memoria (dotnet-dump)
18/12/2020 • 10 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores

NOTE
dotnet-dump para macOS solo se admite con .NET 5.0 y versiones posteriores.

Instalar
Hay dos maneras de descargar e instalar dotnet-dump :
Herramienta global dotnet:
Para instalar la versión de lanzamiento más reciente del paquete NuGet de dotnet-dump , use el
comando dotnet tool install:

dotnet tool install --global dotnet-dump

Descarga directa:
descargue el archivo ejecutable de la herramienta que coincida con la plataforma:

SO P L ATA F O RM A

Windows x86 | x64 | arm | arm-x64

macOS x64

Linux x64 | arm | arm64 | musl-x64 | musl-arm64

Sinopsis
dotnet-dump [-h|--help] [--version] <command>

Descripción
La herramienta global dotnet-dump es una forma de recopilar y analizar los volcados de Windows y Linux
sin necesidad de un depurador nativo implicado, como lldb en Linux. Esta herramienta es importante en
plataformas como Alpine Linux, donde no está disponible una versión de lldb totalmente operativa. La
herramienta dotnet-dump permite ejecutar comandos SOS para analizar bloqueos y el recolector de
elementos no utilizados (GC), pero no es un depurador nativo, por lo que no se admiten elementos como la
visualización de marcos de pila nativos.
Opciones
--version

Muestra la versión de la utilidad dotnet-dump.

-h|--help

Muestra la ayuda de la línea de comandos.

Comandos
C O M A N DO

dotnet-dump collect

dotnet-dump analyze

dotnet-dump collect
Captura un volcado de un proceso.
Sinopsis

dotnet-dump collect [-h|--help] [-p|--process-id] [-n|--name] [--type] [-o|--output] [--diag]

Opciones
-h|--help

Muestra la ayuda de la línea de comandos.

-p|--process-id <PID>

Especifica el número de id. de proceso del que se va a recopilar un volcado.

-n|--name <name>

Especifica el nombre del proceso del que se va a recopilar un volcado.

--type <Full|Heap|Mini>

Especifica el tipo de volcado, que determina los tipos de información que se recopilan del proceso.
Existen tres tipos:
Full : el volcado más grande que contiene toda la memoria, incluidas las imágenes de los
módulos.
Heap : un volcado grande y relativamente completo que contiene listas de módulos, listas de
subprocesos, todas las pilas, información de excepción, información de control y toda la memoria
excepto las imágenes asignadas.
Mini : un volcado pequeño que contiene listas de módulos, listas de subprocesos, información de
excepción y todas las pilas.
Si no se especifica, el valor predeterminado es Full .
-o|--output <output_dump_path>

La ruta de acceso completa y el nombre de archivo donde se debe escribir el volcado recopilado.
 Si no se especifica:
El valor predeterminado es .\dump_AAAAMMDD_HHMMSS.dmp en Windows.
El valor predeterminado es ./core_AAAAMMDD_HHMMSS en Linux.
AAAAMMDD es año/mes/día y HHMMSS es hora/minuto/segundo.
--diag

Habilita el registro de diagnóstico de la recopilación de volcado.

dotnet-dump analyze
Inicia un shell interactivo para explorar un volcado. El shell acepta varios comandos SOS.
Sinopsis

dotnet-dump analyze <dump_path> [-h|--help] [-c|--command]

Argumentos
<dump_path>

Especifica la ruta de acceso al archivo de volcado que se va a analizar.

Opciones
-c|--command <debug_command>

Especifica el comando que se va a ejecutar en el shell al inicio.

Análisis de comandos SOS
C O M A N DO F UN C IÓ N

soshelp Muestra todos los comandos disponibles.

soshelp|help <command> Muestra el comando especificado.

exit|quit Sale del modo interactivo.

clrstack <arguments> Proporciona un seguimiento de pila del código

administrado únicamente.

clrthreads <arguments> Enumera los subprocesos administrados que se ejecutan.

dumpasync <arguments> Muestra información sobre las máquinas de estado

asincrónicas en el montón de recolección de elementos no
utilizados.

dumpassembly <arguments> Muestra detalles sobre un ensamblado.

dumpclass <arguments> Muestra información sobre una estructura de clase EE en

la dirección especificada.

dumpdelegate <arguments> Muestra información sobre un delegado.

C O M A N DO F UN C IÓ N

dumpdomain <arguments> Muestra información sobre todos los dominios de

aplicación y sobre todos los ensamblados en los dominios.

dumpheap <arguments> Muestra información sobre el montón de recolección de

elementos no utilizados y estadísticas de recolección de los
objetos.

dumpil <arguments> Muestra el Lenguaje intermedio de Microsoft (MSIL) que

está asociado a un método administrado.

dumplog <arguments> Escribe el contenido de un registro de esfuerzo existente

en memoria en el archivo especificado.

dumpmd <arguments> Muestra información sobre una estructura MethodDesc en

la dirección especificada.

dumpmodule <arguments> Muestra información sobre una estructura de módulo EE

en la dirección especificada.

dumpmt <arguments> Muestra información sobre una tabla de métodos en la

dirección especificada.

dumpobj <arguments> Muestra información sobre un objeto en la dirección

especificada.

dso|dumpstackobjects <arguments> Muestra todos los objetos administrados que se han

encontrado dentro de los límites de la pila actual.

eeheap <arguments> Muestra información sobre la memoria de proceso que

usan las estructuras de datos internas del runtime.

finalizequeue <arguments> Muestra todos los objetos registrados para su finalización.

gcroot <arguments> Muestra información acerca de las referencias (o raíces) a

un objeto en la dirección especificada.

gcwhere <arguments> Muestra la ubicación en el montón de recolección de

elementos no utilizados del argumento que se ha pasado.

ip2md <arguments> Muestra la estructura MethodDesc en la dirección

especificada en código JIT.

histclear <arguments> Libera los recursos usados por la familia de comandos

hist* .

histinit <arguments> Inicializa las estructuras SOS del registro de esfuerzo

guardado en el código que se está depurando.

histobj <arguments> Muestra las reubicaciones de registro de esfuerzo de la

recolección de elementos no utilizados relacionadas con
<arguments> .
 C O M A N DO F UN C IÓ N

histobjfind <arguments> Muestra todas las entradas de registro que hacen

referencia a un objeto en la dirección especificada.

histroot <arguments> Muestra información relacionada con las promociones y las

reubicaciones de la raíz especificada.

lm|modules Muestra los módulos nativos del proceso.

name2ee <arguments> Muestra la estructura MethodTable y la estructura EEClass

para <argument> .

pe|printexception <arguments> Muestra cualquier objeto que se deriva de la clase

Exception en la dirección <argument> .

setsymbolserver <arguments> Habilita la compatibilidad con el servidor de símbolos.

syncblk <arguments> Muestra la información del contenedor de SyncBlock.

threads|setthread <threadid> Establece o muestra el identificador del subproceso actual

para los comandos SOS.

Uso de dotnet-dump
El primer paso es recopilar un volcado. Este paso se puede omitir si ya se ha generado un volcado principal.
El sistema operativo o la característica de generación de volcado integrada del runtime de .NET Core pueden
crear volcados principales.

$ dotnet-dump collect --process-id 1902

Writing minidump to file ./core_20190226_135837
Written 98983936 bytes (24166 pages) to core file
Complete

Ahora analice el volcado principal con el comando analyze :

$ dotnet-dump analyze ./core_20190226_135850

Loading core dump: ./core_20190226_135850
Ready to process analysis commands. Type 'help' to list available commands or 'help [command]' to get
detailed help on a command.
Type 'quit' or 'exit' to exit the session.
>

Esta acción abre una sesión interactiva que acepta comandos como los siguientes:
 > clrstack
OS Thread Id: 0x573d (0)
Child SP IP Call Site
00007FFD28B42C58 00007fb22c1a8ed9 [HelperMethodFrame_PROTECTOBJ: 00007ffd28b42c58]
System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean,
Boolean)
00007FFD28B42DD0 00007FB1B1334F67 System.Reflection.RuntimeMethodInfo.Invoke(System.Object,
System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[],
System.Globalization.CultureInfo) [/root/coreclr/src/mscorlib/src/System/Reflection/RuntimeMethodInfo.cs
@ 472]
00007FFD28B42E20 00007FB1B18D33ED SymbolTestApp.Program.Foo4(System.String)
[/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 54]
00007FFD28B42ED0 00007FB1B18D2FC4 SymbolTestApp.Program.Foo2(Int32, System.String)
[/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 29]
00007FFD28B42F00 00007FB1B18D2F5A SymbolTestApp.Program.Foo1(Int32, System.String)
[/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 24]
00007FFD28B42F30 00007FB1B18D168E SymbolTestApp.Program.Main(System.String[])
[/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 19]
00007FFD28B43210 00007fb22aa9cedf [GCFrame: 00007ffd28b43210]
00007FFD28B43610 00007fb22aa9cedf [GCFrame: 00007ffd28b43610]

Para ver una excepción no controlada que ha terminado la aplicación:

> pe -lines
Exception object: 00007fb18c038590
Exception type: System.Reflection.TargetInvocationException
Message: Exception has been thrown by the target of an invocation.
InnerException: System.Exception, Use !PrintException 00007FB18C038368 to see more.
StackTrace (generated):
SP IP Function
00007FFD28B42DD0 0000000000000000
System.Private.CoreLib.dll!System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[],
System.Signature, Boolean, Boolean)
00007FFD28B42DD0 00007FB1B1334F67
System.Private.CoreLib.dll!System.Reflection.RuntimeMethodInfo.Invoke(System.Object,
System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[],
System.Globalization.CultureInfo)+0xa7
[/root/coreclr/src/mscorlib/src/System/Reflection/RuntimeMethodInfo.cs @ 472]
00007FFD28B42E20 00007FB1B18D33ED SymbolTestApp.dll!SymbolTestApp.Program.Foo4(System.String)+0x15d
[/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 54]
00007FFD28B42ED0 00007FB1B18D2FC4 SymbolTestApp.dll!SymbolTestApp.Program.Foo2(Int32,
System.String)+0x34 [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 29]
00007FFD28B42F00 00007FB1B18D2F5A SymbolTestApp.dll!SymbolTestApp.Program.Foo1(Int32,
System.String)+0x3a [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 24]
00007FFD28B42F30 00007FB1B18D168E SymbolTestApp.dll!SymbolTestApp.Program.Main(System.String[])+0x6e
[/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 19]

StackTraceString: <none>
HResult: 80131604

Instrucciones especiales para Docker

Si ejecuta en Docker, la recopilación de volcados requiere capacidades de SYS_PTRACE ( --cap-add=SYS_PTRACE
o --privileged ).
En Microsoft SDK de .NET Core imágenes de Docker de SDK de Linux, algunos comandos dotnet-dump
pueden producir la siguiente excepción:

Excepción no controlada: System.DllNotFoundException: No se puede cargar la biblioteca compartida

"libdl.so" o una de su excepción de dependencias.
Para solucionar este problema, instale el paquete "libc6-dev".

Vea también
Entrada de blog sobre la recopilación y el análisis de volcados de memoria
Herramienta de análisis del montón (dotnet-gcdump)
 Herramienta de análisis del montón (dotnet-
gcdump)
18/12/2020 • 5 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.1 y versiones posteriores

Instalar
Hay dos maneras de descargar e instalar dotnet-gcdump :
Herramienta global dotnet:
Para instalar la versión de lanzamiento más reciente del paquete NuGet de dotnet-gcdump , use el
comando dotnet tool install:

dotnet tool install --global dotnet-gcdump

Descarga directa:
Descargue el archivo ejecutable de la herramienta que coincida con la plataforma:

SO P L ATA F O RM A

Windows x86 | x64 | arm | arm-x64

macOS x64

Linux x64 | arm | arm64 | musl-x64 | musl-arm64

Sinopsis
dotnet-gcdump [-h|--help] [--version] <command>

Descripción
La herramienta global dotnet-gcdump recopila volcados de memoria de GC (recolector de elementos no
utilizados) de procesos de .NET en vivo mediante EventPipe. Los volcados de memoria de GC se crean
desencadenando un GC en el proceso de destino, activando eventos especiales y regenerando el gráfico de
raíces de objeto a partir del flujo de eventos. Este proceso permite recopilar volcados de memoria de GC
mientras el proceso se está ejecutando y con una sobrecarga mínima. Estos volcados de memoria son útiles para
varios escenarios:
Comparar el número de objetos del montón en varios puntos en el tiempo.
Analizar raíces de objetos (responder a preguntas como "¿qué sigue teniendo una referencia a este tipo?").
Recopilar estadísticas generales sobre los recuentos de objetos en el montón.
Ver el volcado de memoria de GC capturado por dotnet-gcdump
En Windows, los archivos .gcdump se pueden ver en PerfView o en Visual Studio para analizarlos. Actualmente,
no es posible abrir un archivo .gcdump en plataformas que no sean de Windows.
Puede recopilar varios archivos .gcdump y abrirlos simultáneamente en Visual Studio para obtener una
comparativa.

Opciones
--version

Muestra la versión del servicio dotnet-gcdump .

-h|--help

Muestra la ayuda de la línea de comandos.

dotnet-gcdump collect
Recopila un volcado de memoria de GC de un proceso que se está ejecutando actualmente.
Sinopsis

dotnet-gcdump collect [-h|--help] [-p|--process-id <pid>] [-o|--output <gcdump-file-path>] [-v|--verbose] [-

t|--timeout <timeout>] [-n|--name <name>]

Opciones
-h|--help

Muestra la ayuda de la línea de comandos.

-p|--process-id <pid>

Identificador del proceso del que se va a recopilar el volcado de memoria de GC.

-o|--output <gcdump-file-path>

Ruta de acceso donde se deben escribir los volcados de memoria de GC recopilados. El valor
predeterminado es .\AAAAMMDD_HHMMSS_<pid>.gcdump.
-v|--verbose

Obtener resultados del registro mientras recopila el volcado de memoria de GC.

-t|--timeout <timeout>

Dejar de recopilar el volcado de memoria de GC si tarda más de la cantidad de segundos indicada. El

valor predeterminado es 30.
-n|--name <name>

Nombre del proceso del que se va a recopilar el volcado de memoria de GC.

dotnet-gcdump ps
Enumera los procesos de dotnet de los que se pueden recopilar volcados de memoria de GC.
Sinopsis

dotnet-gcdump ps
 dotnet-gcdump report <gcdump_filename>
Crear un informe a partir de un volcado de memoria de GC generado anteriormente o de un proceso en
ejecución y escribir en stdout .
Sinopsis

dotnet-gcdump report [-h|--help] [-p|--process-id <pid>] [-t|--report-type <HeapStat>]

Opciones
-h|--help

Muestra la ayuda de la línea de comandos.

-p|--process-id <pid>

Identificador del proceso del que se va a recopilar el volcado de memoria de GC.

-t|--report-type <HeapStat>

Tipo de informe que se va a generar. Opciones disponibles: heapstat (predeterminado).

Solución de problemas
No hay información de tipo en gcdump.
Antes de .NET Core 3.1, se producía un problema por el que una memoria caché de tipos no se borraba
entre varios gcdump cuando se invocaba con EventPipe. El resultado fue que los eventos necesarios para
determinar la información de tipo no se enviaban al segundo gcdump y a los siguientes. Esto se corrigió
en la versión preliminar 2 de .NET Core 3.1.
Los tipos COM y estáticos no se encuentran en el volcado de memoria de GC.
Antes de la versión preliminar 2 de .NET Core 3.1, se producía un problema por el que los tipos estáticos y
COM no se enviaban cuando se invocaba el volcado de memoria de GC a través de EventPipe. Esto se ha
corregido en la versión preliminar 2 de .NET Core 3.1.
 Utilidad de análisis de rendimiento dotnet-trace
18/12/2020 • 15 minutes to read • Edit Online

Este ar tículo se aplica a: ✔

️ SDK de .NET Core 3.0 y versiones posteriores

Instalar
Hay dos maneras de descargar e instalar dotnet-trace :
Herramienta global dotnet:
Para instalar la versión de lanzamiento más reciente del paquete NuGet de dotnet-trace , use el
comando dotnet tool install:

dotnet tool install --global dotnet-trace

Descarga directa:
descargue el archivo ejecutable de la herramienta que coincida con la plataforma:

SO P L ATA F O RM A

Windows x86 | x64 | arm | arm-x64

macOS x64

Linux x64 | arm | arm64 | musl-x64 | musl-arm64

Sinopsis
dotnet-trace [-h, --help] [--version] <command>

Descripción
La herramienta dotnet-trace :
Es una herramienta de .NET Core para varias plataformas.
Habilita la recolección de seguimientos de .NET Core de un proceso en ejecución sin un generador de
perfiles nativo.
Se basa en EventPipe del entorno de ejecución de .NET Core.
Ofrece la misma experiencia en Windows, Linux o macOS.

Opciones
-h|--help

Muestra la ayuda de la línea de comandos.

--version
 Muestra la versión de la utilidad dotnet-trace.

Comandos
C O M A N DO

dotnet-trace collect

dotnet-trace convert

dotnet-trace ps

dotnet-trace list-profiles

dotnet-trace collect
Recopila un seguimiento de diagnóstico de un proceso en ejecución.
Sinopsis

dotnet-trace collect [--buffersize <size>] [--clreventlevel <clreventlevel>] [--clrevents <clrevents>]

[--format <Chromium|NetTrace|Speedscope>] [-h|--help]
[-n, --name <name>] [--diagnostic-port] [-o|--output <trace-file-path>] [-p|--process-id <pid>]
[--profile <profile-name>] [--providers <list-of-comma-separated-providers>]
[-- <command>] (for target applications running .NET 5.0 or later)

Opciones
--buffersize <size>

Establece el tamaño del búfer circular en memoria, en megabytes. Valor predeterminado de 256 MB.
--clreventlevel <clreventlevel>

Nivel de detalle de los eventos CLR que se van a emitir.

--clrevents <clrevents>

Lista de eventos de tiempo de ejecución de CLR que se van a emitir.

--format {Chromium|NetTrace|Speedscope}

Establece el formato de salida para la conversión del archivo de seguimiento. De manera

predeterminada, es NetTrace .
-n, --name <name>

Nombre del proceso del que se va a recopilar el seguimiento.

--diagnostic-port <path-to-port>

Nombre del puerto de diagnóstico que se va a crear. Vea Uso del puerto de diagnóstico para recopilar
un seguimiento desde el inicio de la aplicación para obtener información sobre cómo usar esta opción
para recopilar un seguimiento desde el inicio de la aplicación.
-o|--output <trace-file-path>

Ruta de acceso de salida para los datos de seguimiento recopilados. Si no se especifica, el valor
predeterminado es trace.nettrace .
 -p|--process-id <PID>

Identificador del proceso del que se va a recopilar el seguimiento.

--profile <profile-name>

Un conjunto con nombre predefinido de configuraciones de proveedor que permite especificar

sucintamente los escenarios de seguimiento comunes. Hay disponibles los perfiles siguientes:

P ERF IL DESC RIP C IÓ N

cpu-sampling Resulta útil para realizar el seguimiento del uso de CPU y la

información general del entorno de ejecución de .NET. Esta
es la opción predeterminada si no se especifica ningún
perfil o proveedor.

gc-verbose Realiza un seguimiento de las recolecciones de elementos

no utilizados y las asignaciones de objetos de ejemplo.

gc-collect Realiza un seguimiento de las recolecciones de elementos

no utilizados solo con una sobrecarga muy baja.

--providers <list-of-comma-separated-providers>

Lista separada por comas de proveedores de EventPipe que se van a habilitar. Estos proveedores
complementan a los proveedores implícitos en --profile <profile-name> . Si hay alguna incoherencia
para un proveedor determinado, esta configuración tiene prioridad sobre la configuración implícita del
perfil.
Esta lista de proveedores tiene el siguiente formato:
Provider[,Provider]
Provider tiene el formato: KnownProviderName[:Flags[:Level][:KeyValueArgs]] .
KeyValueArgs tiene el formato: [key1=value1][;key2=value2] .
-- <command> (solo para seleccionar como destino aplicaciones que ejecutan .NET 5.0)

Después de los parámetros de configuración de la colección, el usuario puede anexar -- seguido de

un comando para iniciar una aplicación de .NET con un entorno de ejecución de 5.0 como mínimo. Esto
puede resultar útil al diagnosticar problemas que se producen al principio del proceso, como
problemas de rendimiento de inicio o de cargador de ensamblados y errores del enlazador.

NOTE
El uso de esta opción supervisa el primer proceso de .NET 5.0 que se comunica con la herramienta, lo que
significa que, si el comando inicia varias aplicaciones de .NET, solo recopilará la primera. Por tanto, se
recomienda usar esta opción en aplicaciones independientes, o bien utilizar la opción dotnet exec <app.dll> .

dotnet-trace convert
Convierte los seguimientos de nettrace en formatos alternativos para usarlos con herramientas de análisis
de seguimiento alternativas.
Sinopsis
 dotnet-trace convert [<input-filename>] [--format <Chromium|NetTrace|Speedscope>] [-h|--help] [-o|--
output <output-filename>]

Argumentos
<input-filename>

Archivo de seguimiento de entrada que se va a convertir. El valor predeterminado es trace.nettrace.

Opciones
--format <Chromium|NetTrace|Speedscope>

Establece el formato de salida para la conversión del archivo de seguimiento.

-o|--output <output-filename>

Nombre de archivo de salida. Se agregará la extensión del formato de destino.

dotnet-trace ps
Enumera los procesos de dotnet de los que se pueden recopilar seguimientos.
Sinopsis

dotnet-trace ps [-h|--help]

dotnet-trace list-profiles
Muestra los perfiles de seguimiento pregenerados con una descripción de los proveedores y filtros que hay
en cada perfil.
Sinopsis

dotnet-trace list-profiles [-h|--help]

Recopilación de un seguimiento con dotnet-trace

Para recopilar seguimientos mediante dotnet-trace :
Averigüe el identificador de proceso (PID) de la aplicación .NET Core del que se van a recopilar
seguimientos.
En Windows, puede usar el administrador de tareas o el comando tasklist , por ejemplo.
En Linux, por ejemplo, el comando ps .
dotnet-trace ps
Ejecute el siguiente comando:

dotnet-trace collect --process-id <PID>

El comando anterior genera una salida similar a la siguiente:

 Press <Enter> to exit...
Connecting to process: <Full-Path-To-Process-Being-Profiled>/dotnet.exe
Collecting to file: <Full-Path-To-Trace>/trace.nettrace
Session Id: <SessionId>
Recording trace 721.025 (KB)

Detenga la recolección presionando la tecla <Enter> . dotnet-trace finalizará el registro de eventos en

el archivo trace.nettrace.

Inicio de una aplicación secundaria y recopilación de un

seguimiento de su inicio mediante dotnet-trace
IMPORTANT
Esto solo funciona para las aplicaciones que ejecutan .NET 5.0 o una versión posterior.

A veces puede resultar útil recopilar un seguimiento de un proceso desde su inicio. En el caso de las
aplicaciones que ejecutan .NET 5.0 o versiones posteriores, es posible hacerlo mediante dotnet-trace.
Esto iniciará hello.exe con arg1 y arg2 como argumentos de la línea de comandos y recopilará un
seguimiento de su inicio en tiempo de ejecución:

dotnet-trace collect -- hello.exe arg1 arg2

El comando anterior genera una salida similar a la siguiente:

No profile or providers specified, defaulting to trace profile 'cpu-sampling'

Provider Name Keywords Level Enabled By

Microsoft-DotNETCore-SampleProfiler 0x0000F00000000000 Informational(4) --profile
Microsoft-Windows-DotNETRuntime 0x00000014C14FCCBD Informational(4) --profile

Process : E:\temp\gcperfsim\bin\Debug\net5.0\gcperfsim.exe
Output File : E:\temp\gcperfsim\trace.nettrace

[00:00:00:05] Recording trace 122.244 (KB)

Press <Enter> or <Ctrl+C> to exit...

Para detener la recopilación del seguimiento, presione <Enter> o las teclas <Ctrl + C> . Si lo hace, también
saldrá de hello.exe .

NOTE
El inicio de hello.exe a través de dotnet-trace redirigirá su entrada o salida, y no podrá interactuar con su
stdin/stdout. La salida de la herramienta por medio de Ctrl + C o SIGTERM finalizará con seguridad la herramienta y el
proceso secundario. S