于是开始上网寻找解决办法.搜到很多网页,都在说Vista的兼容性不良,说有很多程序在Vista下面运行都不理想,甚至有很大问题.但我的程序比较小,并没有涉及到网络或数据库这些应用,所以我想应该问题不会很大.况且机子上有一些不知道哪里来的规模相当,功能相似的程序都运行正常.所以我在想也许问题应该没那么严重.(后来找到了那个程序的源码,是DELPHI做的,看到人家DELPHI的程序运行得那么好,我做VC的心里很不是滋味.)

继而转向微软新一代开发环境寻找解决方案.立即寻找VS2005.将GOOGLE所有的网页翻了一遍,无果.绝望中发现有微软官网上有Visual Studio .NET 2008, 即传说中的Visual Studio Codename Orcas的Beta2 Pre-release版本,虽然担心文件太大下不下来,但当时只有这一个办法了.还好,第二天都下完了.于是在Vista上安装好,把项目文件夹拷贝过来.

生成解决方案,通过. 调试,崩溃.

Debug Assertion Failed! 因为程序流程很简单,很快就发现哪里出错了. CDialog的SendMessage()函数好象不能用了(反正注释掉它就好了).

重新生成,通过;调试,通过;运行,成功.

因为程序小,所以改起来还比较容易.要是大了,想解这些BUG真的不容易.

把生成的程序拿到其他Vista机子上,想必应该可以运行了吧.没想到,又是一个对话框——

“The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail.”

搜了搜,没搜到side-by-side configuration is incorrect的信息.很意外哦!难道我是第一个用在Vista里面写程序的菜鸟吗?怎么没有前辈给条线索?在MSDN上查side-by-side configuration,只是觉得又是一个什么工程配置之类的东西,结果没有该关键词.只看到了一个side-by-side application,跟进去看了一下.根据文章的描述和以往的经验判断,这篇文章就是说的就是我这个问题.继续跟进,发现一些新名词:

manifest

Manifests are XML files that accompany and describe side-by-side assemblies or isolated application. Manifests uniquely identify the assembly through the assembly’s <assemblyIdentity> element. They contain information used for building and activation, such as COM classes, interfaces, and type libraries, that has traditionally been stored in the registry. Manifests also specify the files that make the assembly and my include Windows classes if the assembly author wants them to be versioned. Side-by-side assemblies are not registered on the system, but are available to applications and other assemblies on the system that specify dependencies in manifest files.

side-by-side assemblies

A Windows side-by-side assembly is described by manifests. A side-by-side assembly contains a collection of resources – a group of DLLs, Windows classes, COM servers, type libraries, or interfaces – that are always provided to applications together.

Side-by-side assemblies are used by the operating system as fundamental units of naming, binding, versioning, deployment, and configuration. Every side-by-side assembly has a unique identity. One of the attributes of the assembly identity is its version. For more information, see Assembly Versions.

Starting with Windows XP, multiple versions of side-by-side assemblies can be used by applications running at the same time. Manifests, and the assembly version number, are used by the loader to determine the correct binding of assembly versions to applications. Side-by-side assemblies and manifests work with applications and the side-by-side manager as illustrated in the following figure.

isolated applications

Isolated applications are self-describing applications installed with manifests. Isolated applications can use both private assemblies and shared assemblies.

An application is considered fully isolated if all of its components are either shared side-by-side assemblies or private assemblies. It is called partially isolated if it uses some components that are not side-by-side assemblies. Note that if an application uses some components that are not side-by-side assemblies, or uses private assemblies, the application may be affected by the installation or removal of other applications on the system.

Developers are encouraged to design isolated applications and to update existing applications into isolated applications for the following reasons:

&laquo;         Isolated applications are more stable and reliably updated because they are unaffected by the installation, removal, or upgrading of other applications on the system.

&laquo;         Isolated applications can be designed so that they always run using the same assembly versions with which they were built and tested.

&laquo;         Isolated applications can use functionality provided by the side-by-side assemblies made available by Microsoft. For more information, see Supported Microsoft Side-by-side Assemblies.

&laquo;         Isolated applications are not tied to the shipping schedule of their side-by-side assemblies because applications and administrators can update the configuration after deployment without having to reinstall the application. This would not apply in the case where only one version of the assembly is being made available.

&laquo;         A fully isolated application may be installed by using the xcopy command. Windows Installer can also be used to install an isolated application without impact to the registry. For more information, see Installation of Win32 Assemblies.

manifest

