Trampas del Store #4: El trimming de .NET eliminó los bindings de WinUI 3
2026-05-31
Tags: Windows · Microsoft Store · Trampas del Store
Este problema lo encontré en una etapa muy temprana. Mientras escribía la serie Trampas del Store, encontré un correo de rechazo antiguo — espero que este artículo sirva como referencia para los desarrolladores que se inician en el proceso de publicación de WinUI 3 / .NET.
Qué pasó
Mi aplicación WinUI 3 se envió para la certificación del Microsoft Store. El informe de certificación llegó:
Status: Attention needed
10.1.2.10 Functionality
Unusable Feature: "Download to local cache", "Open File" - The product fails to download copied items to local cache and "Open File" button in the product is not usable
Espera — yo había probado localmente, y tanto «Download to local cache» como «Open File» funcionaban correctamente. ¿Por qué no funcionaban en la máquina de pruebas de Microsoft?
Investigación
La diferencia más sospechosa: yo usaba un build Debug localmente, mientras que el envío al Store era un build Release. Al revisar el archivo .csproj, encontré una diferencia clave entre las configuraciones Debug y Release:
<!-- Debug -->
<PublishTrimmed>False</PublishTrimmed>
<!-- Release -->
<PublishTrimmed Condition="'$(Configuration)' != 'Debug'">True</PublishTrimmed>El build Release tenía el trimming de .NET activado.
Qué es el trimming de .NET
El trimming de .NET es una función de optimización del SDK de .NET. Al publicar la aplicación, el trimmer realiza un análisis estático para identificar los ensamblados, tipos y métodos que nunca se referencian directamente en el código, y luego los elimina para reducir el tamaño de la aplicación.
El problema: el trimmer solo ve las referencias estáticas. Si el código accede a un tipo mediante reflexión en tiempo de ejecución, pero no existe ninguna referencia estática en tiempo de compilación, el trimmer considera que el tipo está «sin usar» y lo elimina.
Por qué WinUI 3 es especialmente vulnerable
WinUI 3 y su capa de interoperabilidad WinRT subyacente dependen en gran medida de la reflexión y las características dinámicas. Los {Binding} tradicionales, los convertidores de valor y la reflexión de metadatos de interoperabilidad WinRT producen llamadas en tiempo de ejecución que el análisis estático del trimmer no puede rastrear. Cuando el trimmer elimina los modelos de datos, comandos, convertidores y otros tipos que los bindings necesitan, tratándolos como «sin usar», los bindings no pueden encontrar sus objetivos en tiempo de ejecución — los botones dejan de funcionar, el texto deja de actualizarse. Sin errores, sin cierres, las cosas simplemente dejan de funcionar silenciosamente.
Solución
El método más directo: desactivar el trimming en el .csproj:
- <PublishTrimmed Condition="'$(Configuration)' != 'Debug'">True</PublishTrimmed>
+ <PublishTrimmed>False</PublishTrimmed>Volver a empaquetar y enviar — la certificación pasó.
Si realmente necesitas el trimming para reducir el tamaño del paquete, también puedes hacerlo compatible:
- Aplicar los atributos
[DynamicDependency]o[DynamicallyAccessedMembers]en los tipos necesarios para indicar al trimmer que los conserve - Configurar
<TrimmerRootAssembly>en el.csprojpara conservar un ensamblado completo
Pero para la mayoría de las aplicaciones WinUI 3, simplemente desactivar el trimming es la opción más sencilla.
En resumen
- El trimming de .NET elimina el código que considera «sin usar», pero no puede identificar las llamadas reflexivas
- Los bindings de datos de WinUI 3 dependen de la reflexión y se eliminan fácilmente por error
- Si una aplicación WinUI 3 muestra «funciones no utilizables» en la certificación del Store pero funciona correctamente en local, lo primero que debes revisar es el trimming
- Los builds Debug no usan trimming por defecto, los builds Release pueden activarlo — prueba siempre el build Release/Publish antes de enviar al Store
- Próximamente publicaremos un artículo con consejos de pruebas antes de enviar al Store — estén atentos
Parte de la serie Trampas del Store.