2010-05-14 3 views
0

J'ai une application C# qui doit utiliser une ancienne DLL Win32. La DLL est presque sa propre application, il a des boîtes de dialogue, les opérations avec le matériel, etc. Lorsque cette DLL est importé et utilisé, il y a quelques problèmes qui se produisent:Comment protéger une DLL Win32 importée dans une application .NET à partir de problèmes de mémoire

  1. Faire glisser une boîte de dialogue (pas un système Windows boîte de dialogue, mais un créé par la DLL) à travers l'application de code managé provoque l'interface utilisateur ne pas redessiner. En outre, il génère un système sur exception de la mémoire de diverses commandes UI . La performance est incroyablement lente.
  2. Il semble impossible de décharger la DLL de sorte que la mémoire jamais soit nettoyée. Lorsque nous fermons notre application gérée , nous obtenons une autre exception de mémoire.

Actuellement, nous importons chaque appel de méthode en tant que telle:

[DllImport("dllname.dll", 
    EntryPoint = "MethodName", SetLastError = true, 
    CharSet = CharSet.Auto, ExactSpelling = true, 
    CallingConvention = CallingConvention.StdCall)] 
+0

Je suppose que vous avez testé l'appel de la DLL à partir de code non géré, et qu'il se comporte correctement? – egrunin

+0

Oui, la version antérieure de ce que nous avons remplacé par du code managé n'était pas gérée. – Eric

Répondre

1

Je voudrais créer une enveloppe exe (éventuellement non géré) qui expose une API pour votre nouvelle application à utiliser.

Une autre solution possible consiste à créer un deuxième thread d'interface utilisateur qui gère uniquement la DLL problématique. Je me penche davantage sur le wrapper exe, car cette approche traite plus facilement le MOO (vous pouvez redémarrer le processus si nécessaire).

+0

J'ai considéré le wrapper exe, mais la DLL non managée doit être appelée dans le même processus que l'application gérée. – Eric

+0

Pourquoi pas dans le même processus? - les utilisateurs ne sauront pas si c'est le cas – Mark

+0

@Mark: les wrappers exe sont utiles lorsque vous avez un composant bogué hors de votre contrôle qui bloque tout le processus (par exemple, avec MOO). Redémarrer un sous-processus en cas de panne n'est pas trop difficile; Je devais le faire il y a quelques années avec une DLL client Oracle qui bloquait constamment notre système d'automatisation d'usine 24x7. Les utilisateurs ne voient aucune différence mais cela fait une grande différence pour le système d'exploitation (un exe différent a son propre espace mémoire, et ne plante pas l'exe parent). –

Questions connexes