利用MFC向导建立一个工程，然后开始编码。这就是我通常做一个MFC工程的开始。但向导可不是一个守规矩的东西，它会为你添加很多的代码，为你设置大量的编译和链接选项。大部分时候这种工作是善意的，但是好心不一定办好事，你不好好了解它，它会给你带来很多的麻烦。

在配置一个基于OpenCasCade的程序中，我就遇到了很多麻烦。MFC向导在它所生成的View, Document等架构类中都添加了一段如下代码：

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

在Debug状态下（VS会为你默认添加一个_DEBUG的预编译项），你在该类中调用的new操作符都会被DEBUG_NEW所取代，请警惕这个行为，如果你重载过某个类的new，很可能就会由于它导致无法编译通过或运行不正确。

除此之外一些默认的设置也要注意，在VS2005中是默认支持Unicode的，它会在你的编译选项中加入/D "_UNICODE" /D "UNICODE"。这就会使得CString和你可能用到的std::string存在很麻烦的转换问题。你需要修改项目属性中General-->Character Set为not set，将其设为ununicode，保证与std::string的一致（当然你还可以运用其他的解决方法满足你的需求）。

有时候IDE也会“好心办坏事”，比如在一个解决方案中有两个工程，你为A添加B的编译依赖，在A的链接选项中就会悄悄加上对B生成的dll的引用。当你某天整理代码取消了这个依赖的时候，你突然发现莫名的出现了很多link错误。不要慌张，在A中添加上B链接项就好了，这项工作其实是你必须自己做的，只是你添加了依赖编译器非常主动的帮你完成了。

也许你看上面的错误都很简单，但如果不小心，也许有天也会像我一样深陷其中半天爬不出来。总之，在天天用VS2005建MFC工程的时候，提前做好两件事。一件是通读一遍系统默认生成的代码，做到心中有数，每一条莫名其妙的东西都要了解一下它的用途；另一件是在刚开始和改变了工程属性之后查看一下你的编译和链接命令，搞清楚它做了什么事，有时候命令行虽然难记一点，但确实是一目了然，你可以不必每天用命令行编译程序，但一定要对这些命令心如明镜，了如指掌才好。