都有标识! 方法二:
修改编译选项,将/MD或/MDd 改为 /MT或/MTd,这样就实现了对VC运行时库的静态链接,在运行时就不再需要VC的dll了。 方法三:
工程-》属性-》配置属性-》常规-》MFC的使用,选择“在静态库中使用mfc” 这样生成的exe文件应该就可以在其他机器上跑了。 方法四:
你的vc8安装盘上找到再分发包vcredist_xxx.exe和你的程序捆绑安装
在大部分机上都可以运行了,唯独在我的测试机上还是报应用程序配置错误。刚开始怀疑是还缺少dll,在能跑的机上把windows/system32目录下所有的msvc*.dll都复制到这台机的运行目录,还是不行!极度郁闷※×…!后来实在没辙了,就在VC环境中打开了EXE来查看它内嵌的manifest资源,无奈了看了一会,带着心中对manifest的咒骂,突然发现这个manifest带了两个版本CRT的依赖:
再打开Microsoft.VC80.CRT.manifest一看,是这样:
就是说,我们EXE的Manifest里多了一个版本依赖,那就把后面那个依赖删除试试。于是就把工程设置的生成manifest的选项去掉,手工改了一下manifest放到程序目录下,发现果然可以运行了!
还有个问题没有明白,就是VC为什么在自傻膍anifest里带了两个依赖呢,上网再查
了一下,发现在msdnonline上说'8.0.50608.0'这个版本是在XP下用的,'8.0.50727.762'这个版本是在Vista下用的(msdn.microsoft/en-us/library/ms235342(VS.80).aspx),可是我用的是'8.0.50727.762'在XP下运行的好好的!想不通是它错了还是别的原因。后来在CRT的源码里面搜索'8.0.50727.762',找到了~'8.0.50608.0'也在那里。 #if defined _USE_RTM_VERSION
#define _CRT_ASSEMBLY_VERSION “8.0.50608.0” #else
#define _CRT_ASSEMBLY_VERSION “8.0.50727.762” #endif
显然默认的版本是“8.0.50727.762”,除非定义了_USE_RTM_VERSION!那为什么我们的工程会生成两个版本的依赖呢,明明这个地方是二选一的。一开始怀疑是工程设置引起的,我就把我们的工程拷出来,把里面的文件删掉,再复制一些向导生成的文件进来,编译一看,manifest里只有一个'8.0.50727.762',说明工程设置没有
问题!最后我怀疑是工程链接的那些库的问题,因为有些库是用VC6或者VC2003编译的,但是有些库没有代码,编不了,没法尝试了。
VC++ 解决"应用程序配置不正确,程序无法启动"
2009-03-03 10:05
在使用VC++2005环境下生成的程序,放置到未安装VC环境的机器下后,有时候会出现程序无法执行的错误,其提示是:应用程序配置不正确,程序无法启动,重新安装应用程序可能解决问题。
实际上,重装是解决不了问题的,解决的一种方法是查看*exe.intermediate.manifest文件,比如文件的内容是:
xmlns='urn />
version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
需要注意这个文件中的3个关键词:Microsoft.VC80.CRT,
Microsoft.VC80.MFC和Microsoft.VC80.DebugCRT。寻找到...."Program
Files"Microsoft Visual Studio 8"VC"redist文件夹下面,找到这些名称的子文件夹,拷贝它们下面所有的文件到希望发布的EXE文件下面,一起打包。这些文件也就是mfc80.dll,msvcr80.dll,msvcp80.dll和
Microsoft.VC80.CRT.manifest等。此错误发生的原因是在目标机器上需要这些文件的支持。
Visual C++ Libraries
Visual C++ Libraries as Shared Side-by-Side Assemblies
In Visual C++ 2005, the ATL, MFC, Standard C++, and CRT libraries support the new deployment model available on Windows XP, Windows Server 2003, and Windows Vista. The DLLs corresponding to all Visual C++ libraries have been grouped into several shared side-by-side assemblies and are
installed into the native assembly cache, also called the WinSxS folder, under the operating system root directory. Similarly, while building a C++ application using Visual C++ 2005, by default the compiler and the linker generate a manifest file that describes runtime dependencies of this application on Visual C++ libraries.
Visual C++ libraries cannot be used by a C/C++ application without a manifest binding the application to these libraries. If a C/C++
application that depends on a Visual C++ library does not use a manifest, then an attempt to load the Visual C++ library as a dependent DLL from the application-local folder will result in an error message indicating that this is an unsupported way of loading a Visual C++ library.
Note:
On versions of Windows that do not support deployment of shared
side-by-side assemblies, such as Windows 98 and Windows 2000 Server, the Visual C++ libraries are installed in the System32 folder and WinSxS folder under the operating system root directory. This setup enables running Visual C++ applications on these operating system versions because they do not support manifest-based binding of applications to
dependent DLLs. On these operating systems, when an application is loaded, the corresponding manifest file is ignored and the operating systems searches for dependent DLLs using paths set in the current running environment. However, on upgrading the operating system to a version that support manifest-based binding, such as Windows XP, Windows Server 2003, or Windows Vista, applications built with manifests start using the DLLs installed in the WinSxS folder.
This change to the deployment model of Visual C++ libraries prevents the problem of version conflicts between DLLs that occur when you add updates or configurations to a machine, and will allow support of side-by-side in