My machine has the latest Oracle ODP.NET x64 installed (xCopy version). My machine is x64. I don't know if the target machines will be x86 or x64 so I have set the build properties to AnyCPU in VS 2012. There is a default checkbox active "prefer 32-bit"
Compilation is OK but when I run the code it says it can't find the assembly. Unchecking "prefer 32-bit" solves this problem.
But what is causing this? I would assume that prefering 32-bits is okay but that it would use x64 if that's the only option.
Any ideas?
"Any CPU" with "Prefer 32-bit" will run as a 32-bit process on 64-bit machines. And because a 32-bit process can't load the 64-bit ODP.NET assemblies (and native DLLs too), it throws the exception you mentioned.
You can read more about the "Prefer 32-bit" setting here: https://stackoverflow.com/a/12066861/631802
Related
Using VS 2010 Ultimate on my Windows 7 64-bit machine, I wrote a Windows Forms Application with Visual Basic and then compiled it with "Build" command specifically for x86 platforms ( I have tried assigning both "x86" and "Any CPU" on Active solution platform options in Configuration Manager). I have also made sure that TargetPlatform is set to x86 on Project Properties.
However, when I'm trying to run the .exe or the .msi file on my XP 32-bit machine, I get this message:
"This product is designed for x64 platform but is being installed on Intel. Obtain the correct setup from the manufacturer."
.NET Framework 4 client profile, which is a Prerequisite for my application, is also installed on the XP machine.
Does anyone have a clue for this? How can I fix this?
Thank you for your time.
I'm not sure about 2010, but in VS2008 it is sometimes necessary to go to Project Properties, Compile, Advanced Compile Options, and change the target CPU to from AnyCPU to x86.
Thank you for any and all help... I've never seen this bug before... I have several vendor supplied DLLs for talking to a Signature Capture Device. We build our C# windows app platform target set to "any cpu" on an XP x86 machine. When the application is run on Win7 32-bit computer it works fine. When it is run on Win7 64bit computer it fails.
Running the Visual Studio 2010 debugger on Win 7 x64 in "Debug mode" works fine. Running in Release mode on Win7 x64 fails.
I can change the platform to target x64 then Release mode gives "interops made for a different target platorm." When I delete and recreate the interops for 64 bit target I get "ActiveX not properly registered".
Thank you in advance.
Make sure you module not depends of 32 bits libs.
Use Dependency Walker or Fuslogvw.exe to diagnose module load fail.
To interop 32/64 bits COM see Access x86 COM from x64 .NET
My solution was to change the Project->Properties->Build->Platform Target from "any cpu" to "x86". The application now runs on win7 64 bit and 32 bit and XP x86.
I would like to build a x64 package of a project I wrote in monodevelop. I can change the project compiler options from x86 to x64, but if I do this, I get the error:
Error CS0016: Could not write to file `AudioCuesheetEditor', cause: AMD64 (CS0016) (AudioCuesheetEditor)
How can I build packages for x64 systems?
Thank you for help!
Use the any cpu configuration
You'll get x64 on a 64-bit operating system, x86 on a 32-bit operating system. Automagic provided by the just-in-time compiler.
BUT On windows x86 with anycpu there is no problem. Using windows x64 will crash becaus gtk-sharp has no x64 build. So on windows x64 you have to build x86.
When I run the 64-bit version of Windbg on a Win7 64-bit machine, it shows the image path of the the clr.dll module to be the 32-bit version of the framework, not the 64-bit.
Is there any way to specify the image path for the clr.dll module in Windbg? Should Windbg 64-bit running on a 64-bit box be grabbing clr.dll from the Framework64 directory?
0:000> lmvm clr
...
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
I have a 64bit w3wp.exe dump that I cannot use SOS on, and I believe it's because of incompatible frameworks, caused by this 32bit clr dll image.
0:000> .loadby sos clr
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos) failed, Win32 error 0n193
"%1 is not a valid Win32 application."
Once again, the dump is from a 64-bit server, I've doubled checked that it has the same CLR version as my Win7 64bit machine I'm debugging on, and I'm running 64bit Windbg.
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
...
Windows 7 Version 7600 MP (4 procs) Free x64
When I run 32-bit Windbg, it loads SOS fine, but then errors when I try to run !threads, with the ubiquitous Failed to load data access DLL, 0x80004005 error.
Can the CLR image be set and if so, how?
This actually sounds like an mscordacwks issue. Take a look at http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx for an excellent guide on resolving this.
Is there a way to compile a VB6 component into 64 bits?
My feeling is that the answer is "no", but I would like to confirm this.
Please, if you can, paste a link to an authorative source that would confirm.
No. I hope this counts as authoritative.
64-Bit Windows
Visual Basic 6.0
runtime files are 32-bit. These files
ship in 64-bit Windows Operating
Systems referenced in the table below.
32-bit VB6 applications and components
are supported in the WOW emulation
environment only. 32-bit components
must also be hosted in 32-bit
application processes.
The Visual Basic 6.0 IDE has never
been offered in a native 64-bit
version, nor has the 32-bit IDE been
supported on 64-bit Windows. VB6
development on 64-bit Windows is not
and will not be supported.
No it cannot (well Microsoft has not released a compiler to compile it for a 64-bit environment), but this does not mean that it won't run on a 64-bit system. To run it in conjunction with IIS, you'll need to install the 32-bit version of IIS.