I'm trying to access an Oracle Database from a program I'm writing on Windows 7 64bit. Whenever it initializes the client, i get a BadImageFormatException complaining that I'm trying to use a 32bit client in a 64bit environment. I've tried to compile the program in any way (Any CPU, 32, 64 bit), but it did not solve the problem. Any help?
I would guess that the error message is correct. You have a 32 bit Oracle DLL that you use from a 64 process. The Oracle DLL probably does some interop's with native code, that may require it to be processor specific.
There are several ways to solve this.
Option 1: Get the 64 bit Oracle DLLs.
Option 2: Make sure that your process is 32 bit.
.NET exe files marked for AnyCPU will start a 64 bit process on a 64 bit operating system. But if you mark your EXE file for x86 then it should work. For Web applications you have to set a 32 bit flag somewhere in IIS.
You need to configure your Project to target the .NET 4 Framework, by going to Project-Designer -> Target Framework.
Then you need to delete the old Oracle dll, and use the new 64-Bit-Version of the Oracle dll that is included in the .NET 4 Framework.
Related
I have a new VM on which I have installed Visual studio.
I created a new SSIS project, and am trying to use the oledb data source task to access an .accdb MS-Access file.
However I cannot see the Provider. So I installed the Access 32 bit runtime. Now I can see the provider. I am reading that since visual studio is a 32-bit tool, we have to install the Access 32bit runtime. Otherwise if we install the 64bit runtime, then we will not be able to see the provider in the list because visual studio is 32bit and only shows 32bit providers.
When I hit the debug button in visual studio SSIS project it can access the MS-Access file. I am now confused and want to ask - when the project is running, does it run in 32 or 64 bit mode? If the answer is 64bit mode, then how can it access the MS-access file using the 32bit provider? Does it mean that project running in 64 bit mode can utilize 32 bit mode runtime/provider?
Assuming no settings are changed, when debug button is pressed, then does the program execute is 32 or 64 bit mode? Does the OS bitness have any impact on this?
You are quite right and quite close here.
Since Visual Studio is x32 bits?
Well, if your project is set to x86 (x32 bits) or set to ANY CPU?
Then hitting F5 to run + debug (or ctrl-F5 to run the .exe without debug), then you will get (have) a x32 bit running program. Some caution here. If you use ANY cpu? then again FROM VS f5 to run - you get a x32 bit process.
But, if you go to the windows commnd line?
Well, if you launch teh windows x64 bit command line (default on most computers), then if the project is ANY cpu? Then your app run will be x64 bits. (and ANY un-manged code such as Access, or any other windows code used for COM autoamtion? it will break.
If you launch the windows x32 bit command line (with any CPU) then you get a x32 bit version running.
So, from VS - F5 - always x32 bits.
From windows command line - depends.
So, what above suggests? Well, if your intention is to have + use x32 bits process? Then FORCE/SET the project to your intentions. That way, no "by chance" will fool you, and your application will ALWAYS run as to the project settings.
So, in such cases, I do avoid ANY CPU.
Now, what happens if you force the project to x64 bits? eg this:
Well, if you pick x64 bits? (and not any cpu, and not x86).
Then hitting f5 (or ctrl-F5), it WILL run the application as a x64 bits in-process. I am not sure quite how VS works, but they have some kind of "bridge" that marshals the x64 bit debugger to talk to VS x32 bits.
So, if you force the project to x64, then it will always run as x64 bit - including from VS.
So, this means:
if you set project to x64 bits - use a connection builder in settings?
You can use the connection builder but since (we assume) that you using
access x64 bits? Then the test connection button in VS will NEVER work.
But, if you run the code as x64, and have access x64, then it will work. So ONLY the test connection button fails - and that's due to VS being x32.
If you have even the wrong version of Access (say x32 bits), and your project is set to x64? Then the connection builders will work and EVEN the test connection will work (because test connection is ALWAYS x32 bits from VS). This has the effect of you building a connection, hitting test connection - it says good!!! But when you run the project (f5, ctrl-f5), the project runs as x64, and it will fail (this example assumes x32 bits).
Now this is building an writing code from VS. I don't' know of a SSIS package built with Visual Studio works different. But we do NOT want to confuse Visual Studio (VS) with that of say sql studio or other systems - they don't have the project "cpu" or "bit" setting options like you do for a VS project.
So, I quite much suggest if your intention is x32 bit operations, then ALWAYS force the VS project to x32 bits, and thus come time to launch that .exe from windows, then it will never run with a wrong or un-expected bit size.
I not tested a SISIS integration project, but if building this from VS? Then once again, force/set the project bit size.
In effect to remove the "chance" of the wrong bit size? Then force the project to the given bit size you as the developer were intending to use here - that way this is not left to chance.
There ARE times when you want to use ANY cpu. A really good example is when you build say class library code to share amoung projects. In that case, ANY cpu is a good choice, since then EVEN projects forced to x32 or x64 can referances those external assemblies and library code.
However, if you force those external assemblies to a given bit size, then only projects running that that correct bit size can consume such libraries.
.net code (managed) is differnt then un-managed code. .net code has the ability to run "either" x32 or x64 if you choose ANY cpu. But un-managed code (external non .net code such as Access) can't change on the fly like .net code can. And I use the term "on the fly lose here". Since ONCE a .net program starts running x32 or x64? It remains that bit size until terminated.
So, ANY CPU is fine for external class library code you write and thus want to include in any project. But the main project .exe program has to use SOME external non .net (non managed) code? Then you would do very well to force the project bit size settings.
And to answer you last question?
If the provider is a .net one, such as sql provider or whatever? Then it is managed code - cpu settings don't matter. it is ONLY when you start using external code systems that are NOT managed and NOT .net code. MS-Access is one such common example. So would be any windows c++ or even a lot of commerial programs.
For example. Sage/Simply accoutning, and Quickbooks accounting? They offer .net SDK's to interface to those accoutning packages. But they only have x32 bit verisons of those desktop programs - and they are not .net prorgrams. So once agian, you do well to force the project to x32 bits.
So, no x64 bit process can consume a x32 bit process. nor can you consume external librares that don't match.
However, if that library code and system is .net (managed code), and was compiled and created with any CPU, then you don't have any restrictions in regards to using ANY cpu, or even consuming those libraires when you force the .net project cpu settings.
So this whole system ONLY breaks down when you introduce or start using external code libraires.
For example, if you use .net ghostscript library? They have two versions - x32 and x64. And thus just like MS-Access you have to match up the bit size of those external libraries.
This actually is a REALLY nasty problem say for Adobe PDF. Their pdf viewers are x32 only. In fact it was only what - last month they started offering x64 bit versions of their PDF adobe reader. And they no doubt started doing this since office is now moving towards being x64 bits and not a x32 bit system/program.
I have developed an ISAPI filter which runs fine on 32-bit. I also compiled it for 64-bit using VS2005 cross-compiler. But when I am trying to run it on Windows 2008 R2 64-bit server with IIS-7.5, it does not work. It seems filter dll has been loaded but IIS is not doing anything with it. I used the following command to check this.
tasklist /m mydll*
Any suggestions what
Is there a particular reason you need the DLL to be 64 bit? I've been able to run 32 bit ISAPI filters on a 64 bit machine by doing the following:
Make sure the IIS application pool is set to allow 32 bit applications (this is off by default)
Register the DLL using the 32 bit version of regsvr32: C:\Windows\SysWow64\regsvr32.exe
Verify that the DLL isn't missing any dependencies by using Dependency Walker: http://www.dependencywalker.com/
For 64 bit, the problem is the registry:
The problem I was
for 32 bit the location of apache redirector in registry is:
[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0]
but for 64 bitlocation must be:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Jakarta Isapi Redirector\1.0]
Note the "Wow6432Node".
so just re-create the 32 bit on the Wow6432Node and then you are set.
I have a desktop app created in vs10 and am using clickonce install. I must include a database with critical info for the program as part of the install. I am compiling for all versions of windows (32 and 64). But as I understand it, if I include the 32 bit sqlce as part of the installation, it will not work on 64 bit installs. Must I include a 32 bit and 64 bit version of the db and test for windows version before accessing the data? Or is there a simpler solution that I am missing?
You can just include all the required files as content with your app, and it will run for any user and on both x86 and x64 platforms. Just follow the instructions here: http://erikej.blogspot.com/2011/02/using-sql-server-compact-40-with.html
I've installed Visual FoxPro driver from this link on my 64 Bit Windows 7 Home Premium OS and tried to register vfpoledb.dll using REGSVR32. I could able to register this dll but when run my application which accesses VFP database is throwing the following error:
System.InvalidOperationException: The 'VFPOLEDB.1' provider is not registered on the local machine.
The same application is working fine in 32 bit Windows 7 Home Premium OS without any issues. I have googled for 64 bit VFP driver and found out that there are no VFP drivers for 64 bit OS from this link. Kindly help me to resolve this issue.
I have found out that there is no 64 bit VFP Driver for 64 bit OS. All we have to do is to change the build option in project properties and set the Platform Target to X86 instead of Any CPU. Build the application for X86. Please refer to this for more details.
It's a bit late, but may help somebody else:) You can use Advantage OLE DB Provider for Windows 64-bit, which works like VFPOLEDB. Example in python:
conn = win32com.client.Dispatch('ADODB.Connection')
dsn = 'Provider=Advantage OLE DB Provider;Data Source=%s; ServerType=ADS_LOCAL_SERVER; TableType=ADS_VFP;' % folder
conn.Open(dsn)
cmd.CommandText = 'ALTER TABLE test ALTER COLUMN area NOT NULL'
cmd.Execute()
A blog post by Eric Selje, of Salty Dog Solutions, describes how to run the 32-bit drivers on 64-bit Windows. (You must set them up in the 32-bit ODBC Administrator.)
Visual FoxPro, a 32-bit application, runs just fine on 64-bit machines.
Visual FoxPro cannot use 64-bit ODBC drivers however.
You can use 32-bit ODBC drivers on 64-bit Windows, but you must set them up in the 32-bit ODBC Administrator. This is not the one that’s
going to come up if you go through Control Panel. To invoke it, run
C:\Windows\SysWow64\odbcad32.exe and add your DSNs there.
Do not just Start, Run, ODBCAd32.exe, as it will not bring up the right one.
The 32-bit drivers for SQL Server come with Windows 7 x64, so you don’t have to download them.
I am creating a visual studio set-up project. I need to test to see if the version of Windows I am being installed on is 64 or 32 bit. I am planning on checking for the existence of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node as a way of telling that I am being installed on 64 bit windows. Is this a good idea and/or is there a better way?
The reason that I want to know which version of Windows I am on is so I can create a directory under either System32 or SysWOW64. I would rather not create two installers one targeting 64 bit platforms and one targeting 32 bit platforms.
The easiest way to check for a 64 bit machine in an MSI installer is to use the VersionNT64 property. This will only be set if the target machine is running a 64 bit operating system.
http://msdn.microsoft.com/en-us/library/aa372497(VS.85).aspx