[转]把项目从VS2005升级到VS2013

原创做品，容许转载，转载时请务必以超连接形式标明文章  原始出处 、做者信息和本声明。不然将追究法律责任。 http://rangercyh.blog.51cto.com/1444712/1394348

小斯同窗花了几周的时间，终于把咱们的服务端和客户端从vs2005升级到vs2013了。真是不得不给个赞。

升级的过程当中遇到了各类问题，小斯同窗跋山涉水、越过艰难险阻终于成功让咱们用上了高大上的宇宙第一IDE——vs2013。因此这里我顺带把他升级中遇到的问题记录一下，也许对一些朋友是种参考。

首先，须要说明一下，以前在csdn上看到有人提了一个问题：为何好多游戏都用VS2005开发呢？原帖子在这里：http://bbs.csdn.net/topics/390645505

下面的回复也是五花八门。这里做为从业人员，我谈一下感觉，首先用vs2005仍是用vs2012甚至vs2013只是一个选择问题，换句话说，只要愿意，咱们能够拿什么乱七八糟的玩意开发都没问题。

再来讲下实际的，为何大多数游戏公司都用vs2005开发呢？我其实不知道那个楼主说魔兽世界和愤怒的小鸟是用vs2005开发的，但咱们的游戏确实是拿vs2005开发的，并且我知道的一些游戏公司也确实拿vs2005开发，那么为何呢？由于项目就是在那个时候建立的，而那个时候正好手头上熟悉的开发工具就是vs2005，愤怒的小鸟2009年发行的第一个版本，其开发公司Rovio公司成立于2003年，他们公司以前固然不会打酱油了，因此目测以前咱们用的不是vs2005，由于那个时候尚未vs2005呢，估计有了vs2005以后，他们公司升级到vs2005做为开发工具了，而vs2008要等到07年末才出来，若是他们的程序们不想升级，天然是没人会去升的，而魔兽世界咱们都知道是04年就出了，因此那个时候你总不能说他们的开发工具是vs2005吧。因此魔兽若是真的在用vs2005，那也是以后升级到vs2005的。至于为何不继续升级到vs2008或者是vs20十、十二、13等，个人见解是，没有需求。公司的目的是盈利，而若是从vs2005升级到vs2013没法提升收益，那么为何要升级，既然公司不会为你升级而发奖金或者是工资，天然没人闲的蛋疼去升级，还要处理一堆的升级以后的问题。

还有一点缘由，由于用户看到的那个程序并不是是由程序员来“控制”用什么编译的，固然这里的控制是打引号的，听我慢慢解释，在公司升级开发工具并不是跟本身玩玩同样简单，首先，通常公司编译代码都是配有编译机的，就是说程序员在本身本地用开发工具来编写调试代码以后经过各类版本控制工具，好比svn或者git之类的提交到代码库里，而后由编译机来编译出真正的供使用的版本，因此，若是你想升级开发工具就要同时升级本身的开发工具和编译机的编译配置，通常而言，公司的编译机都有专门的人来管理的，也就是所谓的配置管理员之类的职位，他们负责管理编译机，程序员固然能够在本地用各类开发工具进行开发，只要你可以保证代码编译没有问题，谁管你是用vs2013开发仍是用记事本在写代码？可是程序员若是想要控制输出到外网的版本是用什么编译工具来编译的话，就要说服配置管理员来升级编译机上的配置，而通常公司而言，这都是不可能的，由于程序员压根管不到配置管理员，若是不是项目经理点头首肯，配置管理员为何要听你程序员的，而程序员若是要说服项目经理，那么就要摆出各类厉害关系，好比vs2013如何碉堡（谁管你碉不碉堡）、如何能提升开发效率（尼玛不升级你效率就低下吗？）、vs2013可以给用户带来飞通常的体验（即便你信口开河，项目经理也不必定信）。即便你口才非凡的说服了项目经理，他赞成让公司花一笔钱把新的IDE买下来供你们使用，你还须要说服其余的程序员，由于你一旦修改了项目的编译工具，必然要影响到其余程序员的开发，固然咱们必须可以说服其余程序员，让他们改变开发习惯。总结一下：

一、你须要说服项目经理，让他申请花费一笔钱购买新的vs
二、你要说服配置管理员，让他更改编译机的配置，颇有可能你须要帮助他解决新配置下的各类问题，而也许你并不擅长
三、你须要说服别的程序员，让他们改变开发习惯，适应新的开发工具
四、最后你须要解决大家项目工程由vs2005升级到vs2013的各类诡异bug，保证升级以后大家的用户不会在使用上有问题。

固然，这是从程序员推进去升级开发工具，若是从项目经理推进的话，就容易的多了，一句话“大家都给我用vs2013开发”，其余的事情天然有人去完成了，程序员要作的不过是安装一下vs2013罢了。可是有多少项目经理是真正关心程序员拿什么开发，又或者程序最后拿什么编译的呢？呵呵！其实只有程序员关心这些。我相信全部跟我同样的程序员都是喜欢尝试新鲜事物的，因此不少状况下，你虽然看到的程序是用vs2005编译的，实际上我颇有多是用着vs2013在作开发，只不过编译给你的是vs2005编译的罢了：）

回到正题，咱们项目升级过程当中遇到了哪些问题呢？这里我分别挑几个显著的问题说一下：

