Después de años trabajando con plugins de Dataverse, hay errores que veo repetirse una y otra vez. Esta lección es un compendio de los problemas más frecuentes, sus causas, y cómo resolverlos.
Objetivos de aprendizaje
- Identificar rápidamente errores comunes de plugins
- Aplicar patrones de troubleshooting sistemático
- Conocer las herramientas de diagnóstico disponibles
- Prevenir problemas en el diseño inicial
Errores de registro y configuración
"Assembly must be signed with a strong name"
Causa: El DLL no está firmado. Dataverse requiere strong-name signing para todos los assemblies de plugins.
Solución:
- En Visual Studio: Proyecto → Properties → Signing
- Marca "Sign the assembly"
- Crea un nuevo archivo .snk o selecciona uno existente
- Recompila
Si usas el template de Power Platform Tools, esto viene configurado por defecto.
"Could not load type" o "Could not load assembly"
Causas posibles:
- Dependencia faltante que no está en el GAC del sandbox
- Versión incorrecta del SDK
- .NET Framework target incorrecto
Soluciones:
- Usa .NET Framework 4.6.2 o superior
- Las únicas dependencias permitidas son las del SDK y las que traes embebidas
- Para incluir dependencias, usa ILMerge o ILRepack para combinar todo en un solo DLL
"Plug-in class not found"
Causa: El nombre completo de la clase (namespace + nombre) no coincide con lo registrado.
Solución:
- Verifica que no renombraste la clase o el namespace después de registrar el step
- Si renombraste, elimina el step y regístralo de nuevo
Errores de ejecución
"This workflow job was canceled because the workflow that started it included an infinite loop"
Causa: El plugin dispara una operación que a su vez dispara el mismo plugin, creando un loop infinito.
Ejemplo típico: Plugin en Update de Account que actualiza el mismo Account.
Solución: Verifica context.Depth antes de ejecutar lógica que puede disparar el mismo plugin:
var context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
if (context.Depth > 1)
{
trace.Trace("Ejecución anidada detectada, saliendo");
return;
}
// Tu lógica aquí
Otra opción más selectiva es verificar qué campos modificaste y si son los mismos que disparan el plugin.
"SQL Server Timeout" o "The operation has timed out"
Causa: El plugin tarda más de 2 minutos (síncrono) o hace operaciones muy pesadas.
Soluciones:
- Optimiza consultas: usa TopCount, limita ColumnSet
- Pagina resultados grandes en lugar de traerlos todos
- Para operaciones lentas, usa plugins asíncronos
- Para llamadas HTTP, configura timeouts razonables (30 segundos, no ilimitado)
// MAL: Trae todos los campos de todas las cuentas
QueryExpression query = new QueryExpression("account");
query.ColumnSet = new ColumnSet(true);
// BIEN: Solo lo que necesitas
query.ColumnSet = new ColumnSet("name", "accountnumber");
query.TopCount = 50;
"Sandbox restriction" o "Partially trusted code"
Causa: El plugin intenta hacer algo que el sandbox no permite:
- Acceso al sistema de archivos
- Llamadas HTTP (en lugar de HTTPS)
- Reflection sobre tipos no permitidos
- Uso de puertos no estándar
Solución: Revisa qué operación específica causa el error. Para integraciones complejas, considera usar Azure Functions como intermediario.
Errores de lógica
El plugin no se ejecuta
Checklist de verificación:
- ¿El step está habilitado? (Verifica en PRT)
- ¿El mensaje es correcto? (Create, Update, Delete...)
- ¿La entidad primaria es correcta?
- ¿El stage es el esperado?
- ¿Los Filtering Attributes incluyen el campo que modificas? (Para Update)
- ¿Hay errores silenciosos en el catch que ocultan excepciones?
Entity Images vacías o nulas
Causa: Las imágenes no están configuradas correctamente o pides Pre-Image en Create.
Recuerda:
- Pre-Image en Create: no existe (el registro aún no existe)
- Post-Image en Delete: no existe (el registro ya no existirá)
- El alias debe coincidir exactamente con lo registrado
- Los atributos solicitados deben incluir los campos que necesitas
Cambios no se guardan
Causa común: Modificas el Target pero el sistema no ve los cambios porque lo hiciste mal o en el stage incorrecto.
En Pre-operation, modifica directamente el Target de InputParameters:
// En Pre-operation
Entity target = (Entity)context.InputParameters["Target"];
target["calculatedfield"] = nuevovalor;
// No necesitas service.Update(), los cambios van en la misma transacción
En Post-operation, el registro ya se guardó. Necesitas Update explícito:
// En Post-operation
Entity actualizacion = new Entity(context.PrimaryEntityName, context.PrimaryEntityId);
actualizacion["calculatedfield"] = nuevovalor;
service.Update(actualizacion); // Necesario en Post-operation
Herramientas de diagnóstico
Plugin Trace Log: La primera herramienta a consultar. Muestra las trazas de ITracingService y errores.
Plugin Profiler: Para reproducir ejecuciones y depurar paso a paso.
XrmToolBox: Tiene herramientas para consultar datos, ver metadatos, y analizar configuración.
Fiddler: Para capturar tráfico HTTP y ver qué llamadas hace tu plugin a servicios externos.
Solution Checker: Análisis estático que detecta problemas antes de desplegar (en Power Apps maker portal).
Checklist general de troubleshooting
- ¿El step está registrado y habilitado?
- ¿Hay excepciones en Plugin Trace Log?
- ¿Las trazas llegan al punto esperado?
- ¿Los InputParameters tienen los datos esperados?
- ¿Las Entity Images están configuradas?
- ¿Hay loops infinitos? (Verifica Depth)
- ¿El código tiene try-catch que ocultan errores?
- ¿Las dependencias están incluidas en el assembly?
Puntos clave
- Firma siempre los assemblies con strong name
- Verifica Depth para evitar loops infinitos
- Usa ITracingService generosamente para diagnóstico
- Pre-Image no existe en Create, Post-Image no existe en Delete
- En Pre-operation modifica el Target, en Post-operation usa Update
- Plugin Trace Log es tu primera herramienta de diagnóstico