I try to integrate Web Camera support into C# solution. 1st of all I have learnt the nice example from Touchless.Vision. It contains C# solution with 3 components :
- one windows form project (C#, Any CPU)
- one wrapper project (C#, Any CPU)
- WebCamLib project (C++, x64)
I use Win7 x64.
So the example works fine. At least from the moment when I changes Platform target from Win32 to x64 for C library/project.
But then I have added two projects (C# wrapper and C++ project) under another C# solution. Now it always fails when it calls a method from C++ project.
System.BadImageFormatException was unhandled by user code
Message="Could not load file or assembly 'WebCamLib, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."
Source="Touchless.Vision"
FileName="WebCamLib, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"
FusionLog=""
StackTrace:
at Touchless.Vision.Camera.CameraService.<BuildCameraList>d__0.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Touchless.Vision.Camera.CameraService.get_AvailableCameras() in C:\CustomWare.NET\CustomWare\WebCamWrapper\Camera\CameraService.cs:line 40
The solution uses AnyCPU platform as well. I think there should not be any conflicts based on platform.
What can be the different between these two cases? What should I check?
The reason is that you're calling a 32-bit library from a 64-bit application. When using the AnyCPU configuration on an executable it will load as the OS type. 32-bit on a 32-bit machine, 64-bit on a 64-bit machine.
When calling a 32-bit library from a 64-bit executable there might differences in things like the data types which can lead to serious trouble. For example, C# specifies that a long is always 64 bits in size (it's an alias of System.Int64), while in C it's defined as at least 32 bits in size.
Or in your case, I assume the opposite applies.
So make sure to check whether your newly added C# library is indeed a AnyCPU or x64 project, and your C project is an x64 project. My guess is that the last one is not the case.
To provide a bit more insight on the subject:
AnyCPU is perfectly fine for # class libraries. It's the calling assembly that determines how to load an assembly. Thus, if you have a 32-bit application on a 64-bit machine calling an AnyCPU class library, it will load as if it were a 32-bit library.
In VS2010 the behavior changed compared to VS2008. When you create a Console, WPF or Forms application the target platform will always be x86 (32-bit). My suggestion is to use x86 unless you absolutely need or want to create a 64-bit version of your application. 64-bit applications have some benefits, and I'm sure that somewhere in the future the use of 32-bit applications will completely disappear, but because maintaining two versions doubles the time necessary to test the software, create releases, test those releases, and so forth, I usually don't bother creating a 64-bit version.
Rick Byers wrote an interesting article on this a while ago: AnyCPU Exes are usually more trouble than they're worth.
Related
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 have a C# application that makes use of a DLL as I need C++ to access some unmanaged functionalities of the user32 API (I cannot use PInvoke for that). I compile both the application and the DLL for x86 architectures, and everything works fine on Windows 7 32 bits. Now the problem is, on Windows 7 64 bits, the application crashes when I try to use the feature that relies on the DLL (but all the rest works fine).
I suspect that this is a 32/64 bits issue, so I tried re-compiling the DLL for x64 architectures, and now I can choose at runtime which DLL to load between the x86 and the x64. But it still crashes when I try to use the feature that relies on the DLL (which makes sense as I try to load a 64-bit DLL into a 32-bit program). I haven't tried yet to compile both the application and the DLL for x64. I suspect it would work, however it would require me to have two different installers, and I don't want to go there. Any clue?
When interoping with unmanaged code, you need to ensure your .Net app runs on the same subsystem (32-bit or 64-bit). As you've stated the DLL you're loading is for x86, force the .Net to build for only the x86 platform. This setting is found in your project's properties, on the build tab. The default is any CPU, change the setting to x86 to match your unmanaged DLL and you should be fine regardless if you run on a 64-bit or 32-bit OS.
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.
To complete some testing I need to load the 64 bit version of an assembly even though I am running a 32 bit version of Windows. Is this possible?
I'm not sure why you would want to do this, but I suppose you could. If you don't do anything to tell it otherwise, the CLR will load the version of the assembly that is specific to the CPU you are using. That's usually what you want. But I have had an occasion where I needed to load the neutral IL version of an assembly. I used the Load method to specify the version. I haven't tried it (and others here suggest it won't work for an executable assembly), but I suppose you can do the same to specify you want to load the 64 bit version. (You'll have to specify if you want the AMD64 or IA64 version.)
From CLR Via C# (Jeff Richter):
"If your assembly files contain only type-safe managed code,
you are writing code that should work on both 32-bit and 64-bit versions of Windows. No
source code changes are required for your code to run on either version of Windows.
In fact,
the resulting EXE/DLL file produced by the compiler will run on 32-bit Windows as well as
the x64 and IA64 versions of 64-bit Windows! In other words, the one file will run on any
machine that has a version of the .NET Framework installed on it."
" The C# compiler offers a /platform command-line switch. This switch allows you to specify
whether the resulting assembly can run on x86 machines running 32-bit Windows versions
only, x64 machines running 64-bit Windows only, or Intel Itanium machines running 64-bit
Windows only. If you don't specify a platform, the default is anycpu, which indicates that the
resulting assembly can run on any version of Windows.
32 bit Windows can not run 64 bit executables without a VM/emutalor
32 bit Windows can compile for execution on 64 bit Windows
No, you cannot run assemblies that are compiled for 64-bit on a system running the 32-bit version of Windows.