Cambio de oleadas
Una oleada de cambios es un conjunto de cambios de comportamiento en MSBuild que puede optar por no recibir especificando una marca concreta como variable de entorno. La finalidad de ello es avisarle de cambios potencialmente perjudiciales para que disponga de la flexibilidad de adaptarse a estos antes de que se conviertan en una funcionalidad estándar. Todas las características de una oleada de cambios concreta solo se pueden habilitar o deshabilitar juntas, no de forma individual.
Al actualizar a una nueva versión de MSBuild, se permiten de forma predeterminada cambios que son potencialmente problemáticos, pero si una característica afecta de forma negativa a la compilación, puede deshabilitar fácilmente esa oleada de cambios. Cada oleada de cambios se identifica mediante un número de versión de MSBuild (por ejemplo, 16.8), pero el establecimiento de la oleada de cambios solo controla determinadas características que pueden afectar al proceso de compilación, no todos los cambios de esa versión de MSBuild. Más adelante en este artículo se muestra una lista de las características de cada oleada de cambios. Al deshabilitar una oleada de cambios, también se deshabilitan las oleadas de cambios de versiones superiores.
Optar por no recibir las características de una oleada de cambios
Para deshabilitar las características de una oleada de cambios, establezca la variable de entorno MSBuildDisableFeaturesFromVersion
en la oleada de cambios (o versión de MSBuild) que contiene la característica que quiere que se deshabilite. Esta es la versión de MSBuild para la que se desarrollaron las características. Consulte la asignación de oleadas de cambios a las características siguientes.
Valores de MSBuildDisableFeaturesFromVersion
Si no establece MSBuildDisableFeaturesFromVersion
en una oleada de cambios válida, recibirá una advertencia o se establecerá de forma predeterminada una oleada concreta. En la tabla siguiente se muestran los posibles valores:
Valor de MSBuildDisableFeaturesFromVersion |
Resultado | ¿Recibir advertencia? |
---|---|---|
Anular | Se habilitan todas las oleadas de cambios, lo que significa que todas las características que hay detrás de cada oleada de cambios están habilitadas. | No |
Cualquier oleada de cambios válida y actual (por ejemplo, 16.8 ) |
Se deshabilitan todas las características que hay detrás de una oleada de cambios 16.8 y posteriores. |
No |
Valor no válido (por ejemplo, 16.9 cuando las oleadas válidas son 16.8 y 16.10 ) |
Toma de forma predeterminada el valor válido más cercano (ascendente). Por ejemplo, al establecer 16.9 , se toma como predeterminado 16.10 . |
No |
Fuera de rotación (por ejemplo, 17.1 cuando la oleada más alta es la 17.0 ) |
Se fija en el valor válido más cercano. Por ejemplo, 17.1 se fija en 17.0 y 16.5 en 16.8 . |
Sí |
Formato no válido (por ejemplo, 16x8 , 17_0 , garbage ) |
Se habilitan todas las oleadas de cambios, lo que significa que todas las características que hay detrás de cada oleada de cambios están habilitadas. | Sí |
Oleadas de cambios y características asociadas
17.10
- La configuración de AppDomain se serializa sin usar BinFmt: la característica solo se puede optar por no recibir si BinaryFormatter está permitido en tiempo de ejecución editando
MSBuild.runtimeconfig.json
- Procesamiento de datos de resolución del SDK de caché en todo el mundo
17.8
- [RAR] No hacer E/S en referencias proporcionadas por el SDK
- Eliminación del archivo de destino antes de copiar
- Pasar de SHA1 a SHA256 para la tarea Hash
- Dejar de usar BuildEventArgs derivado personalizado: la característica solo se puede optar por no recibir si BinaryFormatter está permitido en tiempo de ejecución editando
MSBuild.runtimeconfig.json
17.6
- Análisis de la propiedad no válida en el destino
- Eliminación de la caché de cadenas de proyecto
- Registrar un error cuando no existe ninguna ruta de búsqueda proporcionada para una importación
- Cargas de ensamblados de registro
- AnyHaveMetadataValue devuelve false cuando se pasa una lista vacía
- Autoexpansión del elemento de registro
17.4
- Respetar deps.json al cargar ensamblados
- Considere
Platform
como valor predeterminado durante la negociación de la plataforma - Adición del patrón de coincidencia del nombre del SDK aceptado a los manifiestos del SDK
- Advertencia de inicio que indica tipos de proyecto no válidos
- Servidor de MSBuild
- Llamada a la nueva API de CultureInfo al validar referencias culturales (solo .NET Core)
17.0
- Scheduler debe respetar BuildParameters.DisableInprocNode
- No compile expresiones regulares de globbing en .NET Framework
- Valor predeterminado para copiar elementos de contenido de forma transitiva
- Los ensamblados de referencia ya no se colocan en el directorio
bin
de forma predeterminada (se revierten aquí y se devuelven aquí) - Mejora de la experiencia de depuración: agregar conmutador global MSBuildDebugEngine; Insertar registrador binario desde BuildManager; imprimir gráfico estático como archivo .dot
- Corrección del interbloqueo en BuildManager frente a LoggingService
- Optimizar el nivel de diag para el registrador de archivos y el registrador de consola
- Comprobaciones actualizadas de archivos inmutables optimizados
- Agregar Microsoft.IO.Redist para la enumeración de directorios
- Almacenamiento en caché para todo el proceso de ToolsetConfigurationSection
- Normalizar las rutas de salida de RAR
Las ondas de cambio ya no están en rotación
16.8
- Habilitación de NoWarn
- Truncamiento de los mensajes de registro omitidos de destino/tarea a 1024 caracteres
- No expandir los globs de unidad completa con una condición falsa
16.10
- Error cuando la expansión de una propiedad en una condición tiene un espacio en blanco
- Permitir la ubicación personalizada de CopyToOutputDirectory con TargetPath
- Permitir que los usuarios que tengan determinados caracteres especiales en su nombre de usuario se compilen correctamente al usar exec
- Operaciones de restauración por error cuando un SDK no se puede deshacer
- Optimizar la evaluación global
Preguntas más frecuentes
¿Por qué se dejan fuera de la rotación las demás versiones de las oleadas de cambios?
Creemos que hay que dar tiempo suficiente para entablar conversaciones con los afectados y ayudarles a adaptarse a los cambios.
¿Por qué una variable de entorno y no una propiedad de proyecto?
Hay escenarios en los que queremos colocar una característica en una oleada de cambios antes de que MSBuild haya cargado el proyecto. Por ese motivo, las oleadas de cambios requieren el uso de variables de entorno.
¿Por qué es mejor optar por no recibir que optar por recibir?
Para nosotros es mejor optar por no recibir, si no, es probable que recibamos información limitada cuando una característica afecte a las compilaciones de un cliente.