一张程序配置的清单.这张清单是一个XML的文件.它伴随并描述了side-by-side assemblies与isolated application. (我自己的翻译:Side-by-side assemblies,并行配件组. Isolated application,独立应用程序.)

为让自己理解这个程序清单,把应用程序想象成一部F1赛车.F1在比赛之前其实并不会完全装好,因为要根据天气选择合适的轮胎,要根据气压调整鼻翼尾翼,在比赛中还可以换轮胎.那技术人员根据什么来调整赛车呢?肯定会有一个标准,就是一张清单. 这里的程序配置清单是类似的东西, 它定义了对于这个程序来讲, 哪些东西可以用, 需要绑定些什么, 等等.而根据程序清单为程序”换轮胎”的人就是Windows操作系统.

通过集合的<assemblyIdentity>项, 清单可以唯一确定程序的配件. 清单包含用于程序生成和程序运行所需要的信息,比如COM类,接口,库类型.这些信息原本是存在注册表中的. 如果作者希望对那些制作配件的文件以及Windows类自定义包含(my include Windows classes)的文件进行版本管理的话,也可以在清单中指明它们.并行配件组(side-by-side assemblies)不在系统中注册,但对于应用程序和系统中其他在清单中指明了依赖性的配件而言是有效和可用的.

关于这张清单长什么样子,怎么去写,MSDN上有相关文档,其中有一篇叫Manifest Files Reference,看起来好象比较合适.

side-by-side assemblies

Windows并行配件组 (side-by-side assembly)是用清单文件来描述的一个东西.它包含了一组将会提供给应用程序使用的资源,即配件.这些资源对于应用程序来讲是固定的和必须的.比如一组DLL, Windows类, COM服务器, 类型库, 接口.

并行配件组被操作系统使用,被作为命名,绑定,版本控制,部署以及配置的关键单元.每一个并行配件都具有一系列特征,比如版本就是其特征之一.

从Windows XP开始,可供应用程序并发使用的并行配件组越来越多.加载程序通过清单和配件的版本号为应用程序确定准确的绑定版本.并行配件组,清单与应用程序,并行管理器之间协同工作时的情形如图所示.

图中SxS Manager就是Side-by-side Manager. 我查了一下自己的机子, XP, Vista的WINDOWS目录下都有一个名为winsxs的文件夹,这个东西和这个SXS Manager应该是有一定关系的.对这图表示的程序运作流程的理解是,应用程序需要使用动态链接的时候,加载程序通过SXS去查询清单,确定了具体的版本号之后再加载对应的DLL.

isolated applications

独立应用程序(Isolated Application)是一个自己描述自己的程序(以前系统来描述的),它连同清单一起被安装到系统里面.独立应用程序既可用自带的配件,也可以用共享的配件.好比F1赛车,既可以用自己造轮胎,也可以用大家都使用的米其林轮胎.

如果一个应用程序所有的零部件(组件)要么全是共享的并行配件,要么全是没有共享的私有配件,那么这个应用程序被认为是完全独立的.如果有一部分零件不是并行配件(就是说没有在清单中指明,在执行程序的时候SXS管理器不会去核对它的版本的那种配件),那么它则被认为是部分独立的.如果一个程序使用的组件不是并行配件,或者使用了私有配件,那么在其他程序安装或移除的时候可能会受影响.

我们推荐开发人员设计独立应用程序,并将现有程序更新为独立应用程序,原因是:

&laquo;         独立应用程序的更新更具稳定性和可靠性,因为他不受其他程序安装,移除或更新的影响.

&laquo;         独立应用程序可以永远使用在设计及测试时使用的配件.(这可以避免由于配件更新带来的一系列不兼容或升级问题.比如DLL Hell.)

&laquo;         独立应用程序可以享用微软制造之并行配件组所提供的功能和性能.

&laquo;         独立应用程序不会被并行配件组的交货日程所限制,因为程序和管理员可以在完成部署之后更新配置,而不用重新安装应用程序.而如果程序中指定了只能用某一版本的配件,则不能进行这种更新.

&laquo;         把一个完全独立的应用程序拷贝过来就等于安装了它. (这条是独立应用程序的根本优越性.以前的Windows程序必须在系统注册,安装就是注册,卸载就是注销.现在不用搞那么多名堂,想用就直接复制过来双击就可以运行了.这样系统省事,用户方便.这应该是Windows从Linux中吸取的长处,应该算是一大改进吧.) Windows Installer也可以用于安装一个独立应用程序,但它再也不需要注册表进行配置.

总体意思就是,对于完全独立的应用程序,以前由系统维护和管理的程序组件信息现在改由应用程序自己来维护和管理,方法是通过清单.程序的安装不再需要配置注册表,而是需要写明这张清单.

