I have a WPF app that uses Flash10c.ocx developed on a 32 bit machine. I didn’t have to register the ocx on my dev machine, I just installed the latest flash, added a reference and started coding. When testing on a 64 bit system I get ye old “Class not registered” which I think mean I need to regsvr the ocx. Is it Ok to just copy the 32 bit ocx (I’m pretty sure its 32 bit as its located in C:\Windows\System32\Macromed on the dev system) to a 64 bit system and register it?
Update: regsvr32 /i flash10c.ocx errors out with “The module flash10c.ocx las loaded but the call to DllRegisterServer failed with error code 0x80004005”
Update 2: I’ve given up on this and decided to run Flash on 32 bit systems only. If anyone has a better answer I’d like to hear it but I’m marking the current suggestion as answered to give due credit for the effort.
The reason it’s not working for you is that your WPF application is running as 64-bit.
A .NET application is able to run as 32-bit or 64-bit; and the CLR is JITing your app to whatever architecture the application is running on – in this case 64-bit.
Except you now want your 64-bit application to load a 32-bit dll. This is not possible. A 64-bit process can only load 64-bit dlls. A 32-bit process can only load 32-bit dlls. No amount of fiddling with COM object registration will change this; it’s not a question of missing registry entries.
Adobe Flash only comes as a 32-bit dll. Adobe does not now (and hopefully will never) have a 64-bit version.
In order for your WPF .NET application to load the 32-bit flash dll, it needs to be running as 32-bit process. There is a way, in Visual Studio’s build configuration, to force your .NET application to only target
x86, rather thanAny CPU.The choices of CPU targets are:
Flash, for what it’s worth, doesn’t have an Itanium version, either.
See StackOverflow: Visual Studio “Any CPU” target for more discussion about target cpus.