Pointeurs utilisant une DLL 32 bits dans un service 64 bits

Question

Jusqu'à récemment, nous utilisions un service en tant que x86, mais nous l'avons remplacé par Tout processeur à utiliser pour introduire de nouvelles fonctionnalités en utilisant une DLL 64 bits. L'une des DLL tierces restantes était 32 bits. J'ai installé un substitut de DLL pour cela dans le registre, mais ce n'est que la moitié de la solution.

Je soupçonne que le pointeur en mémoire n'est pas accessible car il n'est plus exécuté dansProc. Ce que je dois savoir, c'est comment utiliser l'objet System.Runtime.InteropServices.Marshall pour avoir accès au pointeur retourné.

Merci d'avance.

public Image GetThumbnail(string strFilename) 
    { 
     SeThumbnailExtractor objExtractor = new SeThumbnailExtractor(); 
     int hImageSE; 
     Image objImage = null; 
     try 
     { 
      objExtractor.GetThumbnail(strFilename, out hImageSE); 
      IntPtr iPImage = new IntPtr(hImageSE); 
      //fails below 
      objImage = Image.FromHbitmap(iPImage); 
      _ReturnedImage = objImage; 
      _SourceFile = strFilename; 
      Marshal.FreeHGlobal(iPImage); 
     } 
     catch (Exception ex) 
     { 
      _ErrorMsg = "ERROR: " + ex.Message.ToString(); 
     } 

     if (objExtractor != null) 
     { 
      System.Runtime.InteropServices.Marshal.ReleaseComObject(objExtractor); 
      objExtractor = null; 
     } 

     return objImage; 
    } 

Answer 1

L'exécution dans un substitut est complètement transparente pour un composant COM correctement implémenté. Le proxy/stub du composant garantit que les arguments et les valeurs de retour des méthodes d'interface sont correctement sérialisés par le proxy dans un paquet de données interopérables afin qu'il puisse être transmis à travers la division de processus et désérialisé à nouveau dans le stub.

"Correctement mis en œuvre" est cependant le frotter. Si vous obtenez un handle ou un pointeur de bitmap brut à partir d'une méthode COM, cela provoque des problèmes. Un handle ou un pointeur ne peut pas être sérialisé, il n'est valide que dans le processus qui l'a créé. Un proxy/stub personnalisé est requis pour substituer ce handle aux données bitmap réelles, transmet ces données au talon afin que le bitmap puisse être recréé avec un nouveau handle/pointeur dans un processus 64 bits. Les chances que l'auteur du composant COM a prises en compte sont faibles, ce n'est pas facile à faire et il n'a sûrement pas vu l'exigence à ce moment puisqu'il a supposé que le composant serait toujours utilisé en cours de processus. Ce n'est plus.

Il n'y a pas de solution simple pour cela, vous devez créer un proxy/stub approprié et cela nécessite d'avoir au moins accès à l'IDL d'origine pour le composant. Habituellement, seul l'auteur de COM a accès à cela. Mauvaises nouvelles, j'en suis sûr.

Une solution de contournement possible consiste à laisser le soin à .NET de s'en occuper. Vous aurez besoin d'un processus d'assistance Littler qui s'exécute en mode 32 bits, ce qui permet de charger le composant COM sans problème. Parlez-lui avec l'un des mécanismes d'interopérabilité .NET, comme WCF ou Remoting. Obtenir le bitmap sérialisé est maintenant entièrement entre vos mains.