The project is a C # project with managed C ++ libraries.
Setting: x64 debug
Problem: When debugging, C ++ routines are not jumped in, even if there a
Breakpoint is set !!!
The C ++ dll and pdb files are up to date!
If a new routine is built into this C ++ library for test purposes,
there is a "Missing Method Exception" when this routine (method) is called at runtime
However, this new method is displayed in the object catalog!
The project is ported from VS2010. It worked there
It works in x86.
The project settings are the same in x64 and x68.
Related
So I recently finished a VC++ console application I have been working on and I sent it to one of my friends to try out but he cant even open it because he keeps getting an error.
A box will open up with the title Bad - Image and then it shows the error and stuff, it says it cant find the file MSVCP140D.dll on my friends computer but when I start the program it runs fine.
Can anyone tell me why he cant play the program and how to fix it?
You have built your project in debug mode and you are using Multi-threaded Debug DLL (/MDd) RunTime library.
In Visual Studio main menu, select Project -> Properties
Go to "Configuration Properties" -> C/C++ -> Code Generation
In Runtime Library, select Multi-threaded Debug (/MTd) and rebuild your project.
Alternatively you can build your project in Release mode, then select Multi-threaded (/MT) Runtime library.
This will make a stand-alone executable file which uses standard windows libraries, you won't have to provide additional dlls with the *.exe file.
You need to ship your program with the Microsoft Visual C++ Redistributable package. That's MSVCP140D.dll.
As user4581301 pointed out, the D in MSVCP140D.dll means 'Debug'.
You shouldn't ship a debug-enabled executable. It makes reverse engineering, hacking, and other modifications easier.
You should instead compile a release build, and ship it with the redistributable.
Well you need to do one thing(the easy solution), you just go to your system32 directory at system where you have built the code and find out the file MSVCP140D.dll, put it with your executable(.exe) and give it to your friend, and tell him to keep the dll in same folder as the exe.
MSVCP140D.dll (redistributable pack) is one of the run time dependencies you need to provide to run your application.
Now it will get installed. Or you can copy the dll at system32 at target system and then try.
But you shouldn't provide the debug build if you are giving it to client, you should provide the release version of it.
I am using a VS2015 to create DLLs which will be used in a project (which will be run on another PC).
I have build the DLLs in Release version on my PC but when I start the project on another PC, I get following errors:
VCRUNTIME140D.dll is missing
MSVCP140D.dll is missing
MSVCP140D.dll is missing
What steps should I take while creating these DLLs so that these debug runtime DLLs won't be required to the run the project on any PC.
In spite of it being built in release mode, if you require "...D.dll", then there are debug builds in the mix.
This could be the result of the third party dll you have or there are DEBUG or _DEBUG defines floating around.
Most likely is that the build (of the dll or the host exe) is explicitly set to use the debug version of the runtime (/MDd). Change this in the project settings to not use the debug version of the runtime (/MD).
Open the project's Property Pages dialog box.
Expand the C/C++ folder.
Select the Code Generation property page.
Modify the Runtime Library property.
To assist in the diagnosis of which binary is responsible for the debug dependency, you can use Dependency Walker to track down the offender. It will give you a list (as a tree) of the dependencies of each file.
In general, for missing the C++ runtimes (release version) on a target machine, you should install the C++ redistributable. As of this writing, VS 2015 redistributable is available here.
In C/C++ -> Code Generation -> set Runtime Library to:
Multi-threaded Debug (/MTd)
And yes, such setting is very much needed if you want to debug a process on a remote machine. So, don't go by others saying, "test with Release build only". Obviously, you'll need Remote Tools installed.
As stated by Niall, you should use dependency walker in order to find which part of the project is causing the error, it might not be the dll in issue after all.
My bet is it's just some part of the project you forgot and built in debug mode, which of should never be used for production as debug dlls are not included in C++ redistrib installers.
I wrote some C++ code. I sent it to my friend who isn't a developer. On windows 7 he got the error "the program can't start because msvcr120.dll is missing"
How can I build it so it will run? Do I need to use compile using MSVC 2008? 2005? I'd like this to work on vista+
I think you can statically link the run time library using /MT instread of /MD
see http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Right Click your project -> Properties -> C/C++ -> Code Generation -> Set "Runtime Library" to "/MTd" for debug and "/MT" for release builds
There are three projects:
project A (my project, WPF .NET 4.5)
project B (managed C++ with CLR (.NET wrapper for the FANN library))
project C (unmanaged project made in C, (FANN library))
In Visual Studio 2012 with project A opened, I can't step into to the project C through the project B.
Project B and C are free and open source and I have already built them successfully.
Project A references project B's DLL and project A won't run if the project C's DLL file cannot be found - so I have copied and pasted the DLL for the project C inside the project and set "Copy always" to the output directory.
When stepping into during debugging, I can get only to the project B's source code. I don't even see the project C loaded in the Modules window which I do not understand at all.
The project wouldn't run without the project C's DLL included and when it's included, it won't load but all the calls are working so it must be loaded somewhere.
I tried to include the project C's PDB file to the project A's output directory but no luck, function calls from project B to project C still get stepped over and never into.
Note that:
Just My Code is disabled
project C is included in the project B's in two ways - a "lib" file (in the linker settings) and its ".h" files in the source code are referenced... I don't know if that is the problem but you might.
I know there must be a way to achieve this, I have all the source code available but I'm no expert in C or C++ code, nor in debugging of it. I have tried including all the various project C's files from the bin directory to the project A but can't get it working.
Thanks for any help or advice!
If you're using Visual Studio, you have to explicitly enable debugging unmanaged code. You can do this from
Solution Explorer -> csproj -> Properties -> Debug -> Enable unmanaged code debugging
I have created a wn32 project with Visual Studio 2008 and Visual C++ language, it uses the ws2_32.lib library and then I compiled in Release mode.
It runs very good in the same computer, but when I copy the exe file to other computer (that doesn't have installed Visual Studio), it doesn't run.
The message I see is:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
But, if I compile my application using DEV C++, it generates a bigger executable (738KB) compared with the Visual Studio 2008 executable (9.5 KB). However, the DEV C++ executable runs in the other computer.
I have add the library ws2_32.lib to the linker properties of my project, in the Additional Dependencies field.
How can I fix it to work with Visual Studio 2008?
My code is the following: http://www.stan.com.mx/yupi/udpserver.cpp
The problem is almost certainly that the other computer does not have version 9 of the C++ CRT installed.
The default setting for compiling against the CRT in VS2008 is to dynamically link vs. statically linking. If you want to deploy your program with a real setup project you'll need to include the CRT redistributable.
However if you want to do an XCOPY deployment follow the steps on the following page.
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Try installing the Visual C++ redistributables. If that doesn't work, use DependencyWalker to find out what DLLs are missing.
I agree with JaredPar. The application you build with VS2008 is using dynamic linking, whereas the DEV C++ is linking statically, hence the larger size and why one works and not the other.
However, if its a plain win32 application project you've got (and you don't want/need to distribute it with a setup), you may be able to get it to run on another machine without redistributing the CRT by getting VS2008 to link statically for you (if its just the standard lib you're missing). I don't have a copy of VS2008 to hand, so I'll describe how to do it in VS2005 and hopefully it'll translate across.
Bring up configuration properties for the project (right click the project name, then select "properties" from the menu)
Expand "Configuration Properties", then "C/C++", then click "Code Generation"
Under the "Runtime Library" item, for your particular configuration select the non-DLL version of the library i.e. for debug builds you want "Multi-threaded Debug (/MTd) and for release builds you want "Multi-threaded (/MT)"
Try and see if that works. You'll obviously get a much bigger final binary now the library is statically linked.
You may be missing an external dependency required by your program. Check the project settings to see if you are linking against MFC dynamically for example. You can also run Depends utility to check for missing dependencies.