我把程序从VC6和 VS2003 移植到VS2005时, 遇到了一些问题, 这里讲的是XP风格化的问题:
为了实现界面的XP风格化, 需要有一个manifest文件XPStyle.manifest(见附文).
可以添加到项目资源中, .rc文件中会添加一个ID:1 type:manifeset的资源;
可是, 这个资源ID在VC2005里会提示资源冲突(VC2003不会冲突).
在百度搜索, 发现了一个网友提供的方案: "项目属性"--"清单工具"--"输入和输出"--"嵌入清单"--"否" ;
但是, 这个方案对我来说有不足, 会引起其他问题, 比如动态链接MFC的程序, 执行时会提示找不到MFC库文件,
可我的电脑可是装了VS2005的,怎么没有库? 试了几次, 就是这个清单的问题.
如果选择不生成清单文件, 那么界面风格就不是XP化的.
查MSDN后, 发现MSDN已经提供了解决方法:
在 Visual Studio 开发环境中设置此链接器选项
打开此项目的“属性页”对话框。有关详细信息，请参见设置 Visual C++ 项目属性。
单击“链接器”文件夹。
单击“嵌入的 IDL”属性页。
修改“类型库资源 ID”属性。(我设置为100,OK!)
这种方案也算是个好方案, 但是需要去修改.RC文件里面的资源ID.
最后推荐一种方法:
不要将manifest文件添加到项目资源中, 有两种做法:
1. 在"项目属性"--"清单工具"---"输入和输出"---"附加清单文件"--在里面填入XML文件的位置;
比如我的文件位置: $ (ProjectDir)\res\XPStyle.manifest
2. 直接把文件添加到项目的文件列表中(不是导入到资源中).
[附manifest文件内容]
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Microsoft.Windows.M8000"
type="win32"
/>
<description>SetM8000</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
本人检验，最后推荐这种方法确实有效，谢过。
————————————————————————————————————————————
将以前的代码在vc2005下编译，经常会遇到类似如下的警告: warning C4996: 'strcat' was declared deprecated. 通常这类警告都是由于调用了字符串相关函数引起的。虽然这警告无伤大雅，仅仅只是说使用的函数已过时(deprecated)<需要用新的 函数来替代>,但看着实在别扭,且看看ms为什么要设置成这样。
搜索了一下ms的网站，找到了结果。ms认为以前的c/c++库中有一部分函数不够安全，希望程序员可以使用他们的替代安全库(Safe Library)来避免不必要的隐患。 整个原文请点击以下链接访问:Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ Libraries
在网上搜索到的最常用的解决方案，那就是定义 _CRT_SECURE_NO_DEPRECATE 和 _SCL_SECURE_NO_DEPRECATE 来禁止vc2005对此产生警告(依然使用的是非安全库！显然并不是一个好的解决方案)。而且如果使用了ATL,则还需要定义 _ATL_SECURE_NO_DEPRECATE， 使用了MFC则需要定义 _AFX_SECURE_NO_DEPRECATE。然而尽管如此，更好的解决方案只需要定义一个宏 _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES, 那么vc将会自动替换使用他们的Safe Library来代替C/C++标准库(如strcat将被strcat_f来取代)。
即使使用了_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES，代码将依旧不够安全:(, 对此，ms提出了如下10点建议:
1. 不要认为 strcpy_s 和 strncpy_s( 以及其他的字符串函数)(在空间不够的时候)会自动终止拷贝(truncate截断，不截断则意味着溢出).如果需要自动截断，请使用strncpy_s (同时使用_TRUNCATE作为长度参数)。
2. 记住fopen_s缺省是独占模式。如需共享使用文件，应该使用_sopen。
3. 别忘了_dupenv_s, 它将比_getenv_s更容易使用，因为它能自动分配一个正确长度的内存(buffer)。
4. 在scanf_s中小心参数顺序。
5. 确定printf_s中格式字符串的正确。
6. 使用_countof(x)来取代sizeof(x)/sizeof(element). _countof将会正确的计算元素个数，而且如果x是一个指针，编译器将会发出一个警告(来提醒程序员,仅针对C++编译)
7. 记住所有的sizes(大小,非长度)都是使用characters(字符，unicode下一个字符占2个byte)作为单位，而不是bytes(字节).
8. 记住所有的sizes(大小，非长度，缘由同上)包含了字符串结束符'"0'(即别忘了很多情况下size需要+1)。
9. 调试的时候监视数据0xfd。 (在调试版本下)0xfd将会被填充在数据(buffer，通常是字符串)的结尾处。如果运行非你所愿，可能会得到一个长度错误。
10. 检查所有的错误。 许多新函数相比旧函数,能返回(表示)错误信息(的数值)。
今天在把以前的项目port到VC2005上来时，碰到了不少问题，大都和字符处理相关。VC2005中默认的字符处理函数都是调用双字节版本，而且直接在代码中输入的字符串都默认为双字节的。
在项目的转换Log中发现这一段：The C/C++ compiler default settings have been modified to be more compliant with ISO Standard C++. Included in those changes are enforcing Standard C++ for loop scoping and supporting wchar_t as a native type. These changes may cause existing code to no longer compile without changes to the code or the compiler options with which it is built.
Standard C++ 有要求wchar_t作为默认的字符类型吗？只好先在Project->Properties->Configuration Properties->C/C++->Language中的选项"Treate wchar_t as Build-in Type"设置为No
还有一点就是VC2005的CRT用的是新版的Security-Enhanced Versions of CRT Functions,有关字符串处理的相关函数都被建议用后缀加上"_s"的版本，这样的话，在从以前项目的转换中会出现一大堆的warnings，做好 的解决办法是：在预编译头文件中的任何include之前加入:
//for Secure Template Overloads of Security-Enhanced Versions of CRT Functions
#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1
定义这个宏就会默认使用Security-Enhanced CRT，即使你的代码中用的并不是加后缀_s的函数版本，因为它在库中使用了一个小技量：函数重载。
但是即使你完全按照上面的做了，在编译代码的时候还是会出现一大堆烦人的warnings，你可能会说“我不是已经用新版的CRT了吗？” 是的，没错！那是在链接的时候做的，但是编译器在编译你的代码的时候并不清楚，它只认你上面写的是什么，没"xxx_s";，就给你好看！不让它们出现有 两种办法，我们首先想到的就是可以在预编译头文件里加上#pragma warning (disable :xxxx)，这样也不失为一个处理的办法。另外一个是VS2005自带MSDN中说明的办法，同上，在stdafx.h没include任何头文件之前 定义一个宏:
//for no more warns about the Security-Enhanced Versions of CRT Functions
#define _CRT_SECURE_NO_DEPRECATE
【系统分析】【编译】【代码升级】升级到Visual C++ 2005库要注意事项
Visual C++库的十项突破性变化</p><p>Visual C++ 2005库已经发生了一系列的变化，可能会对现有的程序有所影响，在升级到Visual C++ 2005之前，必须要确定程序中没有这些问题。
1、参数的有效性
在C运行时库中，加入了一些代码，以检查参数的有效性。例如：如果传递的目标缓冲区大小不足以strcpy使用--通常这是在冒安全风险，而新版本此时则 会调用一个非法参数处理程序。在release版中，会调用Dr.Watson；而在debug版中，会产生断言（assert），当然，只要程序中传递 的参数都是有效的，就不会有什么问题了。
2、对非安全API的警告
在Visual C++ 2005中，CRT中的一组函数已不再建议使用，而应使用新提供的安全版本。大多数这些不建议使用的函数如果使用不当，将会导致缓冲区溢出或其他安全问 题，这些函数如：strcpy、strcat等等。这些函数新的安全版本都在函数名后加了一个_s后缀，以方便识别，如strcpy_s、 wcscpy_s、mbscpy_s、calloc_s和strcat_s这些函数。如果想继续使用老版本、非安全的函数，可在源代码开始处加上 #define value of _CRT_SECURE_NO_DEPRECATE（此处value代表某一数值）；然而，还是建议大家升级代码使用新的安全函数。
3、迭代器越界
受检查的迭代器（checked iterators）和调试迭代器（debug iterators）也因为安全的原因进行了相应的更新，如果迭代器越界，则相应会调用一个非法参数处理程序。再次提醒，可以通过抛出一个越界异常来避免 产生非法参数问题。在代码中加入#define value of _SECURE_SCL_THROWS，并把value值设为1,这样就不会调用非法参数处理程序，而是产生一个异常了。也可以通过设置#defined value of _SECURE_SCL值为零，关闭此迭代器检查，通常默认情况下，此选项是打开的。
4、time_t类型
time_t类型通常用于显示从1970年开始以来的秒数。直到Visual C++ 7.1（即Visual C++ .NET 2003），time_t类型都被定义为一个long，而到了Visual C++ 2005中，已被定义为一个64位类型，可用于显示一直到3000年的时间了。
5、链接到CRT
托管应用程序现在不能静态链接到CRT。以往，在Visual C++ 7.0和7.1中（指Visual Studio .NET 2002与2003），可以生成静态链接到CRT的CLR程序，而在Visual Studio 2005却行不通。
6、单线程CRT支持
在Visual Studio 2005中，已经取消了单线程CRT支持。而且用发展的眼光来看，未来大多数的人还是愿意使用线程安全的多线程代码。<br />在线程中，可使用_nolock后缀来优化代码，但同时，这些函数是非线程安全的。
7、异常处理
有两种类型的异常处理可供选择：/EHa（异步的）和/EHs（同步C++异常）。在以前，如果使用了/EHs，那么在一个catch(…)块中，也许可 能、也许不可能捕捉到结构化异常，因为此行为是没有定义且不可靠的；现在，再使用/EHs时，就可保证不会捕捉到结构化异常。如果想与以前版本的 Visual C++保持一致，并且捕捉异步结构化异常，还是应该在编译时使用/EHa。
8、初始化顺序
以往，如果代码中同时有托管与本地全局变量及对象，那么初始化顺序是不确定的；如代码中存在托管对象与本地对象互操作，就不能保证哪一个对象先初始化了。 现在，Visual Stuio 2005可保证所有的本地全局变量及对象先初始化，然后才初始化托管全局变量及对象。
9、printf
就目前来说，printf中的%n格式化指示符一般用于指定输出的字符个数。这已经确认为一个安全隐患，并且已禁用，但可以使用 set_printf_count_output来启用它；通过传递给set_printf_count_output一个零值（0）可禁用它，而传递任 意一个其他值可再次启用。
10、swprintf函数
为与C++标准保持一致，对swprintf函数也作了修改，现在它已遵循C++标准了。在C++中，通过适当的参数，可实现重载；这个函数的老版本已不再建议使用，因为在C中，是不允许重载的，因此如果使用老格式，将会返回一个错误。
编译器中的突破性变化
除了那些会影响到库的变化之外，也有一些变化会影响到编译器。以下是Visual C++ 2005中编译器的主要变化，需再次提醒的是，此处并没有列出所有的变化，但却是微软公司VC++使用者及内部合作者所确认的关键性变化。
指向成员的指针
在之前的版本中，一个指向成员的指针不需使用取址操作符（&）就能获取，现在，Visual C++ 2005已经严格按照标准，必须要使用取址操作符，这也有助于消除潜在的运行时错误。但也导致了MFC库的许多地方需要修改，同时意味着，可能会对现有的 程序造成影响。
范围限制规则
在for循环声明中，默认情况下不强制执行范围限制规则。在之前的版本中，for循环中变量的生命期将会延续到循环之外，为与标准兼容，for循环中定义的变量，现在只限定在for循环内使用。
wchar_t类型
现在，wchar_t已为默认内置类型。这就是说，也许在以前，wchar_t可能会被当作一个unsigned short，因为它还不是内置类型，所以，当与那些有wchar_t类型变量的文件作符号比较时，很可能会导致问题。在Visual C++ 2005中，wchar_t已是一个内置类型，也就是说，需要确定以前对wchar_t的用法不会导致转译为一个unsigned short。
异常处理
为了与库的变化保持一致，编译器已作了一些修改，以便不会捕捉到结构化异常。所以，为与以前代码保持兼容，还是应该使用/EHa。
参数属性
为了提供更健壮的属性--也是为了代码的健壮性，编译器现在将会检查类型、枚举等等的属性。这意味着，以前的代码可能会在属性方面碰到一个从未有过的编译器错误。
默认为int
为遵循C++标准，对没有类型声明的变量或函数，已不再默认为int类型。但在C语言中仍然可以，C++语言中已不行。这甚至也影响到了微软公司自身的代码，包括NT系统的代码，所以最好的方式，还是显式声明。
关于C的托管代码
C语言编译器一般不可能创建CLR的托管代码，因为C语言不是面向对象的，它不符合CLR所使用的模型，因此，任何以C语言来编译的代码都会与CLR编译器设置冲突。例如，如果在编译时使用/TC设置，而且又设置了CLR，就会导致冲突。
面向CLR的新语法
通过设置/clr编译选项，C++编译器只接受新语法。这将强制推广加入到Visual C++ 2005中的新语法，同时，也会废弃掉老代码。
安全检查
在安全越来越得到重视的今天，安全检查选项/GS，在默认情况下就是打开的，还是有一定道理的。在Visual C++ 2005中，默认情况下将会使用/GS选项。
结论:本文列出了微软公司已确认的Visual C++ 2005中的一些关键性变化，虽然不是所有的变化，也不是最有可能冲击到代码的变化，但此处所列出的项目，将最有可能导致问题的产生。归根结底，在升级或 用新版编译器对程序作修改之前，必须先试着编译现有程序，以确认代码能通过编译，否则，就不可避免要动手修正源代码中存在的问题。
——————————————————————————————————————————————————
我的问题是这样解决的:
1。.lib是用vc6编的,其中用到了消息响应,vc6的消息响应函数和vc2005的消息响应函数的参数和返回值类型不同造成的链接问题.
2。所以我用vc2005 重新编译了这个.lib就ok了.
把工程的字符集改成多字节模式就OK了， VS2005默认是 UNICODE 字符集
项目是从vc6 转到 vc2005 的,在vc6下引用一个lib库,运行一切正常, 转到vc2005 就出现下边的错误.头文件,lib文件都引入了.请大家帮分析下.
是VC6与VC2005的wchar类型定义不同导致的,你可以在项目属性里找到"C/C++"-"语言",把wchar_t的类型设置改为No(/Zc:wchar_t-),这样应该就可以了.
把你的库用unicode编码重新编译后，添加到VS2005工程。
评论