刚使用Win7 系统不久，前段时间在清理系统垃圾时发现，win7系统的windows文件夹下的winsxs 文件夹占用空间很大，想清理之，却提示无权限无法清理。随即在网上查了个到底，原来winsxs是一个超大的文件仓库，系统所在分区差点儿全部的系统文件都在那里至少有一个备份。并且随着系统的使用，winsxs的所占的空间还将不断的积累壮大，终于将吞噬整个系统分区的磁盘空间。以下附上搜索来的一篇winsxs的具体描写叙述文摘、winsxs的瘦身方法和一篇关于 DLL Hell问题 的描写叙述文摘和大家分享：

winsxs的具体描写叙述文摘：

***

winsxs的目录位于Windows根目录，是一个超大的文件仓库，系统所在分区差点儿全部的系统文件都在那里至少有一个备份。有兴趣的网友最好还是通过搜索功能在winsxs搜一下公用视频、公用图片、公用音乐目录里的文件，你会发现那些精简系统时已经被删除了的文件在winsxs里还能够找到影子。假如系统文件被删除或者破坏，用命令sfc /scannow就能够恢复，但假设将winsxs里面的不论什么一个重要的组件删除，sfc命令就会失效。系统在线更新的过程是旧版本号文件被新版本号的代替，旧文件自己主动备份在winsxs里；卸载补丁的过程是系统新版本号文件被旧版本号的代替，而旧版本号文件的来源正是winsxs。XP也有相似的功能，但XP下备份文件是能够直接删除的，Vista和Win7下不行。所以Vista和Win7占用的空间随着更新增多会越来越大，并且大得惊人。winsxs里的文件非常重要，建议不要删除，以我长期的实践经验，临时发现仅仅有ManifestCache和Temp两个目录里的缓存文件才干够安全删除。

特别提醒：网上全部精简winsxs的方法都有一定的危急性（微软官方的工具除外），比如“删除Backup目录或用空文件代替同名文件”，尽管它叫Backup，但里面绝对不是备份文件而是关系到系统是否能正常更新和正常“打开或关闭Windows功能”的关键文件，某些大量被转载的文章都在误导人。某软件提供删除Windows内置字体，帮助文件的方法，事实上这对于精简系统是没有不论什么意义的，字体和帮助文件在winsxs另一个备份，两个同样的文件共用一个储存空间，换句话说，删除前和删除后C盘可用空间不变！可是注意，假设你查看文件或者目录的属性，他们都会占空间。又如有人提出删除winsxs里同名文件较低版本号的一个或几个，这是一个非常好的想法，但问题是有些同名文件的不同版本号都有重要作用，都不能删除，比如.Net Framework的相关组件。

***

winsxs的瘦身方法：

***

清理winsxs的小工具

由于磁盘空间不够了，所以想起来清理一下系统垃圾文件，主要目标就是臭名昭著的winsxs文件夹。这个winsxs就是微软为了解决“dll hell”问题，结果是好比在windows系统里安置了一个毫无克制不断增大的“肿瘤”。听说微软研究院如今在研究这个问题，只是我想我的硬盘空间不够大，等不到这个补丁出来的时候，所以仅仅好自己动手了。

winsxs文件夹下的文件都是系统要用的各种库文件，system32下存放了这些dll的最新的版本号，全部老版本号的dll都放在winsxs下。所以仅仅要你安装程序或者更新补丁，system32下的文件就会被更新，而同一时候winsxs就会添加一些旧文件，所以我们的C盘空间就在持续不断地降低，直到磁盘容量不够，被迫重装系统为止，假设你足够幸运，能够直接安装最新的SP的话，也许能够为winsxs节约一点微薄的空间。

winsxs文件夹下的不同版本号文件都存放在特定命名规则的文件夹下，比方

C:/Windows/winsxs>dir msil_microsoft.transactions.bridge.resources*
驱动器 C 中的卷是 vista
卷的序列号是 989F-EFF3

C:/Windows/winsxs 的文件夹

msil_microsoft.transactions.bridge.resources_b03f5f7f11d50a3a_6.0.6000.16386_zh-cn_1cde5a17d78fb5ec
msil_microsoft.transactions.bridge.resources_b03f5f7f11d50a3a_6.0.6000.16716_zh-cn_1cd75781d79605cf
msil_microsoft.transactions.bridge.resources_b03f5f7f11d50a3a_6.0.6000.20876_zh-cn_060fb27df137fddf
msil_microsoft.transactions.bridge.resources_b03f5f7f11d50a3a_6.0.6001.18000_zh-cn_1cb2dbd3d7e75eb8
msil_microsoft.transactions.bridge.resources_b03f5f7f11d50a3a_6.0.6001.18106_zh-cn_1cb252ffd7e7f8cf
msil_microsoft.transactions.bridge.resources_b03f5f7f11d50a3a_6.0.6001.22221_zh-cn_05e71ebbf18d0b5e
msil_microsoft.transactions.bridge.resources_b03f5f7f11d50a3a_6.0.6002.18005_zh-cn_1c8e610fd838f2cc
0 个文件 0 字节
7 个文件夹 5,382,139,904 可用字节

