Este team de expertos pasados varios días de trabajo y de juntar de datos, han obtenido los datos necesarios, esperamos que resulte de gran utilidad para tu trabajo.
Solución:
De hecho, hay un mecanismo incorporado solo para estos diagnósticos.
(1) En las propiedades/depuración de su proyecto, asegúrese de que esté marcada la opción “Habilitar depuración de código nativo”:
(2) Levante la bandera show-loader-snaps – es un registro key en IFEO, y es accesible a través de la GUI ‘GlobalFlags’:
(3) Ejecute la aplicación desde un depurador o adjúntela antes del error de carga. Inspeccione el (muy) panel de salida detallada. En su mayoría, puede saltar hasta el final o buscar ‘ERROR’.
Más detalles aquí.
¿Estás haciendo alguna importación dll? – ¿Esto parece un problema con un dll no administrado que no se encuentra?
Lo primero es asegurarse de que cualquier dll o exe no administrado al que esté llamando (a través de dllimport) se implemente en la misma carpeta que el .Net exe que está creando
Si la fuente del ensamblado que llama no está disponible, puede intentar usar reflector en ese ensamblado para buscar declaraciones dllimport
Aparte de eso, es posible que desee habilitar el visor de registros de fusión para rastrear los problemas de carga del ensamblaje; consulte esta publicación de blog y la página de msdn para obtener más detalles.
Implemente un controlador para el evento AppDomain.AssemblyResolve. Le dice qué ensamblaje está buscando con ResolveEventArgs.Name. Si esto es solo un esfuerzo para solucionar este ensamblaje en particular, use Fuslogvw.exe. Si el bloqueo es un ensamblado no administrado, la opción Perfil de DependencyWalker puede mostrarle qué llamada LoadLibrary() está fallando. ProcMon de SysInternals también funcionará, pero es mucho más ruidoso.