views:

890

answers:

3

We have a particular Vista x64 machine that, when running our C# WinForms app, displays the following error:

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

This same code works fine on other Vista machines. For some reason, this particular Vista machine always throws this exception.

How can we fix this?

+1  A: 

I would suggest comparing the version of comctl32.dll on the working and non-working Vista machines -- and comparing their checksums even if they report the same version.

Other things to check:

  • Is it possible that the non-working machine has a pre-release version of Vista?
  • Is it possible that a non-Vista version of comctl32.dll has been copied onto the machine and is being picked up by the application? (The Depends utility that comes with Visual Studio may help here.)
  • Is it possible that a virus or worm (or what not) has replaced the comctl32.dll?

It might also be worth reading this article on activation contexts.

Paul Ruane
Thanks, we'll have a look at this. If it leads us to the answer, I'll accept your answer as correct.
Judah Himango
+1  A: 

If the other machines you used to run the program were using Vista x86 it's likely that there's a PInvoke in your code that's causing the issue. You may want to try setting the compiler target architecture to x86 to force your program to run in WoW64 on the x64 Vista. By default, Visual Studio uses settings building assemblies in architecture-agnostic ways. That means that when you try to run a .NET program on a 64bit system it should be run hosted by a native x64 version of the CLR. Attemptiong to load a 32bit DLL in that context will fail. Forcing the app to run in emulated x86 mode, instead, should do the trick.

emaster70
Thanks, but we've already set the app to compile as x86, as we use some components that aren't x64 ready.
Judah Himango
+2  A: 

I had problems with this and Naughter's free XTaskDialog API, to get a fallback mechanism on Windows XP machines via emulation, rendering this dialog implementation much more useful. :)

In my case it was an activation context issue, as mentioned in this blog entry.

Or, quoted here, in case the blog post is lost in cyberspace some day (applies to Visual Studio):

  1. Open your project properties in the Solution Explorer,
  2. On the Security tab, check Enable ClickOnce Security Settings,
  3. Now you can see appearing the app.manifest file in the Properties folder of your solution, open it,
  4. Beneath the </trustInfo> tag, insert the code below.
  5. If you try to build, there may be an error. To fix it, uncheck the Enable ClickOnce Security Settings.

The code to insert in step 4:

<dependency>
  <dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" 
        version="6.0.0.0" processorArchitecture="*"
        publicKeyToken="6595b64144ccf1df" language="*" />
  </dependentAssembly>
</dependency>
Jonas
Thanks, we'll give this a try.
Judah Himango