I converted my visual studio solution from 2008 to 2010. A project has a reference to ShDocVw. When I run the program I get a BadImageFormatException. Googling led me to check the interop library with corflags:
corflags Interop.ShDocVw.dll
Version : v2.0.50727
CLR Header: 2.5
PE : PE32
CorFlags : 3
ILONLY : 1
32BIT : 1
Signed : 0
Sure enough, the 32BIT flag is set so my application built as Any CPU on 64-bit machine cannot load this library. If I run corflags /32BIT- I can turn off the 32BIT flag and everything works just fine. The question is, why is this Interop library generated with that flag set? I didn't have that problem with VS2008, this only started happening after the upgrade.
More importantly, how can I fix it so that I don't have to run corflags to turn the bit off? I assume that it is probably due to some MSBuild-fu that I don't understand very well. I haven't been able to spot anything, anyway.
The problem is that after the upgrade the <PlatformTarget> tag is not set in certain <PropertyGroups> in the C# project files and it apparently defaults to x86. So, to fix this go to the project Properties -> Build tab and set Platform Target to something other than AnyCPU, save it. Now set it back to AnyCPU and save it. The <PlatformTarget> will be written to the project with the value of AnyCPU and all is well.
Here is where I found the answer.
Related
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?
I know this has been asked in other places and answered, but I'm having issues with MS Visual Studio 2010. I've developed a C++ executable but if I run the Release version on a machine that doesn't have the VC++ runtime library (ie, msvcr100d.dll), I get the "program cannot start because msvcr100d.dll is missing from your computer" error.
This is weird for two reasons:
Why is it trying to link with the debug version of the redistributable?
I tried applying this fix, setting the runtime library setting to /MT instead of /MD (multi-threaded DLL), but that only made the problem worse (if I manually copied msvcr100d.dll, it then said it couldn't find msvcp110.dll).
How can I package the runtime library with my executable so that I can run it on machines that don't have MS VC 2010 or the redistributable installed?
I know it's considered a security risk to include a copy of the DLL since it won't ever be updated, but my goal is just to send this executable to a few friends in the short term.
You definitely should not need the debug version of the CRT if you're compiling in "release" mode. You can tell they're the debug versions of the DLLs because they end with a d.
More to the point, the debug version is not redistributable, so it's not as simple as "packaging" it with your executable, or zipping up those DLLs.
Check to be sure that you're compiling all components of your application in "release" mode, and that you're linking the correct version of the CRT and any other libraries you use (e.g., MFC, ATL, etc.).
You will, of course, require msvcr100.dll (note the absence of the d suffix) and some others if they are not already installed. Direct your friends to download the Visual C++ 2010 Redistributable (or x64), or include this with your application automatically by building an installer.
For me the problem appeared in this situation:
I installed VS2012 and did not need VS2010 anymore.
I wanted to get my computer clean and also removed the VS2010 runtime executables, thinking that no other program would use it.
Then I wanted to test my DLL by attaching it to a program (let's call it program X).
I got the same error message.
I thought that I did something wrong when compiling the DLL.
However, the real problem was that I attached the DLL to program X, and program X was compiled in VS2010 with debug info. That is why the error was thrown.
I recompiled program X in VS2012, and the error was gone.
This problem explained in MSDN Library and as I understand installing Microsoft's Redistributable Package can help.
But sometimes the following solution can be used (as developer's side solution):
In your Visual Studio, open Project properties -> Configuration properties -> C/C++ -> Code generation
and change option Runtime Library to /MT instead of /MD
Usually the application that misses the .dll indicates what version you need – if one does not work, simply download the Microsoft visual C++ 2010 x86 or x64
from this link:
For 32 bit OS:Here
For 64 bit OS:Here
I got the same error.
I was refering a VS2010 DLL in a VS2012 project.
Just recompiled the DLL on VS2012 and now everything is fine.
Debug version of the vc++ library dlls are NOT meant to be redistributed!
Debug versions of an application are not redistributable, and debug
versions of the Visual C++ library DLLs are not redistributable. You
may deploy debug versions of applications and Visual C++ DLLs only to
your other computers, for the sole purpose of debugging and testing
the applications on a computer that does not have Visual Studio
installed. For more information, see Redistributing Visual C++ Files.
I will provide the link as well : http://msdn.microsoft.com/en-us/library/aa985618.aspx
Okay, I am trying to add a .dll file to my application in Visual Studio 2010. If it is set for 32 bit, everything is fine. However, once I switch it to 64 bit, the library has a warning on it and wont load. I'm assuming the error "A single valid machine type compatible with the input type library must be specified" is related to the .dll not loading properly. It works fine if the application is moved up to .NET4.0 but I need to try and get this to work in .NET2.0. Any advice you can give on what is causing Visual Studio to not recognize the redemption64.dll would be greatly appreciated.
Make sure you project is set to build as "Any CPU", not x86 or x64 when you import the Redemption type library.
I work on a machine with win 7 32bit on visual studio 2010.
I tried to run in release mode a code that work fine on other computer(win7 64bit), and the following message came up:
The program can't start because msvcp80.dll is missing...
I tried looking up at threads dealing with this problem. tried to install diffrent Redistributable runtime versions. tried to copy those files(msvcp80.dll,msvcm80.dll, msvcr80.dll) to the project dir. and some diffrent things I don't even realised what I'm doing.
maybe some other ideas?
OK
thanks for your answers.
before i started the project i confirm all the build dll are 32bit.
I work on a 'opencv' project and narrow the problem to this one: the only problem occurred on opencv_imgproc230 lib function (like cvtColor, GaussianBlur)' what cause me to check with the program above(the_mandrill's link) the includes at this dll. it's include(or point I guess) for msvcp100.dll what seems reasonable because i work on VS10 enviroment.but even though it's screams for msvcp80.dll what belongs to VS80 I think.
by the way, when i manually include (msvcp80.dll,msvcm80.dll, msvcr80.dll) it's screams:
"R6034 An application has made an attempt to load the c runtime library incorrectly..."
It's seems that it's need to tell him to work with the VS10 version(for this dll's/runtime library)
Install Dependency Walker and run in 'Profile' mode (f7) which will show you the dlls it's looking for and failing to find.
This just means that you link agains MSVC C runtime dynamically.
So you have to install the so called redist package.
msvcp80.dll -> VC 8 -> VS 2005
X86 – http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en
X64 - http://www.microsoft.com/downloads/details.aspx?FamilyId=90548130-4468-4BBC-9673-D6ACABD5D13B&displaylang=en
The dlls where installed to a central place by the redisrt package and should be resolvable after installation.
Can you check to see if your dlls are 32bit ? Maybe you have the 64 bit versions.
See How can I test a Windows DLL file to determine if it is 32 bit or 64 bit?.
See this question.
You mentioned that you've installed the VC8 redistribute packages, but you may have missed the "correct" one.
You probably want: Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update
I need to build an MVC 3.0 site and target x64 specifically. I'm having an issue trying to build my MVC 3.0 site with the Platform Target set to x64 and MvcBuildViews set to True. Everything builds fine until it tries to compile the views. If I set the Platform Target to AnyCPU everything will compile, but when set to x64 I get this error:
Could not load file or assembly 'Mvc64Bit' or one of its dependencies. An attempt was made to load a program with an incorrect format.
This can easily be recreated by creating a blank MVC 3.0 project, unload the project, edit the project file to set the MvcBuildViews item to "true", reload the project, change the Platform Target in the Project's Build Properties to x64, and then build.
I haven't been able to find anything about the above error online, just that it deals with mismatched DLLs (one x32, one x64) but this doesn't make sense unless the view build engine is 32 bit or something.
Any hints to point me in the right direction will be GREATLY appreciated. Thanks for reading!!
I got a response from Microsoft on this issue. I guess what is happening is that Visual Studio calls a 32-bit compiler that compiles the website into a 64 bit DLL. After that, it calls the 32-bit compiler again for the views. The view compilation needs to load the 64 bit Web project DLLs to get information from the defined models. This is where the "Incorrect format" comes in. The 32 bit compiler tries to load the 64 bit Web project DLLs.
Now, calling the 64 bit aspnet_compiler.exe from the Visual Studio Command Prompt works perfectly. But, I guess, since Visual Studio is a 32 bit application, it can't load the 64 bit compiler. I'm not sure of any way to call the 64 bit, and even if there was a way, Visual studio probably couldn't give the nice list of errors that typically does (just an assumption there as I don't know how Visual Studio calls the compiler...a simple command line execution works, but maybe it actually loads the DLL and calls from inside the VS code)
So, my work around was to put the MVCBuildViews=true declaration inside the property. I then put MVCBuildViews=false in the 'Release|AnyCPU' propertyGroup and I just let IIS compile the views when the site first loads. It's not precompiling completely, but it will work.