Failed -- Retrieving the COM class factory for component with CLSID...

I've integrated LTMM into my app and am running into a few problems and am hoping you can clear some things up for me.

On the target machine it appears that I have to register DSKernel2.dll and Ltmm16.dll. First, why do I need to do that? Isn't that a fairly outdated way of handling dlls, especially if I'm developing in .NET? Is there a way around registering on the target machines? This just could be misinformation on my part, but with other LeadTools dlls I just have to drop them in with my app. When I was writing my own C++ dll to interface with the DirectShow I did the same thing...nothing had to get registered.

But I did register the dlls on the target machine and everything worked fine for the 32 bit system, but on the 64 bit system the call to UnlockSupport from a static constructor caused an unhandled exception. The error code produced was 80040154. My application is built using 'Any CPU' in the configuration manager and we want to keep it that way so we don't have to have a 32 bit install and a 64 bit install (at this stage anyway). Can you tell me what to do to get the DLLs to work with the 64 bit system?

Thanks a lot for your time.
Matt

Hello Matt,

Although you are using our Multimedia support through DotNet, our toolkit is based on a set of COM objects. For this reason, you must register the dlls, and there isn't any way around this that I'm aware of. Our Imaging toolkit is not based in COM, so no DLLs need to be registered with it. You only have to have them near your exe to be loaded at runtime. If you wrote your own dll to interface with DirectShow, you were likely accessing filters that were already registered on the machine.

Our dlls are currently only 32-bit. If you do not set the target processor to x86 but deploy to a 64-bit machine (i.e. to "Any CPU"), the processor is going to look for 64-bit dlls. When it doesn't find these, it could throw an error such as you're seeing. This problem is not present on a 32-bit machine because the processor can find the DLLs in the system (both being 32-bit).

I would suggest changing the target processor to x86, and try deploying to a 64-bit machine to see if this is the problem. Applications using 32-bit dlls should be able to work in 64-bit machines as well, so making this change doesn't force you to use two projects for the two different machine types.

If this does not work, please let me know so we can continue looking into this issue.

Thanks for the reply. I've registered the ltmm16.dll and dskernel2.dll and everything seems to be working fine. However, on target machines (those where Multimedia is not installed) I get the same error. I don't get an error on development machines where Multimedia was installed.

My first thought was that there were dll dependencies, so I registered everything in the redist directory on the target machines and still no joy. What step am I missing that is covered during the Multimedia install process?

Incidentally, the exception occurs when I first access LTMM code, in the following line for example:

ltmmCaptureCtrl captureControl = new ltmmCaptureCtrl();

Thanks for your time.
Matt

Matt,
If you use the new keyword to create our control, it will only work on a development machine, because this is similar to design-mode creation of the control.
Our controls are licensed, so you can only create them in run-mode on non-development machines.

The 'normal' way of doing that is to draw the control on a form, build an EXE and deploy the EXE (along with registering needed objects).

If you must use dynamic creation, you need to supply the license string during creation. The following forum post explains how to do that:
http://support.leadtools.com/SupportPortal/CS/forums/24719/ShowPost.aspx#24719

Thank you. I just added the control via the designer and it worked fine.

Matt