精华内容
下载资源
问答
  • 操作系统重装后,安装LoadRunner11时,会报缺少vc2005_sp1_with_atl_fix_redist错误,类似下图所示: LR自动安装失败,在网上下载此组件安装后依然提示此信息,最终解决方案,在LoadRunner的安装包中,找到此...

    操作系统重装后,安装LoadRunner11时,会报缺少vc2005_sp1_with_atl_fix_redist错误,类似下图所示:

    LR自动安装失败,在网上下载此组件安装后依然提示此信息,最终解决方案,在LoadRunner的安装包中,找到此组件,进行安装解决,也就是说必须要用LR安装包自带的组件。

    路径地址:找到安装程序自带的lrunner\Chs\prerequisites\vc2005_sp1_redist,双击运行vcredist_x86.exe,再重新安装LoadRunner即可成功。

    转载于:https://www.cnblogs.com/ssj0723/p/7919051.html

    展开全文
  • 最近几天被这个问题困惑了许久。 不禁感叹微软的东东真是越做越烂了,也... 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷...

     最近几天被这个问题困惑了许久。 不禁感叹微软的东东真是越做越烂了,也终于明白了时隔12年大家仍然死守VC6的原因。。 


      用VC2005编译的程序,编译时没有任何错误,但是运行时就是提示“应用程序正常初始化失败”!! 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的; 有让清理注册表的;有让装.NetFramework新版本的;有让查manifest的;

      结果我尝试了半天,几乎都是浪费时间。上面最后一条说的还算正确,只是作者把事情描述得太繁琐了。。现在把处理的方法说一下,省得大家再走弯路:

      1. VC2003、VC2005、VC2008及其后续版本,对底层最基本的CRT、MFC、ATL库都进行了重构,为了避免不同版本的库引起冲突,重构后的库文件一般放在 C:\\windows\WinSxS 文件夹中,并用特定的文件夹\文件名称进行标识;

      2. 与VC6不同, VC2003、VC2005、VC2008及其后续版本,引入了manifest清单的概念,即应用程序编译后会同时生成对应的.manifest文件,并将该.manifest文件作为资源编译到dll或者exe中去。.manifest文件实际上是一个XML格式的文本文件,里面记录了dll或exe中要引用的CRT、MFC、ATL库的版本和名称。VC6编译的应用程序对CRT、MFC、ATL的dll都是直接调用,而VC2003、VC2005、VC2008编译的程序都是先查询编译到资源中的manifest中的记录,然后按照记录提供的版本和名称去搜寻对应的CRT、MFC、ATL库以及随库发布的.manifest文件,搜寻的路径包括当前目录、C:\\windows\WinSxS 等等,如果没有找到对应的库文件,则提示“应用程序正常初始化失败”;

      3.因此解决这个问题的办法就是:(a)用文本编辑器打开exe或dll对应的.manifest文件,查看它引用的CRT、MFC、ATL库的版本;或者,用UltraEdit直接打开exe或者dll,从资源区中找到编译进去的.manifest信息,找到它引用的CRT、MFC、ATL库的版本;或者,运行程序,当程序弹出“应用程序正常初始化失败”对话框时,在桌面上右键点击“我的电脑”-“管理”-“事件查看器”-“系统”,双击查看其中的记录,可以看到出错的原因是因为缺少了某某版本的CRT、MFC、ATL库,记录下这个版本信息;(b)记录到的库的版本信息一般类似于“Microsoft.VC90.DebugCRT”,之后到C:\\windows\WinSxS 或者VC200X的安装文件夹中搜索包含这个字符串的文件夹和文件,将搜索到的dll和.manifest文件都拷贝到应用程序所在的文件夹中,其中,.manifest文件必须重命名为“Microsoft.VC90.DebugCRT.manifest”(这里以Microsoft.VC90.DebugCRT为例),这样应用程序就可以正常运行了;(c)注意:库的.manifest文件和dll要一同拷贝到应用程序根目录去,因为应用程序会将编译到内部的manifest信息与外部的.manifest文件进行对比,之后才会对库的dll进行调用。如果只拷贝库的dll文件是没有用的;

      4.如果本机编译和运行程序都ok,但是将编译好的程序拿到其它机器上确无法运行,则多半也是这个原因。另外,如果提示"应用程序配置不正确",大多也是因为上面所说的CRT、MFC、ATL库版本与应用程序不匹配导致的,可以如法炮制进行解决;

     

    在网上找出了这些方法:
      方法一:
      在类似C:\Program Files\Microsoft Visual Studio 8\VC\redi
      st\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT 下找到了下列文件:
      msvcm80d.dll
      msvcp80d.dll
      msvcr80d.dll
      Microsoft.VC80.DebugCRT.manifest
      把这几个文件拷贝到目标机器上,与运行程序同一文件夹或放到system32下,就可以正确运行了。
      其他release版、MFC程序什么的都是拷redist下相应文件夹下的文件就可以了,文件夹后都有标识!
      方法二:
      修改编译选项,将/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下用的(http://msdn.microsoft.com/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文件,比如文件的内容是:

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>

    <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>

    <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

    </dependency>

    <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.MFC' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

    </dependency>

    <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

    </dependency>

    </assembly>

           需要注意这个文件中的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 installation of two different Visual C++ toolsets. It will also allow you to produce reliable, self-describing applications and components that will not conflict with existing components. For more information on the advantages of new deployment model, please see Concepts of Isolated Applications and Side-by-side Assemblies. To learn about how this may impact deployment of existing native C++ applications, please refer to Redistributing Visual C++ Files.

    Visual C++ libraries have been packaged in several shared side-by-side assemblies with corresponding manifest files.

    Assembly Name

    DLLs included in the assembly

    Visual C++ Library

    Microsoft.VC90.ATL

    atl90.dll

    Active Template Library

    Microsoft.VC90.CRT

    msvcr90.dll

    msvcp90.dll

    msvcm90.dll

    C Runtime Library, release DLLs

    Microsoft.VC90.DebugCRT

    msvcr90d.dll

    msvcp90d.dll

    msvcm90d.dll

    C Runtime Library, debug DLLs

    Microsoft.VC90.MFC

    mfc90.dll

    mfcm90.dll

    mfc90u.dll

    mfcm90u.dll

    Microsoft Foundation Classes, release DLLs

    Microsoft.VC90.DebugMFC

    mfc90d.dll

    mfcm90d.dll

    mfc90ud.dll

    mfcm90ud.dll

    Microsoft Foundation Classes, debug DLLs

    Microsoft.VC90.MFCLOC

    mfc90chs.dll

    mfc90deu.dll

    mfc90esp.dll

    mfc90ita.dll

    mfc90kor.dll

    mfc90cht.dll

    mfc90enu.dll

    mfc90fra.dll

    mfc90jpn.dll

    Microsoft Foundation Classes, localized resources

    Microsoft.VC90.OpenMP

    vcomp.dll

    OpenMP Library, release DLLs

    Microsoft.VC90.DebugOpenMP

    Vcompd.dll

    OpenMP Library, debug DLLs

     

     http://wenku.baidu.com/link?url=lpOCsvRlBW_93VypbKoG9_IdQNvg59XNy2idhYOJ6RS9ohgSwJ_AytTCYsb8tered89-Sz3KBD6fjGU7y0UkP3zaq7EmD38lODzjQsvQZXK

    转载于:https://www.cnblogs.com/forcheryl/p/6386769.html

    展开全文
  • 最近几天被这个问题困惑了许久。 不禁感叹微软的东东真是越做... 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的;
     最近几天被这个问题困惑了许久。 不禁感叹微软的东东真是越做越烂了,也终于明白了时隔12年大家仍然死守VC6的原因。。
    

      用VC2005编译的程序,编译时没有任何错误,但是运行时就是提示“应用程序正常初始化失败”!! 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的; 有让清理注册表的;有让装.NetFramework新版本的;有让查manifest的;

      结果我尝试了半天,几乎都是浪费时间。上面最后一条说的还算正确,只是作者把事情描述得太繁琐了。。现在把处理的方法说一下,省得大家再走弯路:

      1. VC2003、VC2005、VC2008及其后续版本,对底层最基本的CRT、MFC、ATL库都进行了重构,为了避免不同版本的库引起冲突,重构后的库文件一般放在 C:\windowsWinSxS 文件夹中,并用特定的文件夹文件名称进行标识;

      2. 与VC6不同, VC2003、VC2005、VC2008及其后续版本,引入了manifest清单的概念,即应用程序编译后会同时生成对应的.manifest文件,并将该.manifest文件作为资源编译到dll或者exe中去。.manifest文件实际上是一个XML格式的文本文件,里面记录了dll或exe中要引用的CRT、MFC、ATL库的版本和名称。VC6编译的应用程序对CRT、MFC、ATL的dll都是直接调用,而VC2003、VC2005、VC2008编译的程序都是先查询编译到资源中的manifest中的记录,然后按照记录提供的版本和名称去搜寻对应的CRT、MFC、ATL库以及随库发布的.manifest文件,搜寻的路径包括当前目录、C:\windowsWinSxS 等等,如果没有找到对应的库文件,则提示“应用程序正常初始化失败”;

      3.因此解决这个问题的办法就是:(a)用文本编辑器打开exe或dll对应的.manifest文件,查看它引用的CRT、MFC、ATL库的版本;或者,用UltraEdit直接打开exe或者dll,从资源区中找到编译进去的.manifest信息,找到它引用的CRT、MFC、ATL库的版本;或者,运行程序,当程序弹出“应用程序正常初始化失败”对话框时,在桌面上右键点击“我的电脑”-“管理”-“事件查看器”-“系统”,双击查看其中的记录,可以看到出错的原因是因为缺少了某某版本的CRT、MFC、ATL库,记录下这个版本信息;(b)记录到的库的版本信息一般类似于“Microsoft.VC90.DebugCRT”,之后到C:\windowsWinSxS 或者VC200X的安装文件夹中搜索包含这个字符串的文件夹和文件,将搜索到的dll和.manifest文件都拷贝到应用程序所在的文件夹中,其中,.manifest文件必须重命名为“Microsoft.VC90.DebugCRT.manifest”(这里以Microsoft.VC90.DebugCRT为例),这样应用程序就可以正常运行了;(c)注意:库的.manifest文件和dll要一同拷贝到应用程序根目录去,因为应用程序会将编译到内部的manifest信息与外部的.manifest文件进行对比,之后才会对库的dll进行调用。如果只拷贝库的dll文件是没有用的;

      4.如果本机编译和运行程序都ok,但是将编译好的程序拿到其它机器上确无法运行,则多半也是这个原因。另外,如果提示"应用程序配置不正确",大多也是因为上面所说的CRT、MFC、ATL库版本与应用程序不匹配导致的,可以如法炮制进行解决。

     

    附文:如何避免windows update后运行库版本被升级导致编译后二进制执行文件无法在低运行库版本操作系统上运行。以下附文转自国外网站:

    Avoiding problems with VC2005 SP1 Security update KB971090

    KB971090 update mitigation

    Problem

    After installing KB971090 for Visual C++ 2005 SP1, the version of ATL/MFC/CRT referenced in the generated manifests is changed from 8.0.50727.762 to 8.0.50727.4053

    The above change forces the application developer to rebuild all components to reference the 4053 version of the versions of ATL/MFC/CRT in the manifest, as well as making it necessary to ship a new vcredist_x86.exe and/or MSM files containing the new 4053 versions of ATL/MFC/CRT.

    Solution

    Instead of uninstalling the KB971090 update, we can force the build to use the 8.0.50727.762 version instead of the default which is 8.0.50727.4053. Microsoft provides a mechanism to specify the assembly version number to use in the manifests.

    Steps to take to allow your applications to reference 8.0.50727.762 instead of 8.0.50727.4053

    1) Create a file named targetsxs.h with the following content and put it in a common location

    #ifndef __midl
    #define _SXS_ASSEMBLY_VERSION "8.0.50727.762"
    #define _CRT_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
    #define _MFC_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
    #define _ATL_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION

    #ifdef __cplusplus
    extern "C" {
    #endif
    __declspec(selectany) int _forceCRTManifest;
    __declspec(selectany) int _forceMFCManifest;
    __declspec(selectany) int _forceAtlDllManifest;
    __declspec(selectany) int _forceCRTManifestRTM;
    __declspec(selectany) int _forceMFCManifestRTM;
    __declspec(selectany) int _forceAtlDllManifestRTM;
    #ifdef __cplusplus
    }
    #endif
    #endif

    2) The above file needs to be included in every project you wish to build.

    Accomplish this in one of two ways. The first method involves the changing of source code. The second involves changing of project settings.

    choose A or B which ever one is more appropriate for your situation:

    A) #include "targetsxs.h" near the top of every one of your stdafx.h files
    (using the path you saved the targetsxs.h)

    B) Use the force include (/FI) compile option to make sure that the above file is included in every file built. To accomplish that, add the following command line to your compiler options

    /FIc:\path\targetsxs.h

    (where c:\path is the location of the targetsxs.h you created in step 1)

    There are two methods to accomplish that: either directly in your project or through a compiler environment variable:

    Method i)

    Add the above to the command line section of the C/C++ project properties.

    Method ii)

    Create an environment variable named CL with the above-mentioned /FI statement

    Method (ii) is more convenient to use when you have dozens of projects that you do not wish to make changes to, but may conflict with other work you do on your machine.

    3) For every MFC DLL project in your solution add the following line to the bottom of the stdafx.cpp file

    #include "..\src\mfc\dllmodul.cpp"

    Step three is only necessary if you have any MFC DLL projects (this step is necessary due to a bug in the handling of the assembly versions in MFC DLLs – the bug is that a reference to the latest version of the DLLs will always be included regardless of what is set in step 1)

    4) Do a rebuild all of all the projects in your solution

    5) Inspect manifest files (by doing a find in files for *.intermediate.manifest) to ensure that 4053 no longer appears in any of the manifests.

    6) Run your app on a machine that has no 4053 components installed to WinSxS to make sure runs properly.

    IMPORTANT NOTE: if you have ATL controls that are affected by this security problem please ensure you have followed the directions to modify your controls to take advantage of the security updates. A simple recompile may not be enough. For more info please see the video at:

    http://channel9.msdn.com/posts/Charles/Out-of-Band-Inside-the-ATL-Security-Update/

    Q&A

    Does referencing 762 instead of 4053 make your application less secure?

    No. Microsoft provides WinSxS policy redirection, so any application referencing 762 will end up loading the 4053 versions (if they’re installed). The ATL security update redistributable has been released as an update on Windows Update, so the 4053 version of ATL will be in place, and will be used even though your app still references the 762 version of ATL.

    *Important note: you should still ship the new version of the redistributable if at all possible, as users may have not updated using Windows Update.

    What are the benefits to referencing 762 instead of 4053 in your SP1 applications?

    1) If you have existing applications shipped and you need to rebuild any components shipped, then new MSM or vcredist_x86.exe containing 4053 versions do not need to be shipped. You can continue to ship existing components with 762 versions.

    2) If you have existing third party static libraries that reference 762, then you need not rebuild them to reference 4053.

    Does VC2008 SP1 security update have a similar issue?

    Yes, it does, if you use _BIND_TO_CURRENT_VCLIBS_VERSION in your project. It will bind to the security update version instead of the SP1 version. You can use a similar technique as described above (step 3 is not required) to get around this problem.

    For VC2008 SP1 the values for the current versions of the CRT/MFC/ATL have changed slightly, instead of _forceCRTManifest, you should use _forceCRTManifestCUR. The same thing applies for MFC/ATL (add the CUR). And of course, the version numbers you’re dealing with are different: SP1 9.0.30729.1 vs the new SP1+security update which is 9.0.30729.4148.

     

    so for VC2008 SP1 it should look like this:

    #ifndef __midl
    #define _SXS_ASSEMBLY_VERSION "9.0.30729.1"
    #define _CRT_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
    #define _MFC_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
    #define _ATL_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION

    #ifdef __cplusplus
    extern "C" {
    #endif
    __declspec(selectany) int _forceCRTManifestCUR;
    __declspec(selectany) int _forceMFCManifestCUR;
    __declspec(selectany) int _forceAtlDllManifestCUR;
    __declspec(selectany) int _forceCRTManifestRTM;
    __declspec(selectany) int _forceMFCManifestRTM;
    __declspec(selectany) int _forceAtlDllManifest;
    #ifdef __cplusplus
    }
    #endif
    #endif


    / 译文 /

    VC分发包安全更新--KB971090的修正之道

    [注]

    KB971090的描述:http://support.microsoft.com/kb/971090/zh-cn

    KB971090的下载地址:http://www.microsoft.com/downloads/details.aspx?familyid=7C8729DC-06A2-4538-A90D-FF9464DC0197&displaylang=zh-cn 

    [问题描述]

    在安装了Visual C++ 2005 SP1的KB971090安全更新后,VC生成的manifest中引用的ATL/MFC/CRT库的版本从8.0.50727.762变成了8.0.50727.4053。

    正因为上面的变动,导致了应用程序开发者必须重新编译所有的组件使它们在manifest中指向4053版本的ATL/MFC/CRT库,同时在发布应用程序的时候还必须部署一个新的vcredist_x86.exe(对应8.0.50727.4053版本)或者在安装文件中内嵌包含了最新4053版本的ATL/MFC/CRG库的MSM文件。

    [解决之道]

    除了卸载KB971090更新之外,我们还可以强制使用8.0.50727.762版本的库来替换此时默认8.0.50727.4053的库。Microsoft提供了一种在manifest文件中指定使用哪种版本编译库的机制。

    使得你的应用程序从指向8.0.50727.4053变为指向8.0.50727.762的步骤如下:

    1) 创建一个名为targetsxs.h的头文件,填入下面的内容,保存在某个固定目录下。

    #ifndef __midl 
           #define _SXS_ASSEMBLY_VERSION "8.0.50727.762" 
           #define _CRT_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION 
          #define _MFC_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION 
          #define _ATL_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION

    #ifdef __cplusplus 
           extern "C" { 
           #endif 
          __declspec(selectany) int _forceCRTManifest; 
          __declspec(selectany) int _forceMFCManifest; 
          __declspec(selectany) int _forceAtlDllManifest; 
          __declspec(selectany) int _forceCRTManifestRTM; 
          __declspec(selectany) int _forceMFCManifestRTM; 
          __declspec(selectany) int _forceAtlDllManifestRTM; 
          #ifdef __cplusplus 
         } 
          #endif 
          #endif

    2) 你需要在每个你希望编译的项目中包含上面的头文件。

    可以通过两种方法来达成这个目的。第一个方法是涉及到修改源代码。第二个方法涉及到修改项目设置。到底选择方法A好还是方法B好?这适合取决于你当前的应用环境:

    A) 在你的每一个stdafx.h头文件的头部包含"targetsxs.h"头文件

    (使用你保存targetsxs.h的路径)

    B) 强制使用(/FI)编译选项来保证每个文件编译时都包含上面的头文件(targetsxs.h)。为了达到这个目的,你可以在你的编译器选项中添加如下的命令行

    /FIc:\path\targetsxs.h

    (c:\path是你在第一步中创建的targetsxs.h的保存位置)

    可以使用两个方法在编译器选项中到达这个目的:在你的工程中直接设置或者通过编译器环境变量来设置:

    方法1:

    将上面的命令添加到C/C++工程属性的命令行中

    方法2:

    用上面提到的/FI语法创建一个名为CL的环境变量

    当你有很多工程的时候,你肯定不希望一个一个地去修改它们的工程属性,这个时候方法2就方便很多,但同时这个环境变量也可能会影响到你机器上的其他工程。

    3) 对于你项目清单中的每个MFC DLL工程,你需要在stdafx.cpp文件的底部添加下面一行代码

    #include "..\src\mfc\dllmodul.cpp"

    只有当你使用了MFC DLL工程的时候,这一步才是必需的(之所以是必需的是因为在MFC DLL中处理汇编代码(assembly versions)时的一个Bug - 如果没有包含dllmodul.cpp的话,步骤一设置的东西就不会被包含而编译器会始终引用最新版本的DLL)。

    4) 编译你的项目清单中的所有工程。

    5) 检查manifeset文件(就是编译器生成的那些*.intermediate.manifest文件)以确保4053不会出现在任何manifest文件中。

    6) 在一台没有安装4053版本WinSxS组件机器上运行你的应用程序来验证它可以正常运行。

    重要提示:如果你被ATL控件的安全性问题所影响(而必须要安装这个更新)的话,还是请你安装此更新以便使用更加安全的ATL控件。此时,简单的重编译可能并不足够,比需要从下面的视频中得到更多的信息:

    http://channel9.msdn.com/posts/Charles/Out-of-Band-Inside-the-ATL-Security-Update/

    Q&A

    1.使用762版本的组件来代替4053是否会使得你的应用程序安全性降低?

    不会。微软提供了一种WinSxS重定位策略,所以任何引用到762版本ATL的应用程序都最终会应用到4053版本(如果你安装了它们的话)。这个ATL安全更新已经作为Window Update的更新发布了,所以一旦你保持了与Window Update同步的更新,那么你就已经准备好使用4053版本的ATL了,即使你的应用程序仍然引用了762版本的ATL,你最终还是会使用4053版本的ATL。

    *重要提示:如果可能的话,你最好还是把最新版本的分发包随你的应用程序一起发布,因为用户有可能并不会使用Window Update来更新最新的组件。 

    2.在你的SP1应用程序中引用762版本来代替4053有什么好处么?

    1) 如果你有一些应用程序已经发布了但是必须重新编译某些已经发布出去的组件,那么你就不用再发布新的MSM或者包含4053版本的vcrdist_x86.exe了。你可以继续使用762版本来发布现有的组件。

    2) 如果你有使用引用到762版本的第三方静态库的话,你也不需要将它们重新编译到4053版本。

    3.VC2008 SP1安全更新是否有同样的问题呢?

    是的,如果你在你的工程中使用了_BING_TO_CURRENT_VCLIBS_VERSION,那么就会有同样的问题。它将会绑定到最新版本的安全更新来代替原来的SP1版本。你同样可以使用上面描述的方法(步骤3不需要)来解决这个问题。 
    对于VC2008 SP1,CRT/MFC/ATL的当前版本号有些许变化,你应该使用_forceCRTManifestCUR来代替_forceCRTManifest。对于MFC/ATL也必须使用同样的设置(添加CUR)。当然,此时你所面对的版本号也是不同的:SP1是9.0.30729.1,而最新的SP1+安全更新则是9.0.30729.4148。

    PS:由于个人实在无法忍受,每次编译出来的DLL都要手动去修改其资源文件中的Manifest(使用ResHacker删除掉有关4053版本的Manifest节点),所以今天一狠心,直接将工作机上所有关于VC2005的东东全部干掉,再重新安装一次,虽然浪费了很多时间,但是还是这种釜底抽薪的方法最有效。 


    展开全文
  •  用VC2005编译的程序,编译时没有任何错误,但是运行时就是提示“应用程序正常初始化失败”!!查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有...

    最近几天被这个问题困惑了许久。不禁感叹微软的东东真是越做越烂了,也终于明白了时隔12年大家仍然死守VC6的原因。。

      用VC2005编译的程序,编译时没有任何错误,但是运行时就是提示应用程序正常初始化失败!!查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe; 有让把CRT库的dll直接拷贝到程序目录的; 有让清理注册表的;有让装.NetFramework新版本的;有让查manifest;

      结果我尝试了半天,几乎都是浪费时间。上面最后一条说的还算正确,只是作者把事情描述得太繁琐了。。现在把处理的方法说一下,省得大家再走弯路:

      1. VC2003VC2005VC2008及其后续版本,对底层最基本的CRTMFCATL库都进行了重构,为了避免不同版本的库引起冲突,重构后的库文件一般放在 C:\\windows\WinSxS 文件夹中,并用特定的文件夹\文件名称进行标识;

      2. VC6不同, VC2003VC2005VC2008及其后续版本,引入了manifest清单的概念,即应用程序编译后会同时生成对应的.manifest文件,并将该.manifest文件作为资源编译到dll或者exe中去。.manifest文件实际上是一个XML格式的文本文件,里面记录了dllexe中要引用的CRTMFCATL库的版本和名称。VC6编译的应用程序对CRTMFCATLdll都是直接调用,而VC2003VC2005VC2008编译的程序都是先查询编译到资源中的manifest中的记录,然后按照记录提供的版本和名称去搜寻对应的CRTMFCATL库以及随库发布的.manifest文件,搜寻的路径包括当前目录、C:\\windows\WinSxS 等等,如果没有找到对应的库文件,则提示应用程序正常初始化失败

      3.因此解决这个问题的办法就是:(a)用文本编辑器打开exedll对应的.manifest文件,查看它引用的CRTMFCATL库的版本;或者,用UltraEdit直接打开exe或者dll,从资源区中找到编译进去的.manifest信息,找到它引用的CRTMFCATL库的版本;或者,运行程序,当程序弹出应用程序正常初始化失败对话框时,在桌面上右键点击我的电脑管理事件查看器系统,双击查看其中的记录,可以看到出错的原因是因为缺少了某某版本的CRTMFCATL库,记录下这个版本信息;(b)记录到的库的版本信息一般类似于“Microsoft.VC90.DebugCRT”,之后到C:\\windows\WinSxS 或者VC200X的安装文件夹中搜索包含这个字符串的文件夹和文件,将搜索到的dll.manifest文件都拷贝到应用程序所在的文件夹中,其中,.manifest文件必须重命名为“Microsoft.VC90.DebugCRT.manifest”(这里以Microsoft.VC90.DebugCRT为例),这样应用程序就可以正常运行了;(c)注意:库的.manifest文件和dll要一同拷贝到应用程序根目录去,因为应用程序会将编译到内部的manifest信息与外部的.manifest文件进行对比,之后才会对库的dll进行调用。如果只拷贝库的dll文件是没有用的;

      4.如果本机编译和运行程序都ok,但是将编译好的程序拿到其它机器上确无法运行,则多半也是这个原因。另外,如果提示"应用程序配置不正确",大多也是因为上面所说的CRTMFCATL库版本与应用程序不匹配导致的,可以如法炮制进行解决;


    在网上找出了这些方法:
      方法一:
      在类似C:\ProgramFiles\Microsoft Visual Studio 8\VC\redi
    st\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT下找到了下列文件:
    msvcm80d.dll
    msvcp80d.dll
    msvcr80d.dll
    Microsoft.VC80.DebugCRT.manifest
      把这几个文件拷贝到目标机器上,与运行程序同一文件夹或放到system32下,就可以正确运行了。
      其他release版、MFC程序什么的都是拷redist下相应文件夹下的文件就可以了,文件夹后都有标识!
      方法二:
      修改编译选项,将/MD/MDd 改为 /MT/MTd,这样就实现了对VC运行时库的静态链接,在运行时就不再需要VCdll了。
      方法三:
      工程-》属性-》配置属性-》常规-》MFC的使用,选择在静态库中使用mfc”
      这样生成的exe文件应该就可以在其他机器上跑了。
      方法四:
      你的vc8安装盘上找到再分发包vcredist_xxx.exe和你的程序捆绑安装
      在大部分机上都可以运行了,唯独在我的测试机上还是报应用程序配置错误。刚开始怀疑是还缺少dll,在能跑的机上把windows/system32目录下所有的msvc*.dll都复制到这台机的运行目录,还是不行!极度郁闷×…!后来实在没辙了,就在VC环境中打开了EXE来查看它内嵌的manifest资源,无奈了看了一会,带着心中对manifest的咒骂,突然发现这个manifest带了两个版本CRT的依赖:
          再打开Microsoft.VC80.CRT.manifest一看,是这样:
        就是说,我们EXEManifest里多了一个版本依赖,那就把后面那个依赖删除试试。于是就把工程设置的生成manifest的选项去掉,手工改了一下manifest放到程序目录下,发现果然可以运行了!
      还有个问题没有明白,就是VC为什么在自傻膍anifest里带了两个依赖呢,上网再查了一下,发现在msdnonline上说'8.0.50608.0'这个版本是在XP下用的,'8.0.50727.762'这个版本是在Vista下用的(http://msdn.microsoft.com/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文件,比如文件的内容是:
     
      <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
     
      <assembly xmlns='urn:schemas-microsoft-com:asm.v1'  manifestVersion='1.0'>
     
      <dependency>
     
          <dependentAssembly>
     
            <assemblyIdentity type='win32'  name='Microsoft.VC80.CRT' version='8.0.50727.762' processorArchitecture='x86'  publicKeyToken='1fc8b3b9a1e18e3b'  />
     
          </dependentAssembly>
     
      </dependency>
     
      <dependency>
     
          <dependentAssembly>
     
            <assemblyIdentity type='win32'  name='Microsoft.VC80.MFC' version='8.0.50727.762' processorArchitecture='x86'  publicKeyToken='1fc8b3b9a1e18e3b'  />
     
          </dependentAssembly>
     
      </dependency>
     
      <dependency>
     
          <dependentAssembly>
     
            <assemblyIdentity type='win32'  name='Microsoft.VC80.DebugCRT' version='8.0.50727.762'  processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
     
          </dependentAssembly>
     
      </dependency>
     
      </assembly>
     
            
    需要注意这个文件中的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 installation of two different Visual C++ toolsets. It will  also allow you to produce reliable, self-describing applications and  components that will not conflict with existing components. For more  information on the advantages of new deployment model, please see Concepts of Isolated Applications and Side-by-side  Assemblies. To learn about how this may impact deployment of  existing native C++ applications, please refer to Redistributing Visual C++ Files.

    Visual C++ libraries have been packaged in several  shared side-by-side assemblies with corresponding manifest files.

    Assembly Name

    DLLs included in the assembly

    Visual C++ Library

    Microsoft.VC90.ATL

    atl90.dll

    Active Template Library

    Microsoft.VC90.CRT

    msvcr90.dll

    msvcp90.dll

    msvcm90.dll

    C Runtime Library, release DLLs

    Microsoft.VC90.DebugCRT

    msvcr90d.dll

    msvcp90d.dll

    msvcm90d.dll

    C Runtime Library, debug DLLs

    Microsoft.VC90.MFC

    mfc90.dll

    mfcm90.dll

    mfc90u.dll

    mfcm90u.dll

    Microsoft Foundation Classes, release DLLs

    Microsoft.VC90.DebugMFC

    mfc90d.dll

    mfcm90d.dll

    mfc90ud.dll

    mfcm90ud.dll

    Microsoft Foundation Classes, debug DLLs

    Microsoft.VC90.MFCLOC

    mfc90chs.dll

    mfc90deu.dll

    mfc90esp.dll

    mfc90ita.dll

    mfc90kor.dll

    mfc90cht.dll

    mfc90enu.dll

    mfc90fra.dll

    mfc90jpn.dll

    Microsoft Foundation Classes, localized resources

    Microsoft.VC90.OpenMP

    vcomp.dll

    OpenMP Library, release DLLs

    Microsoft.VC90.DebugOpenMP

    Vcompd.dll

    OpenMP Library, debug DLLs

    展开全文
  • 最近几天被这个问题困惑了许久。 不禁感叹微软的东东真是越做越... 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的
  • VC2005-"应用程序正常初始化失败"-0xc0150002(转载)文章来源:... 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CR
  • LuaForWindows 安装失败解决办法

    千次阅读 2020-07-02 09:45:38
    1.安装"Lua for Windows"需要预先安装VC2005 sp1运行时库,否则无法安装成功 Visual C++ 2005对于广大玩游戏的朋友来说可以说是必备的软件,少了它,很多软件都无法运行 安装说明 1、重要事项:请确保您具有所...
  • 如果你尝试在 Windows Vista 或在安装完 IE7 的系统上创建 Win32 智能设备项目,你可能已经见过一个在任务栏中提示“项目创建失败”的错误。这是一个已知的问题,并已经在 VS2005SP1 中被修补。不过如果你没法...
  • 最近在某所调试代码。 不禁感叹微软的东东真是越做越烂... 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的; 有让清
  • 最近几天被这个问题困惑了许久。 不禁感叹微软的东东真是越做越烂了,也终于... 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷
  • 这两天配制vega prime 2.2.1的vc编程环境实在是太痛苦了,一开始选用vs2003,各种链接错误,在网上搜了好久也没找到正确的解决方法,一狠心重新安装了vs2005,按照配制要求添加库文件和包含文件,终于编译成功了,但...
  • 应用程序正常初始化 0x0150002失败

    千次阅读 2013-07-09 17:22:05
    查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的; 有让清理注册表的;有让装.NetFramework新版本的;有让查...
  • VC2005编译的程序,编译时没有任何错误,但是运行时... 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的; 有让清
  • 2.此计算机缺少 vc2005_sp1_with_atl_fix_redist,请安装所有缺少的必要组件,然后重新运行此安装 3.输入注册码失败 如果这个方式不行,先用管理员权限打开cmd,再用上文的方法复制路径在管理员权限的cmd下运行就...
  • Error 1935.安装程序集 type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="...显然是visual studio 2005 sp1没有安装...
  • 查找了各方面资料,做了各种尝试,网上说什么的都有:有让安装vc2005 sp1补丁的;有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的; 有让清理注册表的;有让装.NetFramework新版本的;有让查...
  • 解决方法:进入...\loadrunner11\lrunner\En\prerequisites\vc2005_sp1_redist路径下(...表示Loadrunner的安装路径),重新执行exe文件即可。 2、LR脚本录制过程,脚本为空 原因: IE浏览器版本不正确; IE浏览...
  • 2010-05-19 23:30 ...如果是vc8.0(vs2005) 安装以下两个补丁 第一个补丁 : VS80sp1-KB926604-X86-CHS.exe(中文版) http://www.microsoft.com/downloads/details.aspx?FamilyID=bb4a75ab-
  • 如果是vc8.0(vs2005) 安装以下两个补丁 <br />第一个补丁 : VS80sp1-KB926604-X86-CHS.exe(中文版) <br /> ...
  • 眼睛卫士光放3.21版本

    2012-03-26 23:24:56
    用VS2005重新建立工程编译,解决没有VC8环境时无法启动 v3.2 Final by 语晨 改用VS2005编译,从优化大小改为优化速度 取消禁止更改时间功能 解决托盘菜单同时弹出系统菜单的问题 修正锁屏后三处严重的资源...
  • 背景:在性能测试项目上,需要安装到LR11进行性能测试,...问题1:安装LoadRunner时出现“计算机缺少vc2005_sp1_with_atl_fix_redist” 解决方法:在lr安装包里面 loadrunner-11\lrunner\En\prerequisites\vc2005_s...

空空如也

空空如也

1 2
收藏数 30
精华内容 12
关键字:

vc2005sp1安装失败