Getting the "VFPOLEDB.1 Provider" error "not registered on the local computer" even after installing and registering the provider

Question

Ok, so I have a Windows service that has a FileSystemWatcher that monitors the output folder for some Visual FoxPro database files. And he uses the VFPOLEDB.1 provider to read these files. I can’t get away from this provider because it is used in production.

However, I never had to support this application until why I did not set up a development window for it. Here is my environment:

• Windows 7 x64
• Visual studio 2005
• Windows.NET 2.0 Service

therefore, when I first started getting an error, I realized that I simply did not have a provider, and I was right. So, I downloaded and installed here .

Then I again sent the files to the folder, but got the same error.

I realized that this is an x64 machine, I might have problems getting it, as it probably fell in SysWOW64 , and it was as I expected, so I ran this command:

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

and he said that he was successfully registered (which means nothing lol), but I reset the files again - with the same error.

I have not rebooted my machine yet, and I can, if someone has a good reason, that the problem is, but generally speaking, if the assembly is correctly registered with regsvr32 , this is not necessary. I worked with tons of COM objects and should never reboot to get to the object while I registered it.

Does anyone know another step I need to take to register this thing?

Answer 1

Registered as follows. This is an application that is compiled for the AnyCPU platform.
On x64, the operating system produces 64-bit code, and 64-bit code cannot access 32-bit drivers.

Change your platform to x86 and everything will be fine.

EDIT
Two years later, there is something to add to this answer. Now with Visual Studio 2013 has been moved. The article explains in detail how the default settings for the compiler have changed. An AnyCPU target CPU with Prefer 32 bit means your application runs as a 32-bit application, as well as on x64bit operating systems, leaving virtually no space for the x64 application unless specifically required.

With this new configuration, it is also important to remember what is posted in the comments below by Mark Berry. If your (now 32-bit) application needs to work in a 64-bit IIS environment, you need to install the Application Pool using Enable 32 bit Applications

Answer 2

I have a desktop application (Win7 x64 VS 2015) - and still got the same error. I changed the target platform to x86, installed MSI as administrator, etc. - did everything he could for Google - and no luck. What helped me was to install MSI for Everyone instead of Just me - one of the last screens of the installation wizard.