Windows运行库高效管理：8年脚本经验打造稳定开发环境

　　去年7月那会儿，我原以为给开发机装运行库是手到擒来的事儿——毕竟写了八年脚本，从VC++ 2005到.NET 6.0，哪个版本没碰过？结果第一周就被运维老张的机器教做人了。他电脑里同时躺着VC++ 2010 SP1和2012 RTM版，安装目录里DLL版本号乱得像被狗啃过的乐谱，连PowerShell的Get-ChildItem都报错“路径太长”。我当时盯着屏幕直乐——这可比需求评审时产品经理突然改优先级有意思多了。

　　真正让我拍桌子的，是发现有些机器装完运行库后，VS2022的调试器直接罢工。排查了两小时才发现，是某个旧版MSVCR120.dll被系统路径优先加载了，而新版本在子目录里躺尸。我直接甩了个批处理脚本到群里：“把系统PATH里所有‘C:\Program Files (x86)\’开头的条目全删了，只留‘%SystemRoot%\system32’和‘%SystemRoot%\SysWOW64’。”结果运维小王回：“可有些老项目依赖旧路径啊。”我回他：“那你们是想要稳定的环境，还是想要能跑但随时可能崩的环境？”——这话放需求评审里能吵三天，但在技术群里，五分钟就没人说话了。

　　最离谱的是上周五，测试组小李的机器突然报“缺少VCRUNTIME140_1.dll”。我远程过去一看，好家伙，这机器上装了VC++ 2015-2022的所有版本，从14.0到14.36.32532，安装目录里光“redist”文件夹就有七个。我原以为用DISM命令修复系统镜像能解决，结果运行完发现系统版本还是19044.3086——和之前一样。最后没办法，直接从另一台正常机器上拷贝了DLL文件过去，顺便把注册表里所有“Visual C++ Redistributable”相关的键值全导出来对比，才发现有个旧版本的安装记录没删干净。这时候外面突然下雨了，雨点砸在机房玻璃上的声音，和测试组在群里狂刷“解决了”的消息，混在一起特别魔幻。

　　要说这八年脚本经验到底有啥用？我觉得就俩字：优胜劣汰。比如现在给新机器装运行库，我直接写个PowerShell脚本，先卸载所有旧版VC++（包括那些藏在Program Files (x86)\Common Files\Microsoft Shared\VCRuntime里的残骸），再用choco install vcredist-all一键装最新版，最后用reg query检查注册表里有没有残留的安装记录。要是遇到顽固分子，就手动删C:\Windows\Installer里的.msi文件——别问我怎么知道的，上次为这事儿和运维吵了半小时，最后发现是他用CCleaner清过系统，把Installer的缓存给删了。

　　但有些事儿真说不准。比如上周二，我按这套流程给二十台开发机重装运行库，结果有三台装完后VS2022的智能提示没了。排查了半天，发现是这些机器之前装过旧版“Visual Studio Tools for Office”，卸载时没删干净某个COM组件。最后只能手动注册msvcr120.dll和msvcp120.dll——这招还是从Stack Overflow上抄的，原帖下面有人评论“这比需求评审还玄学”。我到现在都没搞明白，为什么同样的脚本在不同机器上表现不一样——可能是系统补丁版本不同？可能是杀毒软件拦截了注册操作？也可能是机房的空调温度影响了硬盘读写速度？

文章配图，仅供参考

　　下一步我打算把这套脚本改成自适应的——根据机器的硬件配置、系统版本、已装软件，自动调整安装策略。但说真的，我有点怕。因为一旦开始搞自适应，就意味着要处理更多变量，而变量越多，出问题的概率就越高。就像需求评审时，产品经理说“这个功能要简单”，结果PRD写了三十页——有时候“稳定”和“灵活”就是一对死对头。不过算了，先写着吧，大不了再踩几年坑——反正运维的奶茶钱，我是赚定了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!