You cannot, because there is no need to install the installer for the debugging runtime (and in fact the software license prohibits distributing it, so you violate the license agreement even if you received something together). However, a "debug build" usually includes 4 separate options, and the remaining 3 do not affect application distribution.
Create a .pdb file (cl / Zi and link / DEBUG) that allows symbolic debugging. You probably want to add / OPT: go to the linker options; the linker leaves unused functions when it does not create a .pdb file, but with the / DEBUG mode it saves them all (since debugging symbol links refer to them), unless you add this for this.
I usually do this with all of my builds, even production ones. As long as you turn on linker optimization again with / OPT: ref, it really does not cost anything, and the presence of characters can be convenient if you ultimately want to read a crash dump.
Using the debug version of the C runtime library (possibly MSVCR * D.dll, but it depends on what working environment you are using). It comes down to / MT or / MTd (or something else if dll runtime is not used).
This is one that means you can no longer redistribute things. It also has a huge impact on the performance of some libraty functions, in particular memory allocation. Versions of the debugging runtime try to “poison” the memory that they touch with values in order to clear uninitialized data errors, and the release usually leaves the old data round in order to save time concerning it. I believe that with the implementation of MSVCP * STL, debugging versions also omit all distribution pools that are normally executed, so the leak checker can display exactly the block you would think, rather than some larger piece of memory that it allocated but that means that it makes more calls for malloc on top of them much slower. If you have errors with a pointer or iterator, this can affect what kind of improper behavior you get.
Disabling compiler optimization (/ Od).
There is a lot to it ( this question has a good discussion of the topic), but basically it hurts the performance. A lot of. Unfortunately, this is necessary if you want the one-step mode to work smoothly.
setting up the #defines DEBUG or NDEBUG preprocessor.
This affects many libraries in various ways, but most notably, it compiles or excludes assert () and friends.
So, you might consider creating an assembly with some smaller combination of these choices. I use assemblies that use characters (/ Zi and link / DEBUG) a lot, and claims (/ DDEBUG), but still optimized (/ O1 or / O 2 or any flags that you use), but with stack frame pointers clear return traces (/ Oy-) and use the regular runtime library (/ MT). This runs close to my release build and is semi-cured (backtracking is great, the one-stage game is a bit confused at the initial level, and the build level works fine). You can have as many configurations as possible; just clone your release and include all parts of the debugging that you find useful.
The only thing that should affect the attempt to redistribute the application is 2.
If you are trying to debug another machine, you may also be interested in msvsmon .