程序移植的问题: 万恶的微软,万恶的的VC 2005分发包版本: 8.0.50727.4053
2009-11-21 12:57
295 查看
把程序移植到另外一台电脑上运行,问题多多,让我始料未及,
我以为在目标机器上安装了VC2005分发包:vcredist_x86.exe 就可以万事大吉了,
结果牛B的微软再一次让我领教到了他的厉害...再一次被折磨.
本来分发包的版本都是762:
但是我打开清单文件一看:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
发现嵌入的清单文件都是version="8.0.50727.4053"这个版本,难怪在目标机器上运行不了,
目标机器安装了vcredist_x86.exe只有"8.0.50727.762"版本的库.
难道windows什么时候偷偷更新了我的依赖库文件?
上网查了下,果然这样,2009/7/12号的时候微软更新了一个什么漏洞,顺便帮我增加了最新的库
你多一个新版本的库没有关系,反正可以并行运行的,但是万恶的微软强行我们使用最新的库~~~4043版本
真是流氓
要解决,办法2个:
一是屈服微软,在目标机器上也安装最新的库
二是干掉微软,卸载相关补丁...这个有点狠,
不过我用了一个不错的办法,就是找一个没有更新到4043的机器,上面只有762版本的库,在上面生成好可执行程序exe和dll文件,就都是762版本的了,再发布到其他机器上,
我以为在目标机器上安装了VC2005分发包:vcredist_x86.exe 就可以万事大吉了,
结果牛B的微软再一次让我领教到了他的厉害...再一次被折磨.
本来分发包的版本都是762:
文件名: | vcredist_x86.exe |
版本: | 8.0.50727.762 |
发布日期: | 2007/11/15 |
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
发现嵌入的清单文件都是version="8.0.50727.4053"这个版本,难怪在目标机器上运行不了,
目标机器安装了vcredist_x86.exe只有"8.0.50727.762"版本的库.
难道windows什么时候偷偷更新了我的依赖库文件?
上网查了下,果然这样,2009/7/12号的时候微软更新了一个什么漏洞,顺便帮我增加了最新的库
你多一个新版本的库没有关系,反正可以并行运行的,但是万恶的微软强行我们使用最新的库~~~4043版本
真是流氓
要解决,办法2个:
一是屈服微软,在目标机器上也安装最新的库
二是干掉微软,卸载相关补丁...这个有点狠,
不过我用了一个不错的办法,就是找一个没有更新到4043的机器,上面只有762版本的库,在上面生成好可执行程序exe和dll文件,就都是762版本的了,再发布到其他机器上,
相关文章推荐
- 终结VC2005分发包版本问题
- 从VC到EVC程序的移植问题汇总
- VC程序Debug版本和Release版本运行不一致问题
- 针对VC版本及相关库的升级后程序无法运行问题举例说明
- VC6代码移植到高版本VC时候的常见问题
- 程序从VC6移植到VS2005环境下的常见问题(一)
- 低版本GCC程序向高版本移植的兼容性问题
- 程序从VC6移植到VS2005环境下的常见问题(二)
- 遇到过的问题,备忘, VC2008发布程序时指定库版本[转载]
- 程序从VC6移植到VS2005环境下的常见问题(三)
- VC程序Debug版本和Release版本运行不一致问题
- vc多线程程序移植到vs2005以上,所遇到到映射问题
- VC分发包版本问题
- VC++ 实现VC程序启动时最小化到任务栏(完美解决闪烁问题)
- VC6编译的Debug版本程序中存在的问题及解决方法
- android studio 升级后,经常会对gradle升级,然后编译原来程序会出现gradle版本太老的问题
- VC编译C程序时的问题解析
- 关于VC开发的程序在别人电脑不能运行的问题
- VC获得程序自身的版本号
- 从VC6到VC2008移植代码问题总结收藏