Getting the error "The 'VFPOLEDB.1' provider is not registered on the local machine" even after installing and registering the provider

c# com windows-services visual-foxpro
Mike Perrenoud picture Mike Perrenoud · Mar 28, 2013 · Viewed 20.6k times · Source

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

Steve picture Steve · Mar 28, 2013

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

Related questions

Microsoft.Office.Core Reference Missing

Using the example provided in codeproject I am struggling to work out where I can find the reference to the library Microsoft.Office.Core. I am getting the error "The referenced component 'Microsoft.Office.Core' could not be found." I …

Read More
How can I generate UUID in C#

I am creating an .idl file programmatically. How do I create UUIDs for the interfaces and Methods Programmatically. Can I generate the UUID programmatically?

Read More
How to handle AccessViolationException

I am using a COM object (MODI) from within my .net application. The method I am calling throws a System.AccessViolationException, which is intercepted by Visual Studio. The odd thing is that I have wrapped my call in a try …

Read More