工程自动转换
首先vs2013对vs2005的工程是兼容的，也就是说你能够直接用vs2013打开vs2005的工程，固然，vs2013会对vs2005的工程文件作一番转换。找到vs2005的sln文件，用vs2013打开完成转换后又日志报告，通常来讲不会有什么问题，若是你想仔细看也能够，点进去看就是的：

 

这里要注意一点，在转换sln的时候，咱们的vs2013挂掉了，最后咱们发现是有一个工程的vcproj文件里有引号字符的html代码，这个在vs2005下是能够识别的，可是用vs2013去转换它的时候却把vs2013给弄死掉了，去掉就能够了

工程设置上的不一样
还有一点就是在vs2005和vs2013工程配置里有好多默认设置竟然是不一样的，好比输出目录，vs2013的路径最后会添加一个 ‘\’，而vs2005下却没有。这个最初看上去没什么影响，可是咱们的工程本身定义了路径宏的时候添加了末尾的符号‘\’，致使在vs2013下路径就多了一个‘\’。

解决方案打开后通常来讲各个工程的组织结构不会变更，这个时候没关系着对整个解决方案进行编译，建议一个工程一个工程的编译，这样解决问题起来比较清晰。

vs2013和vs2005另外一个比较大的变化就是VC++的目录设置，在vs2005里面这个目录设置是针对全部工程的总设置，在Tools->Options->Projects and Solutions->VC++ Directories下，而在vs2013里，这个设置放到了每一个工程设置下，在Project->Properties->VC++ Directories下，位置变化到是次要的，问题是vs2013把不少头文件放到了系统的一个目录，并且文件内容还发生了变化。

系统宏的不一样
好比咱们用到了一个系统的宏：OutputDebugStr，它在vs2005的头文件里定义在vs安装目录下的平台sdk目录下的mmsysytem.h，而到vs2013下这个文件被放到了系统目录的sdk下，并且这个宏的定义还消失了。

解决办法也比较简单，在工程的预编译文件里添加一下这个宏的定义，注意兼容vs2005和vs2013版本就行：

1 2 3

#ifndef OutputDebugStr #define OutputDebugStr OutputDebugString #endif

其余未定义宏的解决方案也相似。只有有一类属于宏的定义值自己就不一样，好比，咱们遇到这么一个问题：

这个变量是定义在wingdi.h文件中的，可是在vs2013新的sdk下和vs2005的windows的sdk下这两个定义是不一致的，vs2005下是这么定义的：

vs2013下是这么定义的：

目前咱们的解决方案只是从新定义一下这个宏：

 

1 2 3

#if (_WIN32_WINNT >= _WIN32_WINNT_WINXP) #define CLEARTYPE_QUALITY 5 #endif

事实上，vs2013下windows的SDK版本和vs2005自带的SDK版本是有区别的，vs2013的SDK版本是0x0603，而vs2005的版本是0x0500。因此会有一批这种问题出现，其实你能够直接把这个版本号进行修改，这样就可使用vs2005下的版本内容了。虽然我不知道sdk是否向后兼容，不过应该是兼容的，能够试下。

命名空间的检查更加严格
咱们的程序引用了一个之前用C写的库，里面用到了一个结构体名字叫：is_base_of，结果没想到vs2013用的std命名空间里有一个同样的名字，因此咱们的解决方案是给咱们本身写的结构体加上了一个命名空间。

 

1 2 3 4 5

namespace  test {      struct  is_base_of {          ...      }; };

 

dx头文件的不一样
咱们都知道vs2013已经集成了dx的sdk，而不像以前同样单独发布dx的sdk，同时，vs2013把dx的头文件放到了系统的sdk目录里。在上面咱们提到过vs2013和vs2005的VC++目录设置不一样，vs2013包含了系统的sdk目录，这致使了一个问题。举个例子就明白了，由于咱们的客户端程序用到了dx9，而为了保证版本的一致性，咱们把dx9的头文件放到了工程目录当中，在vs2005下，咱们不须要特别指明dx的头文件目录，由于系统的默认目录里是没有dx的头文件的，不管咱们是用<>仍是""的方式来先查找系统目录仍是先查找工程目录最后都只能找到咱们工程的dx头文件，可是在vs2013下咱们必需要把咱们本身的dx目录放进工程的VC++目录里，这样才能保证咱们引用的是本身的头文件而不是系统的。顺带说一下，VC++目录和在C/C++选项卡下的附加包含目录有什么区别：

配置在VC++目录里的路径，在用 <> 包含的时候会优先查找，而配置在C/C++ 选项卡下的附加包含目录在用 "" 包含的时候会优先查找。

VS自带库的实现不一样
这个就比较纠结了，由于两个VS的版本存在差别，不免会出现库的实现不一样的状况，好比咱们遇到的一个问题：

咱们打开两个VS的安装目录下 VC\include   queue文件，对比以后发现，这两个queue的实现还真是差异大，咱们的问题在于本来是一个public的成员变量，如今变成了protected了：

不过好在变为protected以后，它提供了一个成员函数来获取它，这没办法了，咱们只能修改咱们本身的代码，把原来直接获取改成用成员函数来获取。

 

本文出自 “菜鸟浮出水” 博客，请务必保留此出处http://rangercyh.blog.51cto.com/1444712/1394348