I'm writing a Windows Forms ClickOnce application that uses the Oracle Instant Client to connect to the DB, because installing the full client on our users' machines is not an option. Unfortunately, our users have a mix of 32 and 64 bit machines. While the application itself is AnyCpu, the Oracle libraries are not.
Right now, we are distributing two copies of the client, with the only difference being the Oracle DLLs -- 32-bit DLLs for 32-bit users, and 64-bit DLLs for 64-bit users.
Just as an experiment, I tried releasing a client with both sets of DLLs, in separate directories, which determines the host OS's bitness at runtime and then loads the DLLs using LoadLibrary. This works, but only sort of.
On 64-bit systems, an error box pops up saying, "The program can't start because oranls11.dll is missing from your computer". When I click "Ok" to dismiss the box, the program starts up and runs normally. Adding oranls11.dll to the list of DLLs to load causes two copies of the message box to pop up, one after the other.
So, is there a better way to load the Oracle Instant Client ? If not, is there a way to suppress that message box, at least ?
Related
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.
Helo,
I am developing UWP Application.
Trying to install build (by Side loading) in various systems.
All systems are windows 10 only, but having different processors. Some systems supporting with Debug mode generated builds and some systems supporting with Release mode generated builds. I am unable to track this issue. Why can't single mode build (whether it may be Debug or Release mode) supporting for all windows 10 systems. Can any one tell me what are the client system requirements for installing and working with UWP applicatiton.
Below is my client machine system specifications
And I have generated build in Release mode by selecting both 64 and 32 bit, after side loading I got files like below
Application installing successfully, but when i am trying to open it's getting crash.
I have observed one change In Client Machine.
Marked one getting extra in Packages folder.
I have verified windows log, it's showing below error.
Activation of app fb23829-a660-4c2e-88df-bc3c735654f7_a2ct2483cqfyg!App failed with error: The remote procedure call failed. See the Microsoft-Windows-TWinUI/Operational log for additional information.
After so many trails I came to know that if target machine having i3 processor then at the time of generating the build we should select only one type i.e., either it may be 32 bit or 64 bit. if we select both then application will Crash.
I have compiled a c natives 32bit DLL with Dev-C++, create the reference on my asp.net project, write a dllImport directives and use my new DLL. When launch my DEBUG session all work very well but when deploy my project on Web Server the runtime not load my DLL.
My IIS 7.0 w3wp.exe runs as a 64 bit process (to check if your process running as a 32 bit process under WOW64, open the task manager's Process tab and see if the process name contains "*32").
I believe that a 64 bit process can only load 64 bit native DLLs (and managed DLLs built for "Any CPU" or "X64"). Perhaps your debug session is a 32 bit session? If this is the cause, take a look at Using a 32bit or 64bit dll in C# DllImport .
For those of you who still cannot find a proper way to use a 32-bit DLL under a 64-bit IIS Application Pool, either by tweaking the registry, or by trying how to deal with the "COM+ Components Services", I have found a perfectly working solution : "Encapsulating" the 32-bit component into a new COM object as described on this page did the job perfectly, and I think that a lot of you will be interested to solve the problem this way ;)
http://www.chestysoft.com/component-services.asp
In my case, that allowed me to use the "XStandard.Zip" free Component from XStandard, which is sadly only available as a 32-bit ASP component, and that have an "InProcServer32" Key in the registry apparently preventing it to work by tweaking the registry, as described here : https://techtalk.gfi.com/32bit-object-64bit-environment/
In this post, a lot of comments reported that "InProcServer32-IDs are not reflected because Microsoft assumes that these are only InProc-Calls and not Out-Of-Proc-Calls".
And that was my case too, leading me to the situation where the registry tweaking solution described in the previous post was not working in my case, as other users.
Hoping having saved some days... or nights !
We have 32 bit windows application developed with vs2005.In this application their is facility were user can upload his details with xls file.
As demand we need to support to 64 bit machine,which we have done.
The only problem we faced is that when user try to upload file system throws an error "'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine"
Can u guide me for the same
Microsoft's Jet driver does not exist in 64-bit form. You have two options:
Compile your application to 32-bit only. This will run on 32-bit workstations and WOW64 on 64-bit machines, so you still get the benefit of "supporting" 64-bit machines even though it is running 32-bit.
Move to the ACE driver, which comes in 32-bit and 64-bit variants.
Option #1 is probably what I would recommend. This requires the least changes to your application, and your application will likely have very little benefit by running native 64-bit. Secondly, if you do move to ACE for the purpose of supporting 32-bit and 64-bit, now you need to worry about two different ACE drivers, the 64-bit one and the 32-bit one.
I had a similar problem - see How to enable reading C# Excel files on IIS (reading them locally on the machine where IIS is running works fine)?
Rewriting everything using EP Plus for XLSX and NPOI for XLS turned out to be much easier than using Microsoft stuff. Both are freeware and work well.
I have just moved from a 32-bit Windows 7 desktop to a 64-bit Windows 7 Laptop. We have a C# program that we are developing that contains approximately 60 projects within the solution. I keep getting the following error whilst trying to build:
Attempt to load Oracle client libraries threw BadImageFormatException. This problem will occur when running in 64 bit mode with the 32 bit Oracle client components installed
Obviously the error is quite self explanatory and I am trying to get my whole solution to load in 32 bit mode. I have gone through every single project and set the target platform to x86 but I am still getting this error. I have searched Google and seen countless different approaches, but I cant seem to fix this problem. What is the best way to ensure my project is running in 32-bit mode on a 64-bit machine?
I am using Visual Studio 2008. I am currently considering downgrading to 32-bit but really want to avoid having to do this.
I found that you have to install the 32-bit Oracle client (you can download the installer from their website) even if you are running on a 64-bit machine.
In addition, during the discussions people were talking about 32-bit mode etc. This is how you can check / set that for an IIS 7 hosted application. You shouldn't need to change this but I have added here for completeness / future reference.
Launch IIS 7 and expand the server name node.
Click on Application Pools node and find the
application Pool you are using.
On the right-hand panel click Advanced Settings...
In the pop-up box that appears check Enabled 32-Bit Applications setting which is third option from the top.
You have to change your main .exe file to run only as 32-bit. You can do this in Visual Studio - just change Platform target from "Any CPU" to "x86".
If this is not possible, use corflags.exe which forces an existing exe to be a 32-bit application.
I have been struggling with this issue for months now and finally solved it. I think all the posts are helpful, but I had one missing piece. I didn't have a Microsoft ODBC for Oracle instance setup for User DSN or System DSN. I'm working on a Windows 8 machine. So for me I had to go to the general windows search and type in ODBC and open the ODBC Data Source Administrator (32-bit). Check to see if you have a Microsoft ODBC for Oracle setup on the User DSN tab or the System DSN tab. If not click on Add and select Microsoft ODBC for Oracle. Fill out the info for your datasource you are trying to hit and click ok. Make sure to restart your computer and that is what finally worked for me. Hope this helps some of you.
You have to change your main .exe file to run only as 32-bit. You can do this in Visual Studio - just change Platform target from "Any CPU" to "x86".
https://msdn.microsoft.com/en-us/library/ms185328.aspx
In my case 64 bit Oracle client was installed on my machine but still giving same error. So, I have analyse that in my application go to Application right click go to ->Properties->Web tab
and uncheck the "Use IIS Express" option if you are using local IIS Web server.
Problem got solved.