Getting the error “The 'VFPOLEDB.1' provid

Question

Alright, so I've got a Windows service that has a FileSystemWatcher that watches an output folder for some Visual FoxPro database files. And it leverages the VFPOLEDB.1 provider to read those files. I cannot go away from this provider because it's being used in production.

However, I've never had to support this application before so that's why my development box isn't setup for it. Here is my environment:

• Windows 7 x64
• Visual Studio 2005
• .NET 2.0 Windows service

so, when I first started getting the error I figured I just didn't have the provider at all, and I was right. So, I downloaded and installed it from here.

I then proceeded to drop the files in the folder again, but I got the same error.

I figured because it's an x64 machine I might be experiencing problems with it getting registered since it was probably dropped into SysWOW64, and it was as I expected, so I ran this command:

regsvr32 "C:\Windows\SysWOW64\mscomct2.ocx"

and it said it was successfully registered (which means about nothing LOL) but I dropped the files in again - same error.

I have not yet rebooted my machine, and I can if somebody has a compelling reason that's the problem, but generally speaking if the assembly is registered properly with regsvr32 that's not necessary. I've worked with a ton of COM objects and never have to reboot to get to the object as long as I've registered it.

Does anybody know another step I need to perform to get this thing registered?

Answer 1

I have desktop app (Win7 x64 VS 2015) - and kept getting the same error no matter what. I changed platform target to x86, installed MSI as admin etc - did everything I could google - and no luck. What helped me is to install MSI for Everyone instead of Just me - one of the last wizard's screen in the setup.

Answer 2

It is registered as it should. It is your application that is compiled for AnyCPU Platform.
In x64 operating system this produces 64bit code and 64bit code could not access 32bit drivers.

Change your Platform to x86 and you will be fine.

EDIT
Two years later there is something to add to this answer. Now with Visual Studio 2013 the cheese has been moved. The article linked explain in great details how the compiler setup defaults has been changed. The AnyCPU target CPU with Prefer 32 bit means that your application works as 32bit app also in x64bit operating systems leaving practically no-room to x64 application unless specifically required.

With this new configuration becomes also important to remember what is posted in comments below by Mark Berry. If your (now 32bit) app needs to work in a IIS 64bit environment you need to set the Application Pool with Enable 32 bit Applications