We Keep Coding

How do I register a .NET DLL for 64-bit application

I have an 64-bit application that uses a .NET DLL, and is returning an error from CoCreateInstance() saying "class not registered". (0x80040154)
Now, this has been running fine as a 32-bit application for a long time, and has no problem calling the .NET DLL, which gets registered as part of the installation, or on my development machine, gets registered as part of the build process. The recent conversion to 64-bit application has started causing this error (the rest of the application is now running fine as 64-bit, so no other issues there).
The application is non-managed C++. The DLL is managed C#, .NET 2.0, and is set to "Any CPU". Both are built in VS2010. My install package uses Regasm to register the DLL, and I wondered if maybe I needed a 64-bit version of regasm, however, I believe I am already using that. Visual Studio is also set up to register the DLL as part of the build process, but even running the 64-bit program in the debugger still cannot find the class.
What do I need to do to register the DLL so that the 64-bit version of the program can find the DLL through CoCreateInstance()?

Probably your installer uses 32 bit regasm from:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe
But it should use 64 bit regasm:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe

Why is LoadLibrary failing in some machines when calling a dll using P/Invoke?

I have a .NET application that calls a C++ API using P/Invoke. The C++ dll has a dependency from a third-party dll. That third party dll calls LoadLibrary to dynamically load libeay32.dll, an OpenSSL dependency.
After doing several tests I found out that the .NET application works correctly in Windows 10 but fails in some deployments using Windows 7. The cause of the failure is because the .NET process is not loading libeay32.dll. I tried placing libeay32.dll in the same directory as the process and in the System folder (having in mind the Dynamically load search order) but the failure persisted in Windows 7 32 bits only. Furthermore, if I called the API dll from a C++ console application it worked without issues in all platforms. To solve the problem I called LoadLibrary in the .NET application, before making the P/Invoke calls to the C++ API, and it worked in all target platforms (Windows 10/7 32 and 64 bits).
Why would LoadLibrary fail to load libeay32.dll in Windows 7 but not Windows 10 if called from the C++ dll dependency of the API called using P/Invoke?
Edit
Some notes from comments:
All the compiled assemblies are targeted for x86 architecture.
Before posting the question, I verified that no dependencies files
where missing, using dependency walker.

Likely because the dll is depending on some files that are missing. Use dependency walker and see what files it requires. Check on both systems. The tool will show you in red the missing files. Do not blindly copy the files.See what they are, what runtime or setup is required to deploy them, and deploy them properly.

.Net applications can be built with AnyCPU as their target and run in both 64 and 32 bit modes, but if you choose AnyCPU for your target the operating system will choose one based on it's preference. What this can mean if you have native dependencies is that the library that you're depending on can't be loaded because you're running in the wrong bitness. If you can constrain the application to the bitness you're expecting it might work better.

AnyCPu vs ODP.NET

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.

BadImageFormatException occurring when loading a native DLL in .NET 4.0

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.

WCF service library : BadImageFormatException with 32 bit dll

My project Structure looks like this:
myApp
-->WCFSerLib (Any CPU Deafult application)
-->ClassLib1 (Any CPU)
-->ClassLib2 (x86)
When I try to execute my application Unfortuantely am getting this below error.
System.BadImageFormatException was unhandled by user code
Is there anyway such that I can achieve the above?
Thanks

If I guess right than you are trying to use an x86 dll on a x64 mashine. With AnyCPU the .net framework will use the currient architecture automatically.
So your application runs as a x64 Application which tries to load a x86 libary which failes. So you have two options:
Set the target architeture to x86
Add/create a x64 libary
If you have both verions (x86/x64) somewhere in you envireonment variable the operation system will choos the correct one automatically.

I suppose that you are running your application on a x64 system.
Mixing the Platform Type in that way will cause the BFE when the WCFService Library or the ClassLib1 call methods in ClassLib2 because the first two run as 64bit processes while the latter is forced to run in x86 mode.
You should set the same platform type on every project.
Of course, the WCFService library supports only AnyCPU, so it make sense to use, for every project, the AnyCPU platform type.
If your ClassLib2 requires the use of a 32bit library (winscard.dll) and there is no 64bit version of that library, then, I think you should use a WCF Service Application instead of a Service Library. See this question

Thank you guys,
problem was with winscard.dll it uses Handles which are Int32
.all I changed is replacing the Int32 with Int64.