1176人阅读
当时我们在发布程序的时候，安装的时候出现：&应用程序配置不正确，..."具体不太记得了，怀疑是依赖dll文件没有被打包进来，但是具体是哪一个呢不清楚，开始使用Depends工具来查看，但这种方法太费劲了，看了这篇文章之后，才知道这原来都是微软为了摆脱&Dll地狱&设置出来的manifest,通过manifest就可以看到，或者是直接打开用vc打开应用程序查看RT_MANIFEST,我们最后就是用了该篇文章的最后一段来解决这个问题的。直接复制将该文件夹下的所有dll打包到应用程序中，搞定！
[现象]对这个问题的研究是起源于这么一个现象：当你用VC++2005（或者其它.NET）写程序后，在自己的计算机上能毫无问题地运行，但是当把此exe文件拷贝到别人电脑上时，便不能运行了，大致的错误提示如下：应用程序配置不正确，请重新安装程序&&或者是MSVCR80D.dll 没有找到什么的（我记得不是很清楚，不过大致是这样的）[分析]看到这样的提示，当然不会傻到重装咯。第一反应应该是什么配置有问题、或者是缺少了什么依赖的库文件；于是我就根据以前Windows缺少库文件的经验，把所有库文件（&&.DLL）统统一股脑地复制到当前文件夹下来，满心欢喜以为可以运行了，以运行&&@#￥@#％￥&&还是挂了。[探索]于是开始网上搜索，我Google，我摆渡；渐渐我发现，这一切都和一个叫做***.manifest 类型的文件发生关系，那么到底什么是 .manifest 文件呢？他有什么用，以前为什么没有？后来，经过艰苦努力，终于得知，原来这一切都是Windows 的Assembly Manifest搞的鬼。这个东东的作用就是为了解决 以前windows上的&Dll 地狱& 问题才产生的新的DLL管理解决方案。大家知道，Dll是动态加载共享库，同一个Dll可能被多个程序所使用，而所谓&Dll 地狱&就是当不通程序依赖的Dll相同，但版本不同时，由于系统不能分辨到底哪个是哪个，所以加载错了Dll版本，然后就挂了。于是盖茨就吸取了教训，搞了一个程序集清单的东东，每个程序都要有一个清单，这个清单存再和自己应用程序同名的.manifest文件中，里面列出其所需要的所有依赖，这儿所列出的依赖可不是简单地靠文件明来区分的，而是根据一种叫做&强文件名&的东西区分的，那么什么是强文件明呢？我们来看一下这个.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.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /&&/dependentAssembly&&/dependency&&/assembly&
我们发现原来这是一个XML格式的文件，其中&dependency&这一部分指明了其依赖于一个名字叫做Microsoft.VC80.CRT的库。但是我们发现，&assemblyIdentity&属性里面还有其它的东东，分别是type系统类型，version版本号，processorArchitecture平台环境，publicKeyToken公匙（一般用来标示一个公司）&&把他们加在一起便成了&强文件名&了，有了这种&强文件名&，我们就可以根据其区分不同的版本、不同的平台&&总之，有了这种强文件名，系统中可以有多个不同版本的相同的库共存而不会发生冲突。[深入]恩，那么现在，我们就来具体了解一下这一套机制。首先是强弱文件名的问题。正如上面提到的那样，为了区分不同版本或不同厂商生成的相同的程序集，必须用一个Assembly Manifest程序清单来列出我这个程序集的强文件名－－慢着，到这里你可能会问：刚才不是说Assembly Manifest程序清单是列出其所依赖的程序集的强文件名呢，怎么这里变成了当前文件的强文件明了呢？其实，Assembly Manifest程序清单有两部分功能，上面这个实例之所以标注了其所依赖的文件的强文件名是因为其是客户端的Assembly Manifest，在服务端有另外一个Manifest 来标注。
[应用]经过以上的讲解，大家对整个依赖查找过程都有了一个整体的认识，那么在实际中问题就好解决了。让我们回到实际问题中，我之前说了，把一个程序编译连接成可执行程序后，在别人的电脑上发现找不到其所依赖的库了，那么怎么办呢？聪明的你自然想到把其所依赖的库相应的版本拷贝到目标计算机上面，可是&&当你在拼命寻找那个可执行文件的assembly manifests文件的时候，却突然发现找不到了，在执行目录下面明明只有一个exe文件嘛。是不是没有生成呢？显然不会，原来是资源连接器把那个assembly manifests文件连接到了可执行文件里面了；不信，你可以用你的vc++打开一个可执行文件看看，在其资源项里面就有一个叫做RT_MANIFEST的项目。这个里面就是二进制标示的manifests文件。那么根据这里面提供的要求，将相应版本的依赖文件（一般就是CRT运行库）拷贝到系统目录Windows/WinSxS/，记住一般会是连带着一个特殊命名的目录一起拷贝到那个文件夹下，比如CRT的运行库就是WinSxS/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50608.0_x-ww_b7acac55有这样一个目录，其标注了此库的版本号以及签名等信息，以防止多个版本重名时不能复制到同一WinSxS目录下。这样就搞定了么？如果是以前，那么一切都解决了，系统会在这个目录下面找到这个运行库，可是现在单单这样可不行，系统可是要找到这个运行库的assembly manifests文件，并且对比强文件名之后才能加载，所以所以千万别忘了把相应的manifests文件拷贝到/WinSxS/Manifests目录下面。当然，这样在目标的系统文件夹下面打动干戈，自然有些过于暴动了，还好，Windows还为我们提供了一种私有查找方式。这种方式会在前面的位置找不到合适库的时候在本地文件夹下面找。所以你只要把之前的库以及那个manifests文件一起拷贝到你的应用程序的路径下面，就可以使用啦。根据MSDN的说明，在本地查找并加载遵循一下规则：
在应用程序本地文件夹中查找名为 &assemblyName&.manifest 的清单文件。在此示例中，加载程序试图在 appl.exe 所在的文件夹中查找 Microsoft.VC80.CRT.manifest。如果找到该清单，加载程序将从应用程序文件夹中加载 CRT DLL。如果未找到 CRT DLL，加载将失败。尝试在 appl.exe 本地文件夹中打开文件夹 &assemblyName&，如果存在此文件夹，则从中加载清单文件 &assemblyName&.manifest。如果找到该清单，加载程序将从 &assemblyName& 文件夹中加载 CRT DLL。如果未找到 CRT DLL，加载将失败。
最后，我想补充的一点是，在你的VC++安装目录下面的&Microsoft Visual Studio 8/VC/redist&目录下，有着所有的提供发布的已经配备相应.manifest的库文件。所以你想要发布一个程序最简单最安全的做法（不用担心用户电脑是否包含你所需要的库）就是把这个目录下面的相应的库的文件夹和你的可执行文件放在一起发布。比如在X86平台下如果你的可执行文件用到了CRT库（废话么），那么就拷贝Microsoft Visual Studio 8/VC/redist/x86/Microsoft.VC80.CRT这个文件夹到你的程序所在的目录，一起发布，就万事大吉啦！
&?xml version="1.0" encoding="UTF-8" standalone="yes"?&&assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"&&noInheritable&&/noInheritable&&assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"&&/assemblyIdentity&&file name="msvcr80.dll" hash="2a0d797a8c5eac76e54e98db4b45" hashalg="SHA1"&&asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&&dsig:Transforms&&dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"&&/dsig:Transform&&/dsig:Transforms&&dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&&/dsig:DigestMethod&&dsig:DigestValue&phRUExlAeZ8BwmlD8VlO5udAnRE=&/dsig:DigestValue&&/asmv2:hash&&/file&&file name="msvcp80.dll" hash="cc4ca55fb6aa6b7bbab77e42f8f91" hashalg="SHA1"&&asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&&dsig:Transforms&&dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"&&/dsig:Transform&&/dsig:Transforms&&dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&&/dsig:DigestMethod&&dsig:DigestValue&<span style="COLOR: #AY1JqoUvK3u/6bYWbOagGgAFbc=&/dsig:DigestValue&&/asmv2:hash&&/file&&file name="msvcm80.dll" hash="55e8e87bbde00d1d96cc119ccd94e0c02c9a2768" hashalg="SHA1"&&asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&&dsig:Transforms&&dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"&&/dsig:Transform&&/dsig:Transforms&&dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&&/dsig:DigestMethod&&dsig:DigestValue&hWq8zazTsMeKVxWFBa6bnv4hEOw=&/dsig:DigestValue&&/asmv2:hash&&/file&&/assembly&
这个便是从WINDOWS/WinSxS/Manifests目录下取出来的一个manifest文件，再这个文件夹下有一陀子这种XML格式的manifest文件，其是服务端的程序清单。WinSxs是windows XP以上版本提供的[blue]非托管并行缓存（side-by-side catche）[/blue]里面安装了各种版本的经过强文件名签名的系统库，而上面这个文件&assemblyIdentity&正是标注了系统中Microsoft.VC80.CRT的一个版本的强文件名签名，如果其和客户端。.manifest 清单里面&dependentAssembly&所列出的依赖项对上的话，就会被加载。刚才说的side-by-side 是指各种不同的版本并行运行。上面这个服务端manifest文件中&file&标签具体指明了当前强文件名签名的到底是哪一个文件，其中还有这个文件的Hash签名，以确保文件的完整性。好了，有了这一套机制，就可以非常非常安全地进行库文件关联了，但是、但是貌似还有一个一直困扰我们的问题：这套机制安全是安全了，但是却失去了以前良好的前后版本兼容性，即如果你的系统库发生了升级，那么服务端的版本号发生了变化，那岂不是所有服务端程序都不能使用了吗？其实，windows还使用一个policy的策略文件来确认映射关系。
&?xml version="1.0" encoding="UTF-8" standalone="yes"?&&!-- Copyright ?
Microsoft Corporation --&&assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"&&assemblyIdentity type="win32-policy" name="policy.8.0.Microsoft.VC80.CRT" version="8.0.50727.42" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/&&dependency&&dependentAssembly&&assemblyIdentity type="win32" name="Microsoft.VC80.CRT" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/&&bindingRedirect oldVersion="8.0..0.50608.0" newVersion="8.0.50727.42"/&&/dependentAssembly&&/dependency&&/assembly&
这便是在WINDOWS/WinSxS/Policies目录下的一个Policy文件，其中&bindingRedirect&标签便指定了所有8.0..0.50608.0变本的客户需求映射到8.0.50727.42这个我现在系统中安装的比较新的版本的库。当然我们也能对别的字段进行映射，这样便能很好解决系统升级带来的问题。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：63162次
积分：1305
积分：1305
排名：第12866名
原创：59篇
转载：30篇
评论：20条
(1)(1)(3)(2)(1)(6)(5)(1)(1)(2)(1)(2)(2)(6)(7)(4)(1)(2)(1)(2)(1)(7)(3)(2)(1)(2)(3)(3)(2)(2)(3)(10)全国统一热线：400-667-9006028-
欢迎光临西部数码，我们将竭诚为您提供最优质的服务！
解决office应用程序配置不正确问题
有关打开某程序时显示：应用程序配置不正确，应用程序未能启动，请重新安装此程序之类的问题反馈，这样的问题不止发生于OFFICE 2007，很多期货类型也有这个问题，例如在使用 VC++2005环境下生成的程序，放置到未安装VC环境的机器下后，就可能会出现这个问题。重装是解决不了问题的，解决的一种方法是查看*exe.intermediate.manifest文件，需要注意这个文件中的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等。此错误发生的原因是在目标机器上需要这些文件的支持。
那么再让我们来看看OFFICE遇到这样的问题如何解决呢？
下面是OFFICEBA为大家收集的一些办法，大家可以尝试：
1、首先当然是按提示尝试重新安装整个OFFICE 2007
2、如果仅仅是某个程序如EXCEL 2007不能启动，而WORD 2007能启动，那么尝试下：试试运行 开始--&Microsoft Office--&Microsoft Office工具--&Office 诊断
3、尝试使用office安装盘修复
4、安装Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) 安装在未安装 Visual C++ 2005 的计算机上运行使用 Visual C++ 开发的应用程序所需的 Visual C++ 库的运行时组件。
此软件包安装 C Runtime (CRT)、Standard C++、ATL、MFC、OpenMP 和 MSDIA 库的运行时组件。对于支持并行部署模式的库（CRT、SCL、ATL、MFC 和 OpenMP），这些运行时组件安装在支持并行程序集的 Windows 操作系统版本的本机程序集缓存中，这一缓存也称为 WinSxS 文件夹。有关 Visual C++ 应用程序受支持的部署方式的详细信息
版权申明：本站文章均来自网络，如有侵权，请联系028- ，我们收到后立即删除，谢谢！
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有。
&#160;热点关注
服务器技术
CopyRight &#169; &#160;西部数码&#160;版权所有
电话总机：028- (50线)&#160;&#160;&#160;&#160;&#160;&#160;传真：028-
400电话： 400-667-9006为什么我的联想I909手机安装JAVA程序的时候提示应用文件的安装网址不正确？求高手帮忙解决。拜谢。
- 第一专业IT门户网站
为什么我的联想I909手机安装JAVA程序的时候提示应用文件的安装网址不正确？求高手帮忙解决。拜谢。
应该是你的JAVA程序有问题，没有下载完全或不兼容的原因！你可以去下载N记6300的JAVA程序来安装，或去中关村的联想I909论坛下载游戏！
等待您来回答
该问题来自：太平洋电脑网是首家以专业电脑市场联盟为基础的IT资讯网站，为IT企业与终端用户提供全面、权威、专业的IT资讯服务。手机领域专家
当前分类官方群讨论、解答、交流电脑数码相关的疑难问题玩游戏由于应用程序配置不正确，程序无法启动，重新安装程序可能会解决此问题。_百度知道
玩游戏由于应用程序配置不正确，程序无法启动，重新安装程序可能会解决此问题。
,该怎么修复,,没用,,,,,,,,,,这到底怎么一回事,,,又安装64版,,重装系统打开依然没用,,,说安装个什么vcredist（86）,安装了,还是没用,,
提问者采纳
速度越来越感觉比较慢,卸载了大量的应用程序,软件就运行正常了。,1fc8b3b9a1e18e3b&#39,终止应用程序”,0,有兴趣的可以了解下,intermediate,这些软件出现“由于应用程序配置不正确,使用最新版本的世界之窗浏览器,一起打包。这些文件也就是mfc80,MFC&#39,比如文件的内容是,,VC80,dependentAssembly&#47,查到“(0xc0000135)”原因是没有安装,Microsoft,然后考虑到和其它软件有冲突,Program Files&quot,CRT,VC80,本来操作系统是默认安装这些组件的,NET Framework 3,1fc8b3b9a1e18e3b&#39, &#47,5版本了,另外,维护和优化, version=&#39,在安装过程中,762&#39,msvcp80,net程序引起的,开始也没太在意,下载了微软网站上的,8,dll,8,应用程序未能启动。重新安装应用程序可能会纠正这个问题”提示,1,无法再继续运行,反而regedit出了一大堆“由于应用程序配置不正确,优化大师对系统进行清理,程序无法启动,这在以前都是没有的现象,,今天使用电脑,报“由于应用程序配置不正确,VC80,卸载程序时,Microsoft,另外,拷贝它们下面所有的文件到希望发布的EXE文件下面,UTF-8&#39,它的进程也确实太多,也随之解决了。csdn中有一篇文章, processorArchitecture=&#39,故障依旧,dependencydependencydependentAssemblyassemblyIdentity type=&#39,0&#39,于是到“添加&#47,这就比较让人惊异了。另个,manifest等。此错误发生的原因是在目标机器上需要这些文件的支持。看到最后才知道,考虑就优化下电脑系统,顺便看下几个常用软件的问题。具体报故障现象是,schemas-microsoft-com,redist文件夹下面,Microsoft Visual Studio 8&quot,程序运行时,能运行的问题,造成很多需要VC运行库的程序无法正常运行了。 至于那个“(0xc0000135)”问题,dll) do regsvr32,通过把这个句子“由于应用程序配置不正确, encoding=&#39,把这些组件给删除了,它都会报有恶意代码,占用内存比较厉害,应用程序未能启动。重新安装应用程序可能会纠正这个问题”,VC&quot,出错,50727,有时候会出现程序无法执行的错误, publicKeyToken=&#39,*,就是缺乏软件应用环境,xml version=&#39,但可能是由于其他原因,就像vb程序需要vb运行库那个道理一样,dependentAssembly&#47,,1fc8b3b9a1e18e3b&#39,762&#39,因为大多数应用程序都是一些绿色版本,应用程序未能启动。重新安装应用程序可能会纠正这个问题”添加到搜索引擎搜索,找到这些名称的子文件夹,在使用 VC++2005环境下生成的程序,x86&#39, manifestVersion=&#39,CRT,打开dreamweaver cs3,应用程序配置不正确,762&#39,应用程序未能启动。重新安装应用程序可能会纠正这个问题”的提示。运行360安全卫士,x86&#39,50727,dll和Microsoft,5几个版本了以后,感觉小红伞判断代码是有些过于敏感了,,重新安装也是无法解决这个问题的,从而程序也无法继续运行。开始考虑是杀毒软件引起的,这可以通过卸载它可以判断出来。虽说有免费的三个月key, publicKeyToken=&#39, processorArchitecture=&#39,VC80,dependency&#47,解决的一种方法是查看*exe, &#47,现在最高版本可能是3,assembly需要注意这个文件中的3个关键词,也有软件报“应用程序正常初始化(0xc0000135)失败,win32&#39,问题还是存在,后来,VC80,exe也总是报警,带防火墙的,DebugCRT&#39,dependencydependencydependentAssemblyassemblyIdentity type=&#39,x86&#39,重装是解决不了问题的, version=&#39,还有假死状态,v1&#39,0,删除程序”里面,Microsoft,再次测试,system32&#47,在百度知道中, name=&#39,上个问题解决了,50727,displaylang=zh-cn,NET Framework 就ok了,只要再安装Microsoft ,对纳米下载器程序DuTool,&#47,adobe photoshop cs时显示“由于应用程序配置不正确,dependencydependentAssemblyassemblyIdentity type=&#39,Microsoft, name=&#39,VC80,8,manifest文件,asm,urn,Microsoft,为排除问题,有些asp官方正常程序的代码,&#47,MFC和Microsoft,应用程序未能启动。重新安装应用程序可能会纠正这个问题”运行提示,用的是小红伞的三个月最新免费版本,重新安装应用程序可能解决问题。实际上, standalone=&#39,exe &#47,发现有文章说明了这个问题的解决办法, &#47,因此,1,当然我使用的那个snagit的不能启动问题,安装之后解决了adobe系列无法启动的问题,但无意中得知安装 Microsoft Visual C++ 2005 Redistributable 可以解决,但通过下载Microsoft ,msvcr80,无法顺利安装完成,CRT&#39, publicKeyToken=&#39,其提示是,,也算属正常,介绍得比较深层次一些,assembly xmlns=&#39,dll,DebugCRT。寻找到,放置到未安装VC环境的机器下后,dependentAssembly&#47,出现问题,s %1”, name=&#39,卸载掉。故障依旧,win32&#39,0&#39,&quot, processorArchitecture=&#39,&#47,用那个注册所有组件的命令“for %1 in (%windir%&#47,yes&#39,当然,VC80,win32&#39, version=&#39,0,请单击“确定”,到微软网站上下载安装,
提问者评价
其实..不知道怎么回事...我在安装游戏：007血钻石就把VC和DX装上了。。。都可以玩了...不过还是谢谢你。
其他类似问题
按默认排序
其他2条回答
找个免CD补丁一打就可以了。更和系统没有任何关系。应用程序错误,别装X64的。最后一招就是重新安装,故悄蔷浠,可能是内存的问题,希望可以帮助你。,但更多是软件的问题。缺补丁,你要安装的是什么,装X86的,补丁版本不正确,把杀毒关闭,不用那么麻烦,把杀毒干掉了,安装前,另外,如果是游戏,
是不是客户端的问题呢，从新下个别的试下呢？
应用程序的相关知识
等待您来回答
您可能关注的推广回答者：
下载知道APP
随时随地咨询
出门在外也不愁}