工程配置中的细节问题

可能你觉得这是一个很没有水平的题目，但是有些细节可能是你从未想过的:)
1． 你是否还是将编译中间文件输入目录保持为默认的Debug和Release（也或是其它中间文件默认的目录）并且放在源代码所在的目录下？如果是，你应该考虑看看我的建议。我的建议是将它们统统移到源代码文件目录之外，也就是$(SoluctionDir)之外，为虾米？如果你不能保证源代码不会被复制，你就应该这样做，当你在复制源代码时，臃肿的*.obj文件会让你感到恐怖，所以你不得不手工清除掉这些文件，然后再复制你想要的源代码目录，或许你不想删除，那还要将它们CUT来PASTE去，完成复制后再CUT，PAST回来，如果最初你就没把这些文件放在你的源代码目录下，你就用不着清除掉这些中间文件，并且，当你下次再在此机器上编译时，也用不着再从头编译一次了。推荐的做法，将ProjectConfig/General/OutputDirectory & Intermediate Directory设置为：$(SolutionDir)../tmp/$(ProjectName)/$(ConfigurationName)。这样你就可以很轻松地应付诸如上面提到的情况了。如果你的项目中还有Custom Build产生的文件，也记着将它们的Custom Build Step/General/Outputs设置到$(SoluctionDir)之外。有很多宏可能你也不曾注意，我们在设置工程配置时，有很多地方都可以按图1所示点击<Edit…>然后在图2中出现的对话框中点击下面的[Macro]按钮就能看到这些宏了，不过要注意在用它们时是要用“$()”包起来的。



图1


图2

2． 看看你的ProjectConfig/Linker/General/Output File是不是还是默认的形如这样的设置$(OutDir)/TestCase.exe，如果是，那你应该改改了，把Release版本改成$(SolutionDir)../Bin/$(ProjectName).exe，而Debug版本改成$(SolutionDir)../Bin/$(ProjectName)D.exe，这样的好处一是在于可以避免污染源代码目录，将编译的执行文件放到单独的目录Bin中，而使用宏的好处是在于以后复制，你可以把这段设置复制到一个专门的小文本文件中，下次直接复制，不用更改。不过，最好的办法不是复制，嘿嘿，我后面再说^^。

3． 注意你的ProjectConfig/C/C++/Language/Treat wchar_t as Built-in Type，如果编写DLL时打开这项，有可能其它工程设置不同的不能链接通过。还有ProjectConfig/C/C++/Code Generation/Runtime Library如果设置不一致，可能通过链接，运行时报些灵异的错误，也可能你DEBUG时看到灵异的数据。

4． 是否还在使用ProjectConfig/Linker/Input/Additional Dependencies设置相应的Lib文件？试试用这个吧：
#if defined(USE_DEBUG_LIB) || defined(_DEBUG)
# pragma comment(lib, "Lib/XUtilD.lib")
#else
# pragma comment(lib, "Lib/XUtil.lib")
#endif
这个预处理指令可以帮你省掉很多事。最好把它放在.cpp文件中，即使以后改起来也会不会影响太多的文件重编译。

5． 初始建立工程时打开ProjectConfig/General/Character Set为Use Unicode Character Set，这样会迫使你在字符串时加上_T(“”)宏。即使以后你需要编译成MBCS的工程也不会有什么麻烦，但是，如果你想从MBCS切换到UNICODE来编译时，你可能会遇到一大堆字符串转换的问题。
6． …to be continue