2009-04-05 7 views
5

Nous avons un Vista particulier la machine x64 qui, lors de l'exécution de notre application C# WinForms, affiche l'erreur suivante:Impossible de trouver un point d'entrée nommé 'TaskDialogIndirect' dans 'comctl32' DLL

System.EntryPointNotFoundException: Unable to find an entry point named 'TaskDialogIndirect' in DLL 'ComCtl32'.

Ce même code fonctionne bien sur d'autres machines Vista. Pour une raison quelconque, cette machine particulière de Vista jette toujours cette exception.

Comment pouvons-nous résoudre ce problème?

Répondre

7

J'ai eu des problèmes avec ceci et XTaskDialog API libre de Naughter, pour obtenir un mécanisme de repli sur des machines de Windows XP par émulation, rendant cette implémentation de dialogue beaucoup plus utile. :)

Dans mon cas c'était un problème de contexte d'activation, comme mentionné dans ce blog entry.

Ou, cité ici, dans le cas où le billet de blog est perdu dans le cyberespace un jour (s'applique à Visual Studio):

  1. Ouvrez les propriétés du projet dans l'Explorateur de solutions
  2. Dans l'onglet Sécurité, cochez la case Activer ClickOnce Paramètres de sécurité,
  3. maintenant vous pouvez voir apparaître le fichier app.manifest dans le dossier Propriétés de votre solution, ouvrez-le,
  4. Sous l'étiquette </trustInfo >, insérez le code ci-dessous.
  5. Si vous essayez de construire, il peut y avoir une erreur. Pour le réparer, décochez la case Activer les paramètres de sécurité ClickOnce.

Le code à insérer dans l'étape 4:

<dependency> 
    <dependentAssembly> 
    <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" 
     version="6.0.0.0" processorArchitecture="*" 
     publicKeyToken="6595b64144ccf1df" language="*" /> 
    </dependentAssembly> 
</dependency> 
+0

Merci, nous allons essayer. –

+0

J'ai le même problème dans un projet de bibliothèque DLL (plugin Excel). Il n'y a pas d'onglet de sécurité dans VS studio pour les projets de bibliothèque? –

+1

Actuellement (VS 2012/2013) cette solution ne fonctionne pas :(Cela fonctionne cependant comme un charme: http://support.microsoft.com/kb/830033 –

1

Je suggère de comparer la version de comctl32.dll sur les ordinateurs Vista fonctionnant et ne fonctionnant pas - et de comparer leurs sommes de contrôle même s'ils rapportent la même version.

Autres choses à vérifier:

  • Est-il possible que la machine non-travail a une pré-version de Vista?
  • Est-il possible qu'une version non-Vista de comctl32.dll ait été copiée sur la machine et qu'elle soit récupérée par l'application? (L'utilitaire Depends fourni avec Visual Studio peut vous aider ici.)
  • Est-il possible qu'un virus ou un ver (ou quoi d'autre) ait remplacé comctl32.dll?

Il peut également être utile de lire ce article sur les contextes d'activation.

+0

Merci, nous allons jeter un oeil à ce sujet. Si cela nous amène à la réponse, j'accepterai votre réponse comme correcte. –

1

Si les autres machines utilisées pour exécuter le programme utilisaient Vista x86, il est probable qu'un code PInvoke soit à l'origine du problème. Vous pouvez essayer de définir l'architecture cible du compilateur sur x86 pour forcer votre programme à s'exécuter dans WoW64 sur le x64 Vista. Par défaut, Visual Studio utilise des paramètres créant des assemblys de manière indépendante de l'architecture. Cela signifie que lorsque vous essayez d'exécuter un programme .NET sur un système 64 bits, il doit être hébergé par une version x64 native du CLR. Attemptiong pour charger une DLL 32 bits dans ce contexte échouera. Forcer l'application à fonctionner en mode émulé x86, à la place, devrait faire l'affaire.

+0

Merci, mais nous avons déjà défini l'application pour compiler en tant que x86, car nous utilisons des composants qui ne sont pas prêts pour x64. –

Questions connexes