I have to upgrade a project from 32 bit to 64 bit. My project is currently on .net 2.0 (will be soon 4.0, but doesn't really matter for this issue). My project is referencing some old .net 1.1 assemblies, that I only have in binary form. As you all know, 64 bit support was added in .net 2.0 only, and I expected my application won't run because of those old assemblies.
However, my application runs on a x64 server in 64 bit mode (no star is shown in Task Manager) while referencing the .net 1.1 dll.
My questions are:
Why does it run? I previously read that you cannot use .net 1.1
assemblies in 64 bit apps.
Are there any shortcomings if I keep the 1.1 assemblies? Or should I invest effort in getting newer versions of those 1.1 assemblies?
EDIT: I forgot to mention that a requirement is to run the application (asp.net) natively in 64 bit. The application runs in 64 bit because I disabled 32 bit compatibility on my application pool.
EDIT2: I just tried to compile and run the application compiled for x64. It works. So it runs in pure 64 bit mode, no questions about it.
A .NET 1.1 assembly contains the same kind of IL as a .NET 2 or .NET 4 assembly. Only the format of the metadata has changed. The jitter doesn't mind translating it to 64-bit machine code and the CLR can read the old metadata format. Only if the .NET 1.1 assembly contains native code will you have a problem. Corflags.exe utility, ILONLY bit. There's no compelling reason to rebuild that assembly.
Is your application running under wow32 (32-bit emulation mode)? Most applications do not really run in x64 mode, they force the application to run in wow32 (x86 mode) to keep their backward compatibility on older x86 systems. Otherwise the application would run only on x64 systems but not on x86.
Forcing the application to run in x86 mode (even on x64 systems) allows to run ony any manchine no matter if its a 32 or 64 bit windows OS.
Related
My config: Vs2015 / X64 PC / ODP.NET X86
I've wrote a few DLL on 'Any Cpu' mode and I would like to write programs that use this DLLs and that can be work on X64 and X86 machins.
But I referenced "Oracle.DataAccess.dll" in my Dlls then I've a warning 'ProcessorArchitecture=X86' on Oracle DLL.
How can I do (I can install ODP.NET X64 if necessary) ?
thks
When you compile your DLL with "x86" then also the Oracle.DataAccess.dll must be the x86 version (i.e. 32 bit version)
When you compile your DLL with "x64" then also the Oracle.DataAccess.dll must be the x64 version (i.e. 64 bit version)
For "AnyCPU" it depends, there is no "AnyCPU" version of Oracle.DataAccess.dll. If your application runs on 64-bit Windows it will run as x64 process - thus also Oracle.DataAccess.dll must be the x64 version. If your application runs on 32-bit Windows it will run as x86 process - thus also Oracle.DataAccess.dll must be the x86 version.
To cut a long story short: architecture of Oracle.DataAccess.dll must be the same as the application, i.e. your DLL.
Follow this instruction to run both in parallel:
BadImageFormatException. This will occur when running in 64 bit mode with the 32 bit Oracle client components installed
Update
In your *.csproj, resp. *.vbproj edit your reference to ODP.NET like this:
<Reference Include="Oracle.DataAccess">
<SpecificVersion>False</SpecificVersion>
<Private>False</Private>
</Reference>
Attributes like Version=... or processorArchitecture=... are not required. Your application will load the correct Oracle.DataAccess.dll depending on selected architecture and target .NET framework (provided that it is installed properly)
The easiest solution would be to target x86 - a 64-bit operating system can still load and run 32-bit applications, and so this would mean your app can run on both x86 and x64 machines.
The downside is that your app must run as a 32-bit processes, i.e. your process will have a 4GB maximum address space and cannot load 64-bit assemblies. If you try to load your dll in a 64-bit process (e.g. because IIS hasn't been configured to use a 32-bit app pool) you will get a BadImageFormatException.
If thats not acceptable to you then you could try detecting the process version and dynamically loading the correct assembly as per this Stack Overflow answer
All the above mentioned solutions are correct, but I just feel the need to mention Oracle.ManagedDataAcces as it does not care what the bitness is.
Our application is all 64 bit. We got ADODB provider to 3rd party database (nexusdb). It's 32 bit and consists of .NET library (which we reference just fine) and I beleive C .dll which is 32 bit. So, when we compile in 32 bit it works, in 64 it complains that it can't find C .dll.
How can we solve this issue without compiling our code to 32 bit?
EDIT:
3rd party DLL's as follow:
ADONET.dll - this is .NET native DLL that I reference and it references just fine.
ADONETProvider.dll - this is non-.NET 32 bit DLL that I just keep in bin/ folder.
I DO NOT want to compile my project for x86 because I reference many other projects and they all 64.
I want to make sure that ADONET.dll somehow called in "32 bit mode"
You have to use some kind of surrogate process and IPC to access a 32 bit dll from a 64bit process.
Some time ago I wrote the LegacyWrapper project that hides this behind a simple API call. You may want to see the corresponding blog post for technical details.
Edit: Since Version 2.1, LegacyWrapper also supports loading 64bit DLLs from a 32bit process.
I'm attempting to use a CAN device over USB that comes with a native DLL that needs to be wrapped by a .NET C# class (source code provided by the vendor) that gets included in one's project. Their sample applications target .NET 2.0 where my application targets .NET 4.0. I'm able to use the code in their sample apps and debug everything just fine, however, when I try to debug my application, I get a BadImageFormatException:
System.TypeInitializationException: The type initializer for 'TotalPhase.KomodoApi' threw an exception. ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
The only differences between their code and mine appears to be that their code is an application built for .NET 2.0 and (currently) my code is running as an MSTest unit test in .NET 4.0. Both solutions target AnyCPU. I'm running on a Windows 7 Ultimate 64-bit install. Even changing from AnyCPU to x86 didn't make any difference. How can I get this native DLL to load in an AnyCPU project?
If you get a BadImageFormatException when interfacing with a native DLL, it almost always means that you are trying to interface with a 32-bit DLL while running in the 64-bit CLR, or vice versa.
When you run the sample applications, do the processes have *32 in the "Image Name" column of Task Manager's "Processes" tab? That indicates the applications are running in the 32-bit CLR. Check your own application as well. It is possible that the machine you are testing on only has a 32-bit .NET 2.0 runtime, but both 32-bit and 64-bit .NET 4.0 runtimes, or the other way around.
If you are distributing a native DLL with your .NET application, then you should set your startup project to target x86 or x64 (as opposed to AnyCPU), depending on whether the native libraries are 32-bit or 64-bit. You can always ship both 32-bit and 64-bit versions, and let the installer choose which binaries to install based on the client architecture.
Alternatively, you can ship both 32-bit and 64-bit DLLs with different file names, define separate P/Invoke stubs for each version, and decide which one to call at runtime. The easiest way to do this would probably be to wrap your native calls in an interface (e.g., INativeMethods) and choose which implementation to instantiate at runtime based on IntPtr.Size. With this method, you could still target AnyCPU.
I'm trying to embed SQLite into my portable C# .NET 2.0 application rather than having the DLL files included in the distribution folder. However, to embed SQLite, I cannot use the Mixed-Mode libraries provided by PHXSoftware. Instead, I am using their 'Managed Only' version.
This works fine on 32-bit computers, but when it's running on a 64-bit machine, it throws a format exception. As I found out from here: http://sqlite.phxsoftware.com/forums/p/2564/9939.aspx I need to load the unmanaged sqlite3.dll manually in the required architecture format first before I use the managed libraries.
That's where I fall short. I cannot find a 64-bit version of SQLite to include along with the 32-bit one. Can anyone help? Dare I say, does anyone have any better ideas?
I'd recommend you build the source yourself. It's very straight-forward to do. Especially considering Sqlite offers amalgamation source.
Here are the compiler pre-processor defines I use for a 64-bit release build:
WIN64 NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
Here are the compiler pre-processor defines I use for a 32-bit release build:
WIN32
NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
The System.Data.SQLite fork has x86/x64 binaries for .Net 2, 3.5, and 4. Downloads are here.
Update:
Another possible solution is to target your application for x86 platform and just use the x86 SQLite libraries. If your application doesn't require x64 features targeting the x86 platform will greatly reduce the complexity of your deployment.
So I downloaded the .net 2.0 sp2 redistributable "NetFx20SP2_x64.exe" from the following site:
http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=5B2C0358-915B-4EB5-9B1D-10E506DA9D0F&displaylang=en
Deployed on my x64 win2k3 server from which I run IIS in x86 mode. On the same server I also run services and utilities in x64 bit mode.
So the question is easy, do I also need to install the "NetFx20SP2_x86.exe" version from the aforementioned link, or does the x64-bit include it already?
If you try to install NetFx20SP2_x86.exe on a x64 system you will get the following error message:
Cannot install on a 32-bit operating
system
If you have already installed the .NET x64 runtime, you actually get both x64 and x86 versions. The one that will be used depends on which platform the assembly is compiled against (the /platform compiler switch). For AnyCPU, it will use x64 otherwise, it will use whatever was specified.