Context
For a bit more context, the company I work for made an Access vb.net application that runs inside MS Access. They wanted to upgrade and create a C# WPF frontend for it. This works great except for the fact that when I installed the application and downloaded the [dummyDB].accdb (32-bits 2016) the application immediatly broke with the error :
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
I then installed the 2010 AccessDataBaseEngine from Microsoft and a new error apeared:
This Database file requires a newer version of Access
Naturally I went back to Microsoft, downloaded and installed the 2016 x64 (my system is 64-bits) and tried again.
Sadly we we're back to the first error. So i tried to install the 2016 32-bits AccessDataBaseEngine but ran into the problem that I had already installed 64-bits office products. (I also uninstalled all the previous 32-bit AccessDataseEngines)
We of course don't want users to reinstall all their Office products just to use our application.
Question
Is there a NugetPackage of somesort that we could use so the customer can interact with the AccessDatabase out of the box?
If not, is there anyway to make it so they wouldn't have to reinstall all of their Office products?
ps. Different DataBase files 32-bit and 64-bit for users is also not an option because different users with most likely different systems will have to access the same database file.
I don't know if I'm being completely oblivious here, but any help would be greatly appreciated
Application info:
WPF application (.Net Framework 4.7.2)
Build Target : anyCPU
Is there a NugetPackage of somesort that we could use so the customer can interact with the AccessDatabase out of the box
No, not as far as I know.
If not, is there anyway to make it so they wouldn't have to reinstall all of their Office products?
You could write an wrapper that handles both 32 and 64 bit versions of the access driver. I.e. if the installed driver is the same platform as your program you can just continue as usual. If it is another platform you need to start a new process with the correct platform, and delegate all the database work to this process. If your process is anyCPU and is run on 64-bit windows the actual platform will depend on the "prefer 32-bit" flag.
Another alternative is to build both 32 and 64 bit versions of your entire application and run the one matching the office installation. This might be easier, but might not work if you have other platform specific dependencies.
This all assumes that office is already installed, if it is not you can just deploy the stand alone ace driver (i.e. AccessDataBaseEngine) with the correct bittness. The database file itself is platform agnostic and can be accessed by either 32 or 64 bit processes. It is the driver that needs to be of the correct version.
Note that Access is kind of difficult to work with and rather error prone. If this product is intended to be long lived I would suggest migrating to something better sooner rather than later. SqlLite is a popular embedded database engine that could be an alternative.
Related
Learning C# as I go along with managing an existing project given to me. I've noticed there seem to be deployment issues when I build from my windows 10 machine and set up the application on a user's Windows7 machine
Issues such as:
-Getting null pointer errors
-when saving word docs automatically, instead a save dialog box appears
I cannot for the life of me recreate the issues on my machine.
From what I see,
I use Windows 10 64bit with 32bit Microsoft Office
They use Windows 7 64bit with 32bit Microsoft office
We both have .NET v3, v3.5, v4.0.3... and the project is in v4
I can't help but think it is OS related issue I need to account for but I don't know whether I can trust this due to my lack of experience
Can anyone give some advice
My current plan is, since the users are not very accessible, I will try and get a laptop that replicates theirs. Then, if I can recreate the error on there, then i will install visual studio remote debugger and try to attach this external process and debug from my side. Mostly this is my only plan which is a long shot at best
It sounds like you're dealing with Office automation/addins. I would imagine that the version of Office is very important -- not just 32 bit vs 64 bit, but the specific build and version of Office/Word.
Recreating the error is key, as you suspect. Try setting up a Windows 7 VM on your PC with the same environment that the users have. This will make it easier for you to reproduce and debug the issue.
You also need to know the exact sequence of steps that causes the error, and if possible, you will need a copy of the document the user was working on.
I am beginner in using Microsft.ACE.OLEDB 12.0. I create a Winforms application VS 2010.
And create a function for export data grid data to MS Access file. I using Microsoft Oledb
for export the data grid data to MS Access file.But i get this error when i try to export
the
data to ms access.
Please see the below image.
I also refer the Microsoft.Office 12.0 Object Library in my application.
Batch Build Configuration
The reference to the Access Interop bits has nothing to do with your exception and Access Interop is not necessary to use the classes in the System.Data.OleDb.
The problem arises when you have your application compiled for AnyCPU Platform, you are running on a 64bit system and the installed ADO.NET provider (Microsoft ACE.OLEDB.12.0) is the 32bit version.
When using the AnyCpu target Platform your code will be executed as 64bit code on 64bit systems and as 32bit code on 32bit systems. An application executed as 64bit cannot use 32bit drivers (and viceversa). Now add to the mix the fact that Microsoft.ACE.OLEDB.12.0 has two different versions. One for 64bit and and one for 32bit and they cannot be installed together on the same machine.
The simplest workaround is to change the Target Platform of your application through Visual Studio menu
BUILD -> Configuration Manager -> Active Solution Platform -> x86
If the x86 option is not already there, then select NEW, name it x86, Copy Settings from AnyCPU and check Create new project platforms
If you think that using a 32bit app on a 64bit Operating System is a loss of performance or something to be avoided then think twice and read this reference where the PRO and CONS of AnyCpu are critically examined. If you don't have a specific reason to use AnyCpu it is better to stay with x86.
Of course, another option is to deinstall the 32bit version and install the 64bit version of ACE from here and then run you application as AnyCpu on 64bit systems. But this could be a nightmare for your deployment scenarios. What if Microsoft Office 32bit version is installed on your x64 target machine? Office installs its bit compatible version of ACE and, as said, it is not possible to have 32bit and 64bit of ACE installed on the same machine.
Now you should also ask your customer to reinstall Office as 64bit to keep your 64bit app happy.
UPDATE
The situation has changed a bit with the newest versions of Visual Studio. There is now a new option that is the default for new projects. It is called AnyCPU Prefer 32bit mode. More details at this link: What AnyCPU Really Means As Of .NET 4.5 and Visual Studio 11 and another interesting post (albeit regarding Sql Server Compact) is this one The trouble with Any CPU–Prefer 32 bit–BadImageFormatException
Change in its App pool 'advanced settings' to allow to run 32-bit programs... that did it for me.
I have similar issue when we are reading Excel file.
History of the problem:
We recently migrated our application from 32-bit to 64-bit because of the memory requirement. For that we migrated our windows 7 from 32-bit to 64-bit. But still we installed 32-bit office on our machines.
because, of this we had this issue while importing Excel data into application.
Solution,
I downloaded 64-bit version of the http://www.microsoft.com/en-us/download/details.aspx?id=13255 and installed with argument as,
AccessDatabaseEngine_x64.exe /passive
Without any code change my issue get resolved.
Note:
On 64-bit OS and 64-bit office, my functionality was working fine without this fix. This fix is only required while our application is 64-bit running on 64-bit OS which is having 32-bit office installed on it.
Base way:
Application : MVC C#,
For Win Server 64 bit:
Remove all office 32 bit installed.
Download link: https://www.microsoft.com/en-us/download/details.aspx?id=13255
select download 64 bit and then install it to server(If you can't setup program. Please re-check 1 point).
retry access your application again.enter image description here
for me installing Microsoft Access Database Engine 2010 Redistributable fixed the problem, the 32 bit version.
In my case
Download link: https://www.microsoft.com/en-us/download/details.aspx?id=13255
Select download 32 bit and then install it to server(Even if your server is 64-bit)
If you can't setup program uninstall 64 bit version.
Retry access your application again
If you have still error(Set Enable 32-bit Applications to True for your application in IIS)
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?
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
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.
I have the same problem.
I install the VFP Ole DB Provider in my system and resolved.
download link
use Advantage OLE DB Provider,works for 32 or 64,here is the connection string
I have developed a C# winform application in Visual Studio 2010 that connects to a Access 2010 *.accdb database. It works fine on my pc but when I install it on another, It throws the error "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."
I tried to compile it to x86, as advised, without any succes.
Any help/advice is appreciated, I think that I should include this driver as part of my clickOnce install. If so, how do I do so? (It does not appear as an option in the checklist of requirements, in VS Properties > Publish > Previous requirements)
You will have to use a more advanced method of deploying the necessary driver - ClickOnce won't do it by itself as far as I know. I also don't think it's as simple as a single DLL. The driver needs to register with the system etc.
There is a big issue with the Access drivers because of the way they are set up. If the user has Microsoft Office with Access installed, they will already have the ACE driver. The problem is, if they have 32 bit Access installed on a 64 bit machine, your 64 bit application will not be able to talk to Access because the machine only has a 32 bit driver, and you cannot install both.
If none of your users have Microsoft Office with Access, then you should be able to deploy the standalone driver installer for 32/64 bit as necessary with each computer.
It is possible to include arbitrary assemblies and files as part of your ClickOnce install by adding them to the project and changing their file type to Content. They will then appear in the list of Application Files.
Note that you'll get a warning from Visual Studio if you do this, but it can be safely ignored.
You can build an msi instead of oneclick and create a custom action that would install ace driver in quiet mode. Since its an executable you can just run it in a process object
I made C# application for my friend which has connection to access database (mdb file). I have developed application on my computer with win7 x86 installed. My friend had XP and it worked perfectly, but now he installed win7 x64 and application doesn't work. In fact, application starts and behave regular, but cannot connect to database... Database too can be opened with access, but my application cannot connect to it.
What can be a problem? How to make my application works on both operating systems?
regards,
Vajda
Ask your friend to download and install the following file:
Microsoft Access Database Engine 2010 Redistributable
and make sure he picks the 64-bit version there (AccessDatabaseEngine_x64.exe).
By default there is no 64-bit ODBC/OLEDB driver for Access installed, but the 2010 version should work for 2007 databases as well.
You could probably also configure your program to be built for the x86 target. That would run the program as a 32-bit program, even on 64-bit OS.
Most likely, the .Net CLR is trying to fire the app up in 64bit mode by default on his new win7 box and this might be causing some issues with the referenced assemblies.
The first thing I would try is to change the Platform target of the application (go to Project properties in Visual Studio for the application) to x86 (from Any CPU) to force the application to run in 32bit mode.
If this works, you will have narrowed down your problem.
Then, after building the project, look in the bin folder to see which assemblies are being copied to the output folder. If you see any System.Data... or any other .Net assemblies that are already contained in the GAC, you'll want to delete these and then try to fire it up. This will force the application to use GAC assemblies written for 64bit use.