Since the last update I can no longer connect to Oracle databases in "Entity Developer". (In Database Explorer)
So I can't update the database schema either!
I get the following message.
[Translated!]
"The attempt to load Oracle client libraries has thrown a 'BadImageFormatException'. This problem occurs when running in 64-bit mode if the 32-bit Oracle client components are installed."
I've been searching the internet for several hours for a solution, but couldn't find anything that solves this problem.
Various downloads/drivers etc. from Oracle that I tried to install did not work either.
Product: Entity Developer
Product Version: 6.8.1049
OS Version: Windows 10
Platform: x64
BadImageFormatException
-
muellermartin43
- Posts: 4
- Joined: Tue 01 Sep 2020 08:23
Re: BadImageFormatException
I have found a "solution/workaround" for the stand alone application.
Entity Devolper accesses the nuget packages in the user data. --> " C:\Users\[USERNAME]\.nuget\packages\"
If you add the nuget package "Oracle.ManagedDataAccess" (I have used version 19.8.0) to a project, the package is obviously stored in the mentioned directory and appears as an additional connection in the stanalone application of Entity Developer.
The connection is labeled with:
"Oracle Data Provider for .NET Managed driver [NuGet package 'Oravle.ManagedDataAccess' Version=xx.x.x]"
Unfortunately I have not yet figured out how to get this connection working in the Visual studio plugin.
Entity Devolper accesses the nuget packages in the user data. --> " C:\Users\[USERNAME]\.nuget\packages\"
If you add the nuget package "Oracle.ManagedDataAccess" (I have used version 19.8.0) to a project, the package is obviously stored in the mentioned directory and appears as an additional connection in the stanalone application of Entity Developer.
The connection is labeled with:
"Oracle Data Provider for .NET Managed driver [NuGet package 'Oravle.ManagedDataAccess' Version=xx.x.x]"
Unfortunately I have not yet figured out how to get this connection working in the Visual studio plugin.
Re: BadImageFormatException
You should install the package in your current Visual Studio project to make it available in Entity Developer integrated into Visual Studio.
If this doesn't help, specify:
1) target framework of your project (.NET Framework or .NET Core)
2) your model type (Devart EF Core Model *.efml, etc)
If this doesn't help, specify:
1) target framework of your project (.NET Framework or .NET Core)
2) your model type (Devart EF Core Model *.efml, etc)
-
windsorperma
- Posts: 1
- Joined: Wed 09 Dec 2020 06:53
Re: BadImageFormatException
The exception that is thrown when the file image of a dynamic link library (DLL) or an executable program is invalid. 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. In most cases you might be facing the problem with your website after deploying on server.
Make sure that you are not having 32-bit / 64-bit conflict. So, you need to adjust your application pool to Enable 32-Bit or 64-Bit accordingly. Set the Target platform setting on your c# EXE project, not your class library project. 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.
Make sure that you are not having 32-bit / 64-bit conflict. So, you need to adjust your application pool to Enable 32-Bit or 64-Bit accordingly. Set the Target platform setting on your c# EXE project, not your class library project. 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.