I was asked to download the specified DLL after running one of my apps on a secondary computer. The only problem is whether or not it should have been required. I obviously code in Visual Studio, but it is in pure "C" and a Win32 project, so I'm just wondering if this is normal.
if you don't want to load CRTs, change run time library to static library. (MT)
or you need these dlls in installed visual studio\VC\redist
//after your comments//
MSxx##D.dll D means Debug.
if you link any library built with debug run-time, the exe needs debug runtime library
Related
I made a Windows application with C++ WinAPI by using Visual Studio 2019.
After finishing, I built it, and executed with my computer. It works perfectly.
Then I sent to my friend who didn't have Visual Studio. It said that it needs "msvcp140d.dll" "ucrtbased.dll" "vcruntime140_1d.dll" "vcruntime140d.dll" to open it.
Then I found them in my computer, put them in the same dir with my application, and sent them to my friend. It worked fine, too.
But My question is "Is there any way to pack them with just Visual Studio 2019?" A small application with lots of DLLs is just a little bit weird.
First you're sending the wrong files. Files with d suffix like that are for debugging only and must not be distributed
You cannot redistribute all of the files that are included in Visual Studio; you are only permitted to redistribute the files that are specified in Redist.txt or the online "REDIST list." Debug versions of applications and the various Visual C++ debug DLLs are not redistributable. For more information, see Choosing a Deployment Method.
Determining Which DLLs to Redistribute
Final executable files must be compiled in release mode and use the release version of those DLLs. Don't give out debug binaries. They're seriously slow due to the logics added for debugging purposes
And you don't actually need to send the DLLs but you should tell the user to install the corresponding VC redistributable package. It's the runtime (CRT) for Visual Studio projects containing functions like printf, memcpy... for you. You don't need to find any other DLL if you don't use any DLLs in the project
It's also possible to link the runtime library statically by changing the option /MD to /MT. That way the final exe file will be self-contained (no need for additional runtime DLLs) but it'll also be larger and you lose the ability to use the newer library functions when the package is updated to fix bugs or performance issues. Again, you must compile in release mode regardless of whether you're linking statically or dynamically
See also
Compile to a stand-alone executable (.exe) in Visual Studio
Compile C in Visual Studio 2012 without MSVCRT runtime
How to make a Single Executable VS 2010
I wrote a basic program for my mom, and now I want her to be able to use it. Obviously, it works on my computer. Getting the .exe file from the project folder, and putting it on her computer doesn't work: it says MSVCR120d.dll is missing whenever the .exe is run. Makes sense--as her computer doesn't have Visual Studio on it. However, I tried installing the Visual C++ Redistributable Packages for Visual Studio 2013, and that didn't work either.
To be honest, I'm not looking to spending hours of time to piece this all together. This is something I will more than likely never do again--I've already done some searching and can only find subjects speaking of C++ distributions. I want a way to get the console app on her computer to work.
The more easy way is link statically. That mean embed all the needed code to the app to run, in the final binary (.exe), eliminating dependency of other libraries.
Go to Project Properties
Go to Configuration Properties
Go to C/C++
Go to Code Generation
Change Runtime Library (in Debug to Multi-Threaded Debug /MTd and in Release to Multi-Threaded /MT)
I have an existing C application that I debug in Visual Studio, and I want to access certain library functions in it. When I compile the library from its c++/cli source to a .lib I can compile it with or without clr support (the /clr flag.)
If I compile the library with clr support, and link it in with the rest of my application, the debugger can no longer stop at specific lines of code that are not in the library compiled with clr support.
If I compile the library without clr support and link against that library, everything works just fine with the debugger.
We need to compile this library with clr support, and I don't want to lose the ability to debug the rest of the program. Can anyone tell me why I lose my debugging ability when linking with the /clr compiled library but not the other one? Does nayone know how to properly compile / link so that I can keep my debugging ability?
Since the new executable contained a mix of native and managed code, you have to attach both types of debuggers to it. In Debug -> Attach to Process... I selected the process as well as the types of debuggers to attach. In this case, managed (v 4.0) and native.
Answered in greater detail here.
I'm trying to debug a C/C++ native DLL project from Visual Studio 2010. I'm attempting to follow these instructions:
http://msdn.microsoft.com/en-us/library/c91k1xcf(v=VS.100).aspx
I want to use the built-in debugger and be able to step code, examine structures, etc. as I would do with a regular .exe project. The instructions on the page above describe a Debugging category under Configuration Properties which I do not see.
http://img707.imageshack.us/img707/4402/lalasz.png
Just pressing F5 to debug results in the following error:
Unable to start program 'C:\Users.......Test.dll'
I've used the debugger for regular .exe projects many times and it works fine on this computer. I'm not sure if I'm just missing something very obvious right now though.
Edit: Since I didn't make it clear from the start, I want Visual Studio to LoadLibrary my DLL into a stub process and let me debug at a source level from there, much like how OllyDbg does it.
My DLL is not the type that holds a bunch of functions to be exported and called. Instead it does a switch/case in the DllMain and on DLL_PROCESS_ATTACH will spawn a new thread. Therefore all I need Visual Studio to do is to load my DLL into a stub executable and allow me to set breakpoints, etc.
You probably have as the startup project the one that produces the dll.
You have two choices: either change the startup project to another project that produces an executable that uses that DLL, or configure from project properties the debug settings for the dll project to start an external application that uses that dll (Project Properties/Debug/Command).
Native DLLs cannot be run standalone - they must run in the context of some program. See this part of the instructions page you referenced.
"If you start debugging from the project that creates the DLL, you must specify the executable you want to use in debugging the DLL."
You right-clicked the solution name in the Solution Explorer window and got the solution properties. Note that the window says "Solution Test Property Pages".
Right-click the project name (Test in bold) instead to set the project options.
You would run into this problem from a Managed project also. What Visual Studio is telling you is that it cannot run the DLL, just the same as you cannot double-click a DLL from Explorer, and have a program run.
In order to debug the DLL, write a small console application which calls functions from your DLL and exercises your code. If your DLL has a function foo(), call foo() from main in your console application. Set the console application as the "Startup" project, by right clicking the project name in the Solution Explorer and selecting its option.
Then, when you press F5, you will run the console application, which will call the DLL.
Here is my situation:
I have a C project linking with many libraries (I haven't written this application), and it is shipped also with MSVCR71.dll and MSVCP71.dll. Even without those DLLs, the program has run fine on my system, which has MS VS2005 installed (indeed uses MSVCR80.dll and MSVCP80.dll).
I've linked this application with other libraries, compiled on my system. Now, after having linked with those libraries, the application don't start because it cannot load MSVCR80.dll and MSVCP80.dll... very strange, I say.
Loader presents to me the error R6034, which should be solved building applications using the manifest file.
What's wrong with this application?
Confirm that the problem was introduced by the libraries introduced. May I compile those libraries without manifest or statically?
Still curious why application without linking new libraries don't find MS runtime DLLs...
MSVCP71.dll is a dll used by Visual Studio 2002. MSVCR80.dll is for Visual Studio 2005.
So, when you recompiled this app with VS2005 you got new dll dependencies.
You cannot solve it with manifests - you should recompile it in Visual Studio 2002 or just put these new dll's into the same folder where you app is located.
Edited:
And yes, you can just link your application with static CRT libraries to avoid external dependencies on these dll's. But it may be not possible if one of dll's or libraries that you link with uses dynamic CRT - you should recompile them also with static CRT then.