Oleadas de cambios
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. El propósito de esto es advertirle de cambios potencialmente perjudiciales para que tenga flexibilidad para adaptarse a estos cambios antes de convertirse en funcionalidad estándar. Todas las características de una oleada de cambios específica solo se pueden habilitar o deshabilitar juntas, no individualmente.
Al actualizar a una nueva versión de MSBuild, los cambios potencialmente disruptivos se habilitan de forma predeterminada, pero si una funcionalidad afecta negativamente a la compilación, puede deshabilitar fácilmente ese conjunto de cambios. Cada oleada de cambios se identifica mediante un número de versión de MSBuild (por ejemplo, 16.8), pero establecer la oleada de cambios solo controla determinadas características que tienen el potencial de afectar al proceso de compilación, no todos los cambios en esa versión de MSBuild. Aparece una lista de las características de cada oleada de cambios más adelante en este artículo. 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 desea deshabilitado. 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 valores posibles:
Valor de MSBuildDisableFeaturesFromVersion |
Resultado | ¿Recibe una advertencia? |
|---|---|---|
| Anular | Habilite todas las oleadas de cambios, lo que significa que todas las características 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.8y posteriores. |
No |
Valor no válido (por ejemplo, 16.9 cuando las ondas válidas se 16.8 y 16.10) |
Utiliza como valor predeterminado 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 onda más alta es 17.0) |
Se fija en el valor válido más cercano. Por ejemplo, 17.1 se sujeta a 17.0y 16.5 se sujeta a 16.8 |
Sí |
Formato no válido (por ejemplo, 16x8, 17_0, garbage) |
Habilite todas las oleadas de cambios, lo que significa que todas las características 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
- Eliminar archivo de destino antes de copiar
- cambio de SHA1 a SHA256 para la tarea de 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
- considerar
Platformcomo 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
- Lanzar advertencia que indica tipos de proyecto no válidos
- Servidor de MSBuild
- Llamar a la nueva API CultureInfo al validar culturas (solo .NET Core)
17.0
- Scheduler debe respetar BuildParameters.DisableInprocNode
- No compile expresiones regulares de globbing en .NET Framework
- valor predeterminado para copiar de forma transitiva los elementos de contenido
- Ahora, los ensamblados de referencia ya no se colocan en el directorio
binpor defecto (revertido aquí y restablecido 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 rutas de salida de RAR
Las ondas de cambio ya no están en rotación
16.8
- Habilitar 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 ubicación personalizada de CopyToOutputDirectory con TargetPath
- Permitir que los usuarios que tengan determinados caracteres especiales en su nombre de usuario realicen compilaciones correctamente al usar exec
- Las operaciones de restauración fallan cuando un SDK no se puede resolver
- 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 esto es suficiente para discutir con los afectados y ayudar 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.