Antes de investigar un fallo de compilación X++, conviene comprobar si el pipeline llegó a compilar. Una dependencia rechazada durante la restauración puede detener el proceso mucho antes de que el compilador lea nuestros modelos.
Qué anunció Microsoft
The NuGet Team anunció el 23 de septiembre de 2026 una rotación del certificado con el que Microsoft firma sus paquetes NuGet, prevista a partir de esa fecha. El cambio interesa a quienes mantienen una lista de firmantes permitidos o verifican huellas explícitas con dotnet nuget verify. Microsoft indica que, sin esas restricciones, la instalación no debería verse afectada.
La corrección documentada consiste en añadir el certificado nuevo y conservar los anteriores. Omitirlo en una política restrictiva puede causar NU3034. Los paquetes antiguos mantienen sus firmas. Consulta el anuncio y procedimiento oficial de Microsoft.
Qué significa para D365FO
No implica que todos los builds D365FO necesiten cambios. La pregunta práctica es si las dependencias consumidas por ese pipeline y sus controles de confianza encajan en los escenarios descritos. Este artículo no confirma impacto sobre un paquete X++ concreto.
Primero, localizar la política
NuGet permite exigir paquetes firmados mediante signatureValidationMode=require y definir autores o repositorios de confianza en trustedSigners. Son controles diferentes: confiar en un repositorio no equivale a fijar la firma de un autor. La documentación de políticas de confianza explica estas opciones.
Revisa los archivos nuget.config y los scripts que pasan --certificate-fingerprint. El anuncio advierte que la configuración puede existir en varios ámbitos; revisar solo el archivo del repositorio puede ser insuficiente.
Cómo incorporar el certificado
Si existe una política afectada, compara la huella con la fuente oficial y agrega este elemento dentro del autor Microsoft existente en trustedSigners, sin sustituir sus certificados anteriores:
<certificate fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630" hashAlgorithm="SHA256" allowUntrustedRoot="false" />Es un elemento para integrar en una configuración existente, no un archivo nuget.config completo. Si la verificación está en un script, actualiza también su lista de huellas siguiendo el ejemplo del anuncio.
Prueba propuesta antes de integrar
- Crea una rama con el cambio y conserva la configuración anterior para comparar.
- Identifica el ejecutable NuGet o SDK y la configuración que utiliza realmente la tarea de restauración.
- Ejecuta una restauración en un agente de prueba con caché aislada, para evitar que una dependencia ya descargada oculte el problema.
- Comprueba paquetes representativos con firmas antiguas y nuevas. Registra cuáles verificaste.
- Confirma que un paquete no autorizado sigue siendo rechazado según la política definida.
- Ejecuta el build habitual y revisa el resultado antes de incorporar el cambio a la rama de releases.
Estos pasos son una propuesta de validación, no resultados de una prueba ejecutada. Ajusta el alcance al sistema operativo, cliente NuGet y feeds utilizados.
Qué evitar
No conviertas una rotación de certificado en una excepción permanente de seguridad. Desactivar la validación o ampliar indiscriminadamente la confianza puede esconder el síntoma y dejar un problema mayor. Tampoco incluyas credenciales de feeds en logs o capturas compartidas.
Si no hay una política afectada, registra la comprobación y continúa. No hace falta modificar un pipeline estable por el solo hecho de consumir NuGet. Si sí la hay, trata la actualización como un cambio pequeño, revisable y probado.