Erreur de .NET Assembly non trouvé depuis le contrôle utilisateur

Question

Je rencontre un problème où mon contrôle utilisateur ne trouve pas une assembly spécifique référencée au moment de l'exécution.

Je récupère les assemblies référencées au moment de l'exécution à partir des ressources intégrées, mais c'est la seule assembly que le contrôle utilisateur recherche avant de pouvoir être extraite, donc elle ne peut pas la trouver.

Pourquoi l'application n'attend-elle pas que l'instance de l'assembly soit créée pour la rechercher ?

J'essaie de comprendre. Pourquoi cette assembly est-elle catégorisée comme "pré-liée" ?

Log de fusion ci-dessous

*** Entrée de journal de liaison d'assembly (15/08/2012 @ 8:55:28) ***

    L'opération a échoué.
    Résultat de liaison : hr = 0x80070002. Le système ne peut pas trouver le fichier spécifié.

    Gestionnaire d'assembly chargé depuis :  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Exécuté avec le fichier exécutable  C:\Temp\gn\WPFDemo\bin\Debug\WPFDemo.exe
    --- Un journal d'erreurs détaillé suit.

    === Informations de l'état de pré-association ===
    LOG : Utilisateur = xxxx
    LOG : Nom d'affichage = AVX.NET, Version=1.2.0.1551, Culture=neutral, PublicKeyToken=4300bc540bfb680e
     (Entièrement spécifié)
    LOG : Appbase = file:///C:/Temp/gn/WPFDemo/bin/Debug/
    LOG : PrivatePath initial = NULL
    LOG : Base dynamique = NULL
    LOG : Base de cache = NULL
    LOG : Nom de l'application = WPFDemo.exe
    Assembly appelante : Test, Version=1.0.6.39680, Culture=neutral, PublicKeyToken=4300bc540bfb680e.
    ===
    LOG : Cette liaison démarre dans le contexte de chargement par défaut.
    LOG : Utilisation du fichier de configuration d'application : C:\Temp\gn\WPFDemo\bin\Debug\WPFDemo.exe.Config
    LOG : Utilisation du fichier de configuration d'hôte : 
    LOG : Utilisation du fichier de configuration machine depuis C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG : Référence post-stratégie : AVX.NET, Version=1.2.0.1551, Culture=neutral, PublicKeyToken=4300bc540bfb680e
    LOG : La recherche GAC a échoué.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET.DLL.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET/AVX.NET.DLL.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET.EXE.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET/AVX.NET.EXE.
    LOG : Toutes les URL de recherche ont été tentées et ont échoué.

    *** Entrée de journal de liaison d'assembly (15/08/2012 @ 8:55:28) ***

    L'opération a échoué.
    Résultat de liaison : hr = 0x80070002. Le système ne peut pas trouver le fichier spécifié.

    Gestionnaire d'assembly chargé depuis :  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Exécuté avec le fichier exécutable  C:\Temp\gn\WPFDemo\bin/Debug\WPFDemo.exe
    --- Un journal d'erreurs détaillé suit. 

    === Informations de l'état de pré-association ===
    LOG : Utilisateur = xxxx
    LOG : Nom d'affichage = AVX.NET, Version=1.2.0.1551, Culture=neutral, PublicKeyToken=4300bc540bfb680e
     (Entièrement spécifié)
    LOG : Appbase = file:///C:/Temp/gn/WPFDemo/bin/Debug/
    LOG : PrivatePath initial = NULL
    LOG : Base dynamique = NULL
    LOG : Base de cache = NULL
    LOG : Nom de l'application = WPFDemo.exe
    Assembly appelante : Test, Version=1.0.6.39680, Culture=neutral, PublicKeyToken=4300bc540bfb680e.
    ===
    LOG : Cette liaison démarre dans le contexte de chargement par défaut.
    LOG : Utilisation du fichier de configuration d'application : C:\Temp\gn\WPFDemo\bin/Debug\WPFDemo.exe.Config
    LOG : Utilisation du fichier de configuration d'hôte : 
    LOG : Utilisation du fichier de configuration machine depuis C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG : Référence post-stratégie : AVX.NET, Version=1.2.0.1551, Culture=neutral, PublicKeyToken=4300bc540bfb680e
    LOG : La recherche GAC a échoué.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET.DLL.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET/AVX.NET.DLL.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET.EXE.
    LOG : Tentative de téléchargement de l'URL de fichier :///C:/Temp/gn/WPFDemo/bin/Debug/AVX.NET/AVX.NET.EXE.
    LOG : Toutes les URL de recherche ont été tentées et ont échoué.

Answer 1

Il existe quelques déclencheurs pour que le CLR charge une assembly. Au-delà des appels explicites Assembly.LoadXxx(), de loin le plus courant est le compilateur juste-à-temps. Qui a besoin de l'assembly pour générer correctement le code pour une méthode, avant que cette méthode s'exécute.

Donc, si vous avez du code qui utilise un type issu d'une telle assembly et que ce code est "proche" du code que vous avez qui extrait le DLL, il est probable que vous obteniez ce résultat. Le compilateur peut bien avoir besoin de l'assembly avant que votre code d'extraction puisse s'exécuter.

Vous devez particulièrement faire attention à l'optimisation d'inlining réalisée par l'optimiseur du compilateur, activée dans la build Release sans un débogueur attaché. Maintenant, "proche" s'étend au-delà du corps de la méthode. Pour éviter que cela se produise, toute méthode appelée depuis la méthode qui exécute le code d'extraction du DLL doit être décorée de [MethodImpl(MethodImplOptions.Noinlining)].

Vous pourriez probablement rencontrer un autre problème avec cette approche. On dirait que vous n'avez pas écrit de gestionnaire d'événement personnalisé AppDomain.AssemblyResolve. Ou il n'est peut-être pas encore enregistré. Vous ne pouvez pas extraire les DLL dans le même répertoire que l'EXE sur les versions récentes de Windows, UAC l'empêche. L'extraction dans un répertoire inscriptible est requise. Disons le répertoire TEMP. Ce qui nécessite ensuite un gestionnaire de résolution personnalisé d'assemblage. Les scanners de virus deviennent nerveux lorsque des fichiers exécutables apparaissent de nulle part, un autre mode de défaillance possible hautement aléatoire et totalement indiagnostiquable.

Évitez ce genre de problèmes avec le moyen le plus courant de déployer un exécutable unique. Un appelé setup.exe et créé par, disons, un projet de configuration. Facile à faire dans VS.