The OS is Windows XP 64 bits.
The application is Microsoft Office 32 bits, on top of which my application (an office addin) runs.
The DLL is a 64 bit Adobe Acrobat “IFilter” dll, which enables access to the contents of a .pdf file.
I thought that the solution to the problem is finding the 32 bit version of the IFilter dll, but because the OS is windows XP 64 bits the only version that will register properly is the 64 bits version.
Setting the target platform of my .NET project to x86, 64 bit or “Any CPU” won’t solve the problem.
The 64 bit IFilter works properly only when I invoke it from within a console application, but once it gets invoked from within the context of the office Add-In, it does nothing.
What’s the best way to solve this problem? Should I load the 64 bit dll into a new process and have the office add-in communicate with it using remoting?
Also, for those of you familiar with IFilter, is it possible to deploy the 32 bit version of the IFilter along with the office add-in and then access it directly without searching the registry for the properly installed IFilter? ( I couldn’t do it )
You will need to Thunk to the DLL. Whether this is possible in the WOW64 I’m not sure. Certainly it was available on WOW32 in the eary days of NT.
the theory was simply to cause an interupt in the program code – that would thunk over to the 32 bit address space where the DLL was loaded.
It sounds like an interesting project.
However for a quicker solution I would use what you say – host the dll in a 64bit process and communicate using what ever IPC you like (personally WCF Named pipes is quite easy, or perhaps you can use memory mapped files if the data tx is high volume.