I am not very experienced. Just trying to make some changes to source code that someone else wrote.
I had to add a reference to a .dll to get it to work in "Release" mode. However when I try to get it to work in Debug, it does not work. (assembly reference not loaded).
Help?
It looks like the Chillkat dot net is a actually a mixed mode assembly and it's quiet possible that you need to have the appropriate c runtime as well. This exception and a way to fix this is documented here
Hope this helps.
Typically I get this error when the executable is x86 and the dll it's referencing is x64. Check your build configurations to make sure it's targeting the correct platform.
In VS2013 go to Build -> Configuration Manager. There should be a drop down in the top left of the new window which contains the different build modes. Compare Debug to Release.
BadImageFormatException is one exception thrown from the execution engine when you are trying to load one assembly compiled for a specific platform in another platform.
Example A
- project A, compiled as X86
- project B, compiled as X86
- executable, compiled in X86
all work fine in x86 machine and x64 operating system
Example B
- project A, compiled as X86
- project B, compiled as X86
- executable, compiled in AnyCPU
all work fine in x86 operating system
this throw exception in x64 OS (executable is in AnyCPU so it's run on x64 engine, so can't load x86 dll's)
Example C
- project A, compiled as AnyCPU
- project B, compiled as x86
- executable, compiled in AnyCPU
all work fine in x86 operating system
this throw exception in x64 OS (executable is in AnyCPU so it's run on x64 engine, so can't load x86 dll's)
Example D
- project A, compiled as AnyCPU
- project B, compiled as x86
- executable, compiled in x86
all work fine in x86 operating system
all work fine in x64 operating system
the exe is compiled specifically for x86 platform, so also in x64 machine run under x86 mode.
Conclusion
Visual studio run projects in OS configuration, so in debug mode if you don't have a specific x86 configuration for starting project and try to execute an x86 referenced dll it will fail
Related
When compiling my Rust app in Windows 10, it is linked against ucrtbase.dll; however, this dll does not exist on some editions of Windows Server 2008 R2 Datacenter, making my app impossible to execute.
I tried setting -Ctarget-feature=+crt-static as found here, but it did not do anything; ldd app.exe still shows this dll.
Is there a way of removing the dependency on this dll?
If your Rust app does not depend on C libraries that specifically require the MSVC toolchain, you can build it for the x86_64-pc-windows-gnu (or i686-pc-windows-gnu, to build for 32-bit CPUs) target instead. This target links to DLLs that are available in all Windows versions.
For more information about the different Windows ABIs, you can check out this documentation page.
Here's the problem I got for Qt Application(Qt4\Qt5) calling Dlls from Fortran(CVF\IVF).
Qt4+Dll(CVF)+WinXp
It works fine in my PC both in QtCreator and as solo.
not working in other's (xp or win7/8)
the error is "dll not loaded" ( .isLoaded() false message)
then my PC's dead, got new one and immigrated to Qt5 with IVF.
But still the problem:
Qt5+Dll(IVF with complier_platform win32)+Win8
It works fine in my PC both in QtCreator and as solo
not working in other's (xp or win7/8)
the error is "dll not loaded" ( .isLoaded() false message)
Well, after trying them from various PCs:
I suppose it's not the platform problem(32bit or 64)
I am sure the dll path is correct when calling
Qt calling codes are
if(stlDll.load()){
myfun fun1 = (myfun)stlDll.resolve("STLDLL");
if ( fun1 ){
fun1(fileName_For90);
}
}
else
QMessageBox::information(NULL, "File Missing",tr("dll not loaded, the Directory is ")+dllPath, QMessageBox::Ok);
the error is always "dll not loaded", however that's the very right dllPath where I can find the dll with eyeballs but the Qt Applicaiton can not.
Fortran dll compiling codes are :
!DEC$ ATTRIBUTES DLLEXPORT,ALIAS::stlDLL
Typically DLL's compiled with Intel Fortran are dynamically linked to the Intel Fortran (and underlying Microsoft C++) runtime DLL's. Are your Fortran DLL's compiled and linked that way?
If so, you need to have the Intel Fortran runtime DLL's (and the underlying Microsoft C++ runtime DLL's) installed on the target machine.
You can get installation packages for the Intel Fortran runtime DLL's from the Intel website in the same manner that you acquire downloads of the compiler (or see here). You can get installation packages for the Microsoft C++ runtime libraries by searching the Microsoft website (they are Visual Studio version and service pack specific). Alternatively, merge modules and installation exe's for the runtimes may have been installed on your machine as part of the Intel Fortran and Visual Studio installations.
I am trying to build 4 versions of a 3D engine (in C/C++) with VS2010 (visual studio). The versions are:
32-bit debug
32-bit release
64-bit debug
64-bit release
When I'm building the 32-bit versions, I need to include these files in my project:
iceasm32.asm
igasm32.asm
When I'm building the 64-bit versions, I need to include these files in my project:
iceasm64.asm
igasm64.asm
Each pair of 32-bit asm files contains the same functions as the 64-bit asm files, but obviously the 32-bit projects must contain only the 32-bit asm files, and the 64-bit projects must contain only the 64-bit asm files.
My problem is this.
When I add the 32-bit asm files to my 32-bit (win32) debug and release projects, then run the 32-bit debug and release versions of the program, they work.
Then when I switch the IDE over to the 64-bit (x64) debug and release projects, the 64-bit asm files are no longer part of the project, but the 32-bit asm files are! So I exclude the 32-bit asm files from the 64-bit (x64) debug/release projects and add the 64-bit asm files, and then I can build and run those projects.
But then when I switch the IDE back to the 32-bit (win32) debug and release projects, they now contain the 64-bit asm files but not the 32-bit asm files!
Why is this happening?
Before my system disk crashed a while ago, I was developing this program with VS2005, and this problem did not exist. I could have different files be part of the 32-bit and 64-bit projects, and they would "stay put".
Why is this not working with VS2010?
I doubt it matters, but I only have C/C++ installed with VS2010. Not sure whether I had more than just one language with VS2005, but I only ever worked or programmed with C/C++.
Surely it is possible to have different sets of files for the 32-bit and 64-bit projects! Right?
For VS 2015:
You can right-click the masm-file in the solutionexplorer and select properties of masm-file.
There you can specify for each config(debug, release, x86, x64) weather the file should be used.
The file remains in the solutionexplorer, but is used/not used for different
configs.
I have a problem related to this question. Two players:
C# application
Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.
I have a c++/cli dll that I load at runtime and which works great in debug mode. If I try and load the dll in release mode it fails to load stating that one or more dependencies are missing. If I run depends against it I am missing MSVCR90.DLL from MSVCM90.DLL. If I check the debug version of the dll it also has the missing dependency, but against the debug (D) version.
I have made sure debug/release embed the manifest file. I read something about there being issues with the app loading the dll being build as Any CPU and the dll being built as x86, but I don't see how to set them both to x86.
I am using VS2010.
Anyway, I've been messing around for a while now and have no idea what is wrong. I'm sure someone out there knows what is going on. Let me know if I need to include additional info.
alt text http://www.freeimagehosting.net/uploads/fb31c0e256.png
UPDATE:
This ended up being the resolution to my problem: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/07794679-159b-4363-ae94-a68fe258d827
MSVCR90 is the runtime for Visual Studio 2008. If you are running your application on your development PC, then you should have the debug and release runtimes installed (as part of Visual Studio) but it is possible something has gone awry with your install, or that VS2010 doesn't actually include the older runtimes. If you're trying to run the Release on a different PC, then it just needs the runtime installed.
Either way, you may be able to fix it by installing the Visual Studio 2008 redistributable - but make sure you get the right download for your PC (x86 or x64).
In previous versions of VS, you needed the runtime for the version you were compiling with, so if VS2010 follows this precedent you'd need MSVCR100, not MSVCR90 - which suggests that you may not have recompiled the dll with VS2010 - doing so may be another approach to get it running on your PC (using the redist that is in your VS2010 install) but beware that you will still need other users to install the appropriate (VS2010) redistributable on their PC.
As for "Any CPU" versus "x86", this is a problem only on a 64-bit computer. On those systems a 64-bit application can't link dynamically to 32-bit dlls. If you compile your application as "Any CPU" it will be JIT compiled to be 64-bit on an 64-bit OS, so will crash if it tries to call any 32-bit dlls directly. THe solution is to build the application targeting "x86" as that forces the JIT compiler to generate 32-bit code (even on a 64-bit machine) and thus ensures compatibility with the dll you wish to call. If the DLL is a managed assembly, then you can use Any CPU on both the app an dll as they will both be JITted to the same format.
It happened to me something similar running a website in Vistual Studio 2012, after migrating from Visual Studio 2010. The error message was saying that MSVCR90.DLL was missing. The solution was:
1) Delete the folder _bindeployable located at the project path.
2) Rebuild.
I hope it helps.