在非开发机器上运行 vc2008 调试版本
我正在 vc2008 中构建我的应用程序并在机器网络上测试它。
除了安装 Visual Studio 2008 之外，还有其他方法可以在另一台计算机上运行 C++ 程序的调试版本吗？ （即没有安装vc2008）
安装redist包只会安装vc2008程序的发布模式支持DLL。 目前它抱怨“此应用程序无法启动，因为应用程序配置不正确。重新安装应用程序可能会解决此问题。”，我认为这是“我缺少 DLL”的代码。
I'm building my app in vc2008 and testing it on a network of machines.
Is there any way, other than installing Visual Studio 2008, to run a debug build of a C++ program on another machine? (i.e. that doesn't have vc2008 installed)
Installing the redist package only installs the release mode support DLL's for vc2008 programs. Currently it complains that "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.", which I assume is code for "I'm missing DLL's".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你不能，因为调试运行时没有安装程序 redist（事实上，软件许可证禁止分发它，所以即使你确实得到了一些东西，你也会违反 EULA）。 但是，“调试构建”通常涉及 4 个单独的选项，其他 3 个选项不会影响应用程序的分发。
生成 .pdb 文件（cl /Zi 和链接 /DEBUG），该文件允许符号调试。 您可能想将 /OPT:ref 添加到链接器选项； 链接器在不创建 .pdb 文件时会删除未引用的函数，但在 /DEBUG 模式下，它会保留所有这些函数（因为调试符号引用它们），除非您显式添加此文件。
我通常会对我的所有构建（甚至是生产构建）执行此操作。 只要您使用 /OPT:ref 重新打开链接器优化，就不会真正花费任何成本，并且如果您最终想要读取故障转储，则拥有这些符号会很方便。
使用 C 运行时库的调试版本（可能是 MSVCR*D.dll，但这取决于您使用的运行时）。 这归结为 /MT 或 /MTd （如果不使用 dll 运行时，则为其他内容）。
这意味着您无法再重新分发内容。 它还对一些库函数的性能产生巨大影响，特别是内存分配。 调试运行时版本会小心地“毒害”它们所接触的内存，以清除未初始化的数据错误，而发布版本通常会保留旧数据以节省接触它的时间。 我相信在 MSVCP* STL 实现中，调试版本也省略了通常完成的所有分配池，以便泄漏检查器可以准确显示您认为的块，而不是它已子分配的较大内存块，但这意味着它会在速度慢得多的情况下对 malloc 进行更多调用。 如果您有指针或迭代器处理错误，这可能会影响您得到的错误行为。
关闭编译器优化 (/Od)。
这个可以做很多事情（这个问题对该主题有一些很好的讨论），但基本上它会损害性能。 很多。 不幸的是，如果您希望单步运行顺利，则需要它。
设置预处理器#defines DEBUG 或NDEBUG。
这会以各种方式影响许多库，但最值得注意的是它编译或消除了断言（）和朋友。
因此，您可能会考虑使用这些选择的一些较小组合来进行构建。 我大量使用了具有符号（/Zi 和链接 /DEBUG）和断言（/DDEBUG）的构建，但仍然进行了优化（/O1 或 /O2 或您使用的任何标志），但保留了堆栈帧指针清除回溯（/Oy-）并使用正常的运行时库（/MT）。 它的性能接近我的发布版本，并且是半可调试的（回溯很好，单步执行在源代码级别有点古怪；当然，汇编级别工作得很好）。 您可以拥有任意多种配置； 只需克隆您的版本并打开调试中看起来有用的任何部分即可。
唯一会影响尝试重新分发应用程序的是 2。
如果您尝试在另一台计算机上进行调试，您可能还会对 msvsmon。
You can't, because there's no installer redist for the debug runtime (and in fact the software license forbids distributing it, so you'd be breaking the EULA even if you did get something put together). However, a "debug build" generally involves 4 separate options, and the other 3 don't affect distributing the app.
Generating a .pdb file (cl /Zi and link /DEBUG), which allows symbolic debugging. You probably want to add /OPT:ref to the linker options; the linker drops unreferenced functions when not making a .pdb file, but with /DEBUG mode it keeps them all (since the debug symbols reference them) unless you add this expicitly.
I generally do this with all my builds, even production ones. As long as you turn the linker optimizations back on with /OPT:ref it doesn't really cost anything, and having the symbols can be handy if you end up wanting to read a crash dump.
Using a debug version of the C runtime library (probably MSVCR*D.dll, but it depends on what runtime you're using). This boils down to /MT or /MTd (or something else if not using the dll runtime).
This is the one that means you can't redistribute things anymore. It also has a huge impact in the performance of some libraty functions, particularly memory allocation. The debug runtime versions are careful to "poison" the memory they touch with values to make uninitialized data bugs clear, the release ones generally leave the old data round to save the time touching it. I believe with the MSVCP* STL implementations the debug verions also omit all the allocation pooling that is usually done, so that a leak checker can show exactly the block you'd think and not some larger chunk of memory that it's been sub-allocating, but that means it makes more calls to malloc on top of them being much slower. If you have pointer or iterator handling bugs, this could affect what sort of misbehavior you get.
Turning off the compiler optimizations (/Od).
This one does lots of things (this question has some good discussion of the subject), but basically it hurts performance. A lot. Unfortunately, it's needed if you want single-stepping to work smoothly.
setting the preprocessor #defines DEBUG or NDEBUG.
This affects lots of libraries in various ways, but most notable it compiles in or eliminates assert() and friends.
So you might consider making a build with some lesser combination of these selections. I make a lot of use of builds that use have symbols (/Zi and link /DEBUG) and asserts (/DDEBUG), but are still optimized (/O1 or /O2 or whatever flags you use) but with stack frame pointers kept for clear backtraces (/Oy-) and using the normal runtime library (/MT). This performs close to my release build and is semi-debuggable (backtraces are fine, single-stepping is a bit wacky at the source level; assembly level works fine of course). You can have however many configurations you want; just clone your release one and turn on whatever parts of the debugging seem useful.
The only one that should impact trying to redistribute the app is 2.
If you're trying to debug on another machine, you might also be interested in msvsmon.
当然，您始终可以将程序配置为静态链接到 CRT 中，而不是使用 DLL。
这样您就可以避免必须确保正确安装调试 DLL 的麻烦（无论是在设置方面还是在无重新分发许可证方面）。
只需将“运行时库”的代码生成设置更改为“多线程调试（/MTd）”或在命令行上使用“/MTd”选项即可。
Of course you can always configure the program to statically link in the CRT in instead of using the DLL.
That way you avoid the hassles (both in terms of setup and in terms of no redistribution license) of having to make sure the debug DLLs are properly installed.
Just change the Code Generation setting for "Runtime Library" to "Multi-threaded Debug (/MTd)" or use the "/MTd" option on the command line.
阅读这篇博文 您需要能够运行应用程序的调试风格的文件以及从哪里获取它们。 但是，您不能正式将它们重新分发给第三方。
如果您有应用程序的安装程序，则还可以构建一个合并模块，以便在没有 Visual Studio 的计算机上部署调试运行时。 当然，这仅用于测试目的。 合并模块位于
C:\Program Files\Common Files\Merge Modules。Read this blog post on which files you need to be able to run debug flavor of your app and where to get them. You can't officially redistribute them to third parties however.
If you have an installer for your app, there's also a merge module you can build in to deploy the debug runtime on machines without Visual Studio. This is intended only for testing purposes, of course. The merge modules are located in
C:\Program Files\Common Files\Merge Modules.