I've got a C# dll and wanted to import it in stdafx.h (another DLL for JNI):
import "C:\Users\Marcus Tik\Documents\Visual Studio 2010\Projects\DotNETSpy\DotNETSpy\bin\Release\DotNETSpy.dll"
-> Visual Studio said: "Error loading DLL."
Then I used Dependency Walker which says Error: "Modules with different CPU Types where found."
Isn't it standard for a C# DLL to support different CPU Types?
How can I solve my problems ?
Thanx in advance!
If you want to check dependencies on a .Net assembly, better use CheckAsm instead of Dependency Walker (at least if you want to see the managed code dependencies, which you probably want).
You can compile managed .Net libraries to 'AnyCPU', so you usually don't have to worry about 32-/64-bit issues. But maybe your DLL depends on an unmanaged DLL, which may cause trouble if the unmanaged library is e.g. 32-bit and you're trying to run it on a 64-bit machine.
Change the Build option to x86, you might be trying to import a 32 bit OS dll into 64 bit environment.
Check out this link: Access x86 COM from x64 .NET
If your OS is 32bit and the dll is compiled exclusively for 64bit I think you get that result.
Trying to make the Debug version work is pretty pointless, you can't get the debug version of the CRT libraries deployed. Beware that Dependency Walker is running out of gas on modern executables, it knows nothing about manifests. It will always show them as missing, even when they are not.
The two solutions for this case would be to either use it as a private assembly or to statically link.
But remember, this is only for debugging and you should not distribute these files since it is agains the Microsoft terms.
Related
Introduction
I'm working on a .net project, in which I'm using some 32-bit version DLLs. The list of DLLs are:
System.*
Microsoft.*
AWSSDK.*
Npgsql.dll
Newtonsoft.Json.dll
Some other dlls from other vendors
(The list of DLLs is actually too long to be attached in this post without making it too long.)
Requirement
I require 64-bit version DLLs only and at the moment, I only have 32-bit version DLLs in our hand.
Things that I have tried
I verified the DLLs' version using a tool named SigCheck.
I tried to find/convert the DLL version using the following methods:
I searched on the internet and NuGet Package Manager but, I was not able to find 64-bit DLLs.
I tried recompiling the project to 64 bit by changing below setting under project properties:
- Build -> Platform Target -> x64
After compilation, the project DLL got converted to 64-bit. However, the remaining project DLLs' version didn't change.
Question
I would be grateful if someone could share documentation links/steps to convert 32-bit version DLLs to a 64-bit version?
or
Could someone please send us a link to find recompiled 64-bit version of the given DLLs?
Please note that I'm using .NET framework 4.6
Managed .Net dlls are usually platform agnostic. So for most of the libraries you do not need to worry about it, just use nuget to refer to the libraries and you should be good to go. The JIT compiler will take care of compiling the assemblies to 64/32 bit depending on the platform.
The platform target you specify when compiling a dll only sets a flag in the dll. This flag can be changed with CorFlags, but if it has a 32-bit flag it might be for a reason.
The big problem usually occurs when you need to use native assemblies (i.e. c++ dlls). These need to be platform specific. The best solution is to get 64-bit versions of these DLLs, but you would need to get them from the vendor of the libray and update the references in your projects. The most common workaround if you can not get a 64-bit version is to run the library in a separate 32-bit process.
I've read many questions and answers indicating that if I want to link my C# project against native libraries, I can't use AnyCPU platform target but must make separate 32- and 64-bit builds, each linked against the native DLL of the appropriate bitness.
This makes me wonder how the .NET Framework assemblies themselves are, or at least appear to be, built for AnyCPU. That is, when adding a reference to my GUI application, why don't I have to pick the 32-bit or 64-bit version of System.Windows.Forms? I thought this might just be some Visual Studio magic that would resolve to the appropriate GAC subdirectory (GAC_32 or GAC_64), but I searched for System.Windows.Forms.dll in the GAC and found it in:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll
Note the "GAC_MSIL". So how does this DLL manage to wrap a native 32-bit API yet remain linkable in a 64-bit application? And why can't I use a similar strategy to make a single C# DLL that links against a native 32-bit library yet remains runnable in 64-bit mode?
Option 1: In GAC you may register 2 versions of assembly one 32 and one 64 bit with exactly same names. Oracle DB Driver for .NET uses this strategy.
Option 2: With your assembly that will be AnyCPU deploy two versions of native DLL and choose proper DLL at runtime (SQLite works like that). As it turns out .NET Framework is intelligent enough to load proper version of native DLL via P/Invoke (Using a 32bit or 64bit dll in C# DllImport)
I had the same problem and ended up using Fody Costura
DLL Files will be shipped as embedded ressources and the lib takes care of the bitness.
You could find an example for SQLite here
The problem I have encountered was that your application needs to have access to the Windows Temp folder to create the assemblies from the ressource. If you dont need it, you could disable it using a config setting createtemporaryassemblies
I have a mixed-mode C++/CLI project which is compiled as x86 and x64 frozen dlls.
I have a C# app that needs to use this project which is compiled as "Any CPU".
How can I properly reference the correct dll from the c# app?
If I right click add reference I must select only 1 of the 2 dlls.
My "ANY CPU" C# app will sometimes run as x64 and sometimes as x86 process.
I've heard you can maybe do this via a smart config file.
There are several ways to deal with this. First one is simplest, acknowledge the fact that your app actually does have a dependency on the target architecture. And that AnyCPU isn't the proper setting. It is very rare to need the humongous virtual address memory space you get from x64, especially since you also want and need to make it work on x86. So set the Platform target of the EXE to x86 and you're done.
Second is concluding that this is simply a deployment problem. All you have to do is copy the x64 build of the mixed-mode assembly when your app is installed on a 64-bit operating system, the x86 build on a 32-bit operating system. You'll need to create a Setup project that takes care of this. The simplest way is to create two of them. Also the only way afaik.
Third is the one with bells on where it works either way, the one you no doubt are asking about. This requires changes to code, project and installer. What you need to do is write a post-build event that create two subdirectories with names like "x86" and "x64". And copy the respective version of the DLL into them. This ensures that the CLR cannot find these assemblies.
In your code you must write an event handler for the AppDomain.CurrentDomain.AssemblyResolve event. Subscribe it in your Main() method, well before you try to use any types from the assembly. The event handler must use Assembly.LoadFrom() to load the correct assembly from the subdirectory, based on the value of IntPtr.Size. It is 8 when you run in 64-bit mode.
I should mention yet another approach but that's generally frowned-upon at SO. Install both assemblies into the GAC. Everything is automatic.
Even if your C++ project compiles twice it should have the same managed interface for both x86 and x64 DLL's. Hence as long as your not using strong name signing it shouldn't matter which version of the DLL you reference. What's important is that the correct version is deployed on the target machine.
I've got a C# 2.0 project which is set to target 'Any Cpu', however it is referencing a C++ project that's building a 32 bit dll.
When I try to run my program on a 64bit machine I get the following error:
System.BadImageFormatException was
unhandled Message: Could not load file
or assembly TreeTMHook,
Version=1.0.2889.19619,
Culture=neutral, PublicKeyToken=null
or one of its dependencies. An attempt
was made to load a program with an
incorrect format.
How can I fix this?
Update
I want to be able to keep the main project as any cpu.
Thanks.
You'll need to build your .NET project as 32bit (x86 target) if you want it to correctly load a 32-bit DLL on a 64bit machine.
RE: Update:
If you want to keep your project as "Any CPU", you'll need a 32bit and a 64bit version of the DLL, and make sure the appropriate version is distributed with your app. If you can't build the other project as 64bit, you must build your .NET project as 32-bit only.
You will have to force your EXE project to run in 32-bit mode so it can use that C++ DLL. Project + Properties, Build tab, Platform Target = x86.
You may want to take a look at this article it explains why it is not possible, in short since you are dealing with pointers when accessing unmanaged code.
To keep you main project as Any Cpu, you need to supply both 32 and 64 bit version of the .dll - which should be possible, seeing as you're building it from source.
You then need to supply the executable with a manifest pointing it toward to right dll verion depending on platform.
Please use .net reflection and consume objects and its methods. Instead of direct 32 bit dll reference.
I have a dll. and visual C++ source for it. (my dll is visual c++ wraper around some ffmpeg av* libs - another precompiled dll's) while in the same solution (.sln) I have C# project that uses my dll.
what are general steps for me to port my project to mono?
Mono does not support mixed-mode assemblies on non-Windows operating systems.
Remove your C++ wrapper and rewrite your application to only use P/Invoke to call into native code.
See also: www.mono-project.com/CPlusPlus
Compile your project in Visual Studio, but enable the following compiler options:
/clr:pure: This will make a pure CLR assembly (without any x86/x86-64 asm), that should run on mono, unless you use some C runtime calls (CRT).
/clr:safe: The same as pure, but you can't have CRT references, so your project might not compile. If it doesn't, replace those function calls with other portable calls.
The resulting assembly should be pure CLR and will work with Mono.
This page contains everything you might encounter when compiling a version that works on Mono.
I would suggest also take a look at this -
http://mono-tools.com/store/
There are various tools available to help you port to Mono - you can even debug within visual studio and package it for deployment on Linux.