这里的各个部分用下划线切割，当中我们关注的是“6.0.6000.16386”部分，它表示旧文件的版本号号，之前则是唯一文件标识，之后是语言，最后部分是散列值（防止名字冲突）。

本工具的设计思想就是删除全部的旧文件。全部满足例如以下全部条件的文件夹都会被移动到C:/Windows/winsxs_del文件夹中。
存在比自身更新的版本号
本身不是最新版本号

执行工具前的C盘剩余空间：

所列文件总数:
4473 个文件 3,336,376,627 字节
7655 个文件夹 326,840,320 可用字节

C:/Windows/winsxs_del>



执行工具而且执行命令

for /d %v in (%SystemRoot%/winsxs_del/*.*) do rd /s /q %v

删除全部能够删除的无用文件之后的剩余空间：

所列文件总数:
52 个文件 7,555,048 字节
131 个文件夹 5,383,979,008 可用字节

C:/Windows/winsxs_del>



工具源码例如以下：请保存为winsxs_clear.bat就可以。全部不再须要的文件会移动到c:/windows/winsxs_del文件夹中，能够直接进行删除。

执行时候，务必请使用“管理员”权限。
@echo off
rem 获取windows版本号
set move_dir=%SystemRoot%/winsxs_del
if not exist %move_dir%/nul md %move_dir%
set winver=none
FOR /F "eol=; tokens=4* delims=] " %%i in (‘ver‘) do set winver=%%i
if "%winver%" == "none" goto enover
echo windows version is %winver%, ready to list winsxs dir.
if not exist %SystemRoot%/winsxs/nul goto enosxs

set ver_prefix=%winver:~0,-1%
echo list winsxs finished! now ready to clear duplicated files 
echo dir /ad %SystemRoot%/winsxs/*_%ver_prefix%*

if "%1" == "run-winsxs-generated" goto :lSkipGen
rem 准备生成代码
copy /y "%~f0" "%temp%/%~nx0" > nul
echo rem genereted code here >> "%temp%/%~nx0"
echo :ldcdStat1 >> "%temp%/%~nx0"
echo set end4=%%arg:%ver_prefix%=%%>> "%temp%/%~nx0"
echo goto ldcdStat2 >> "%temp%/%~nx0"
echo :ldcdStat3 >> "%temp%/%~nx0"
echo set end4a=%%arg:%winver%=%%>> "%temp%/%~nx0"
echo goto ldcdStat4 >> "%temp%/%~nx0"
rem notepad "%temp%/%~nx0"
"%temp%/%~nx0" run-winsxs-generated
goto :EOF

:lSkipGen
FOR /F "eol=; tokens=1-4 delims= " %%a in (‘dir /ad %SystemRoot%/winsxs/*_%ver_prefix%*‘) do (
 if "%%c" == "<DIR>" call:fnDoClear %%d
)

echo clear OK!
goto :EOF

:enover
echo could not get windows version, abort!
goto :EOF

:enosxs
echo not found %SystemRoot%/winsxs! maybe no privilege or lower windows!
echo only support windows XP and later!
goto :EOF

:fnDoClear
rem arg: dir_name
FOR /F "eol=; tokens=1-14 delims=_" %%g in ("%1") do call:fnDoClearDir %1 %%g %%h %%i %%j %%k %%l %%m n %%o %%p %%q %%r %%s %%t %%u %%v %%w %%x %%y %%z
goto :EOF

:fnDoClearDir 
rem arg: dir_name dir_parts 
set d_name=%1
rem 检查參数是否匹配 %winver%, 先跳过前两个.同一时候准备组合新版本号匹配名称,nv1存当前版本号，nv2存当前的前一个版本号
set nv1=%2_%3_
set nv2=%2_%3_
:ldcdCycle
if "%4" == "" goto :EOF
rem 检查是否 ver_prefix 开头,假设是则继续检查是否winver，假设不是winver则表示目标存在
set arg=%4
rem set line=set end4=%%arg:%ver_prefix%=%%
rem %line%
goto ldcdStat1
:ldcdStat2
if "%arg%" == "%end4%" goto ldcdNext
rem 检查是否 winver 开头
rem set line=set end4a=%%arg:%winver%=%%
rem %line%
goto ldcdStat3
:ldcdStat4
if not "%arg%" == "%end4a%" goto :EOF
rem 至此则为 ver_prefix 开头 且 不等于 winver 的文件夹名,检查最新版本号是否存在，存在则可删除旧的
set newfound=false
for /d %%v in ("%SystemRoot%/winsxs/%nv1%%winver%.*_%5_*") do (
 if exist %%v/nul set newfound=true
)  
if "%newfound%" == "true" call:fnDelDir %d_name%

goto :EOF
:ldcdNext
set nv2=%nv1%
set nv1=%nv2%%4_
shift
goto ldcdCycle

:fnDelDir
rem arg: dir
echo del %SystemRoot%/winsxs/%1
takeown /r /f "%SystemRoot%/winsxs/%1"
cacls "%SystemRoot%/winsxs/%1" /t /e /g everyone:f
move "%SystemRoot%/winsxs/%1" "%move_dir%/%1"
goto :EOF



代码导读有助于大家理解程序和算法，可是主要的批处理语法就不讲了，有几年编程经验的我想也看得懂。下面是大致几个要注意的地方：
代码的开头部分是用ver命令获取系统的版本号号，而且存放到%winver%变量中，比方我的ver命令返回就是“Microsoft Windows [版本号 6.0.6002]”，为了获取这个“6.0.6002”，所以要做一些处理，另外，%ver_prefix%中存放的是相似“6.0.600”，为了比較旧版本号号用途。
由于批处理无法实现嵌套嵌入功能，比方我想把从文件夹中分解出来的6.0.6000.16386和%ver_prefix%进行比較，就无法实现了，仅仅好用代码生成大法来处理，在18~24行就是生成代码，该代码在63行和69行调用。26行负责把控制转移到新生成的文件里执行。
由于winsxs文件夹是有特殊权限的，所以先用takeown命令设置当前用户为拥有者，然后用cacls改动文件夹权限，最后用move指令将文件夹转移到winsxs_del文件夹中。假设出现程序无法执行的情况，请手工移动回去就可以。

***

.NET框架解决DLL Hell问题：问题描写叙述 ：

***

从客户的角度，最常见的版本号问题就是我们所说的 DLL Hell 问题。简单地讲， DLL Hell 是指当多个应用程序试图共享一个公用组件（如某个动态连接库（DLL）或某个组件对象模型（COM）类）时所引发的一系列问题。最典型的情况是，某个应用程序将要安装一个新版本号的共享组件，而该组件与机器上的现有版本号不向后兼容。尽管刚安装的应用程序执行正常，但原来依赖前一版本号共享组件的应用程序或许已无法再工作。在某些情况下，问题的起因更加难以预料。比方，当用户浏览某些 Web 网站时会同一时候下载某个 Microsoft ActiveX? 控件。假设下载该控件，它将替换机器上原有的不论什么版本号的控件。假设机器上的某个应用程序恰好使用该控件，则非常可能也会停止工作。

在很多情况下，用户须要非常长时间才会发现应用程序已停止工作。结果往往非常难记起是何时的机器变化影响到了该应用程序。用户可能会回顾起一周前安装了一些东西，但安装与眼下看到的状态并没有不论什么明显的关联。 更糟的是，如今非常少有诊断工具帮助用户（或帮助他们的技术支持人员）确定有什么问题。 

这些问题的解决办法是应用程序不同组件的版本号信息没有由系统记录或加强。并且，系统为某个应用程序所做的改变会影响机器上的全部应用程序—如今建立全然从变化中隔离出来的应用程序并不easy。

非常难建立一个隔离应用程序的一个原因是当前执行时环境仅仅同意单独版本号组件或应用程序的安装。这个限制意味着组件的编写者必须以向后兼容的方式编写他们的代码，否则当他们安装新组件的时候会有终止已有应用程序的风险。实际上，假设可能的话，编写永远向后兼容的代码是非常难的。在 .NET 中，side by side 概念是版本号问题的核心。"Side by side" 是在同一台机器上同一时候执行不同版本号的同样组件的能力。使用支持并列的组件，编程人员不必努力维护严格的向后兼容，由于不同的应用程序自由使用某个共享组件的不同版本号。

.NET框架与DLL Hell问题：公布和安装

如今安装应用程序是多步过程。一般，安装一个应用程序包含复制很多软件组件到磁盘，和在系统中进行一系列描写叙述那些组件的注冊项。

注冊表中的项和磁盘上文件的分隔使复制应用程序和卸载他们非常困难。并且，在注冊表中全然描写叙述某个 COM 类所需的很多项之间关系非常松散。这些项经常包含联合类、接口、类型库和 DCOM app ID 的项，不涉及不论什么放在注冊表文档扩展或组件类别的项。要时常手工保持这些项的同步。

最后，须要该注冊足迹激活不论什么 COM 类。这极大地复杂了公布分布式应用程序的过程，由于必须到每一个client的机器进行适当的注冊项。

如今还有一个共同问题是：对一个正在执行的应用程序进行更新是不现实的。这是 Web 应用程序最大的问题，Web 应用程序必须停止工作然后重新启动动以更新应用程序使用的 COM 类。

这些问题主要由从组件自己分离传来的组件描写叙述引起的。换句话说，应用程序不是自描写叙述的和独立的。

以上就对须要.NET框架解决的DLL Hell问题进行了简单的描写叙述。

***