C ++ MSVS，哪些文件＆QUOT;清理＆QUOT;我应该做的？ （CL错误：D8037） [英] C++ MSVS, what file "cleanup" should I be doing? (cl error: D8037)

问题描述

在C ++ MSVS2008工作，我一直有越来越多的刺激性问题：断点执行了错误的路线，不要再追等，这是一个非常大的工作空间与成千上万的文件，所以我忍了吧

Working in C++ MSVS2008, I've been having increasingly irritating problems: Breakpoints executing on the wrong line, not catching, etc. It's a really large workspace with thousands of files, so I "put up with it".

我是通过标准的东西（清洁，深干净，手动删除 * IDB ， *。PDB ， * IL * 等），它并没有解决断点 - 上错线的问题，但事情至少编译和我可以运行/调试。

I went through the "standard" stuff (clean, "deep" clean, manually delete *.idb, *.pdb, *il*, etc.) It didn't fix the "breakpoint-on-wrong-line" problem, but things at least compiled and I could run/debug.

然后，（对于不相关的原因），我创建了一个发行编译一个CPP到OBJ命令的命令行程序，并得到了一个奇怪的错误：

THEN, (for unrelated reasons), I created a command-line program that issued a compile-one-CPP-to-OBJ command, and got a strange error:

cl : Command line error D8037 : cannot create temporary il file; clean temp directory of old il files

我从来没有听说过此之前，让网络搜索让我到Microsoft网站，详细介绍了错误：

I never heard of that before, so a web search got me to the Microsoft site that details the error:

http://msdn.microsoft。 COM / EN-US /库/ bb385201（v = VS.90）的.aspx

嗯，咦？在我的系统 TMP 目录，有明显太多 _CL_hhhhhhhh.ss 文件。搜索，是的，我有完全相同 6,063 在该目录中这些文件，可以追溯到大约一年。

Um, Huh? In my system TMP dir, there were apparently too many _CL_hhhhhhhh.ss files. Searching, yes, I had exactly 6,063 of these files in that directory, going back about one year.

我从来没有听说过这些文件之前（临时编译程序文件）。搜索微软网站显示，这个错误是可能的至少的MSVS 2005年，2008年，2010年被临时文件，我认为有某种清除或回收的算法？

I've never heard of these files before ("temporary compiler files"). Searching the Microsoft site shows that this error is possible in at least MSVS 2005, 2008, 2010. Being "temp" files, I assume there is some kind of "cleanup" or "recycle" algorithm?

• 有多少 _CL_hhhhhhhh.ss 文件是极限？ （我在6,063有一个条件下，该错误。）

• How many _CL_hhhhhhhh.ss files is the limit? (I had this error under one condition at 6,063.)

为什么我看到这个错误，当我执行从一个EXE中编译，而不是从MSVS IDE中？ （我没有看到这个错误，当我执行命令行编译直接无论是。）

Why do I see this error when I execute a "compile" from within an EXE, and not from within the MSVS IDE? (I don't see this error when I execute the "compile" directly from the command line either.)

我应该通过清理文件一样做保养自己的计算机上，这些周期性的？

Should I be doing "maintenance" on my development machine by cleaning up files like these periodically?

其他克鲁夫特文件，做我需要考虑寻找和去除？

What other "cruft" files do I need to think about finding-and-removing?

顺便说一句，我知道，MSVS项目的GUID在注册表中缓存以便IDE可以找到了手动移动周围的修复链接/与其他项目文件的依赖性项目文件。我想知道如何清理掉这些呢，如果任何人有一个建议。

As an aside, I'm aware that the MSVS project GUIDs are cached in the registry so that the IDE can "find" project files that are manually moved around to "repair" links/dependencies with other project files. I'd like to know how to clean out those too, if anybody has a suggestion.

此的确实的导致的终极问题，从开发机器上使用MSVS积累什么样的隐藏克鲁夫特的？

This does lead to the ultimate question of, "What kinds of hidden cruft accumulates from using MSVS on a development machine?"

Win7的/ 64，C ++ MSVS 2008年，NTFS

Win7/64, C++ MSVS 2008, NTFS

推荐答案

<一个href=\"http://stackoverflow.com/questions/10560779/cl-exe-when-launched-via-createprocess-does-not-seem-to-have-write-permissions\">cl.exe当通过CreateProcess的推出似乎不具有写权限解决您的第二个问题。为什么你只看到它从一个exe内启动时？

cl.exe when launched via CreateProcess does not seem to have write permissions addresses your second question. Why do you only see it when launched from within an exe?

这是最有可能的cl.exe时在别处失败。如果您使用进程监视器，它会给你对cl.exe时所做的所有系统调用和失败是什么好主意。

It's most likely that cl.exe is failing elsewhere. If you use Process Monitor, it will give you a good idea on all the system calls made by cl.exe and what failed.

在我而言，我打电话时的CreateProcess是压倒一切的环境变量，并在这个过程结束了复位SYSTEMROOT环境变量。 cl.exe时用它来解决一些系统DLL，因此从来没有最终找到该DLL的路径。

In my case, I was overriding the environment variables when calling CreateProcess and in that process ended up resetting SystemRoot environment variable. cl.exe uses it to resolve paths for some system dlls and as a result never ended up finding the dll.

在短期内修复是添加SYSTEMROOT = C：\\ WINDOWS的环境设置，我突入CreateProcess的。

The short term fix was to add "SystemRoot=c:\windows" to the environment settings I was passing into CreateProcess.

右长期固定是获取环境变量，解析它们，只修改/添加的要求，并通过了整个环境变量块给CreateProcess。这样的话，通过的cl.exe推出的CreateProcess继承您的exe与推出的环境变量。

The right long term fix is the get the environment variables, parse them and only modify/append as required and pass that whole environment variables block to CreateProcess. That way, cl.exe launched via CreateProcess inherits the environment variables that your exe launched with.

这篇关于C ++ MSVS，哪些文件＆QUOT;清理＆QUOT;我应该做的？ （CL错误：D8037）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！