最后解决问题用了一个对初学者很实用的办法,在网上搜索到的. 文章标题为《VS 2005编译的程序不能运行的解决办法》，作者对用编译生成都成功的程序不能在别的系统上运行的原因是“发现和 winxp、win2003中为解决dll hell而引入的manifest机制有关系。而以前我们用vs2003开发, 它并没有强制程序使用manifest, 但到了vs2005中, 这已经改成必需的了, 而我们并没有按照需要进行相关的配置, 所以程序启动不了了。”这与自己根据MSDN资料分析出来的原因是一样的。不同的是，作者的用户平台是XP和2003，现在这个问题已经扩大到Vista；作者使用的开发平台是Visual Studio 2005，现在2008也会有同样问题。还一个关键的地方，作者应该制作了安装包，但程序依然没有办法运行，也就是说，即使做了安装包也是可能还是不能用，仍然要进行配置。作者对解决方法的记录如下：

（摘自http://www.vckbase.com/document/viewdoc/?id=1744）

根据目前的经验, vs2005编译的程序不能启动大致有两个原因,其现象和解决办法描述如下：

1.        在开发组的机器上(安装有vs2005)有时都不能启动

这一般是项目的文件被放在FAT/FAT32分区上导致的, 解决方法是把它们都移动到NTFS分区上, 或者把“项目属性|Manifest Tool|General|Use FAT32 Work-around”设为yes。

2.        开发机运行正常, 换到其它机器上就不行了

这一般就是系统DLL(包括CRT, MFC, ATL等)没有正确配置导致的。

如果程序是release版, 那么很简单, 只要把“\SDK\v2.0\BootStrapper\Packages\vcredist_x86”下的"vcredist_x86.exe"拷贝到目标机器上运行即可.（解释一下——拷贝这个程序到目标机然后运行，像是装了一个什么东西。装完了以后再运行用平台开发出来的程序，如果还提示有什么DLL找不到，那就把开发机上相应的DLL拷贝出来，贴到用户机中相应的文件夹里面。比如一个MFC的什么DLL找不到，在开发机上搜索这个DLL，记住它的路径，然后按这个路径贴到用户机上。） 这是以x86平台为例的, 如果你用的是别的CPU平台(amd64或ia64)把x86替换成相应的内容就可以了。

如果是debug版, 就复杂一些了, 首先要确定你需要的DLL的版本, 绝大多数(注意:不是"所有")情况下它和编译器的版本相同, 通过vs2005的关于对话框就能看到, 如下图所示:

确定版本后, 在开发组的机器上进入“%windir%\winsxs"文件夹(下面将以x86平台8.0.50727.762版本的debug CRT为例进行说明) 需要依版本号而定的部分用加粗表示, 拷贝以下文件到目标机器的相同位置即可:

x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9f文件夹下所有文件;

Manifests文件夹下

x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9f.cat

x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9f.manifest

Policies\x86_policy.8.0.Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_x-ww_09e017b4文件夹下

8.0.50727.762.cat                           

8.0.50727.762.policy

注意, 上面的操作只是在目标操作系统为winxp,win2003及以上时才需要的, 如果是win2000及以下的系统, 只要把第一个文件夹下的文件拷贝到system32中就行了。

按作者的方法试了一下，把项目属性改成Release，重新生成解决方案。把文件拷贝到用户机，先运行一次，然后再运行自己的程序，就不再提示“The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail.” 而是提示某个MFC DLL没找到，这个就和XP系统下MFC程序安装就要运行的提示一样了，拷贝相应DLL到SYSTEM32，程序终于能在Vista下面顺利执行了。

本次生成程序用的平台是Visual Studio 2008，装了一下这个vcredit_86就可以了。根据文章VS2005也是这样。那对于VS2003和更早的VC6.0可不可以也使用这个办法呢？根据用VC2003和VC6.0的程序在Vista下面测试的结果，答案是可以。方法也是类似的，先运行vcredist_x86.exe。这个程序是SDK带的程序，以目前的了解也许SDK版本至少要高于.NET 2.0才会有。SDK2.0有，SDK6.0有, SDK1.1没有。值得注意的一点：用系统搜索过这个文件搜索不到，但是自己到那个文件夹下面去找就能找到，所以如果没有搜索到的话一定要自己去SDK文件夹下面找一下。

有的根本就没有装.NET的SDK怎么办呢？也有办法！这个单独的vcredist_x86.exe文件可以在微软的下载中心下载到，东西是一样的，而且在微软下载到的还是最新的版本