简介：这份资源是 .NET 平台经典反编译工具 Reflector 的 7.4.1.179 绿色注册版，面向需要阅读第三方程序集源码、分析组件实现或做兼容性排查的 .NET 开发者。与常见的单文件版本不同，包内已整合 FileDisassembler 与 FileGenerator 两款口碑插件：前者可按类型批量反编译整个程序集，后者能把 DLL 中的源文件成批导出，便于研究非开源控件的实现思路并在其基础上改写复用。压缩包共 21 个文件、约 4.79MB，主体由 6 个 dll（主程序、插件及日志等依赖）、3 个 exe（含命令行版本与开发路径设置工具）、4 个 txt 与 3 个 rtf（授权说明与使用文档），以及 config、cfg、pdb、htm、nfo 等配置与说明文件组成，解压后配置好插件加载项即可使用。目前已有 395 人学习，适合希望一次性获得可注册主程序与插件协同环境的读者，省去自行搜寻插件 DLL、反复调试加载配置的时间。

1. 没有源码的三百个 dll：为什么我最后留下的还是 Reflector 7.4

某次接手一个交接过几轮的老系统，交付物只有一个 bin 目录，三百多个 dll，零文档，上一任留下的唯一线索是“源码在某台已经报废的机器上”。我先用开源反编译器逐个点开看，能读，但把类型一个个另存为 .cs 再手工拼回工程，两天推进不到十分之一。后来换成 Reflector 7.4.1.179 这个绿色注册版，FileDisassembler 和 FileGenerator 两个插件都已经装好并验证能联动，整包导出加依赖补齐，一个下午把主干跑通。

这篇讲三件事：.NET 反编译器该按什么维度比、这两个插件到底补上了哪一环、绿色版在真实机器上会出哪些问题。手上有一堆没有源码的程序集，或者正纠结换哪个工具，下面的判断依据可以直接参考。

2. 反编译器怎么比：五个维度决定你能不能把活干完

大多数工具评测停在“反编译出来能不能看懂”，这个标准太低了。看懂只是第一步，真正的活是把它变回一个能编译、能改、能重新跑起来的工程。我一般按五个维度打分，权重从高到低排下来，基本能覆盖九成场景。

2.1 反编译精度：看不出状态机痕迹的才算合格

判断精度别拿 Hello World 试，那玩意儿谁都能还原得漂亮。要看编译器帮你生成的那些东西：async 方法、yield 迭代器、lambda 闭包、泛型约束、模式匹配、匿名类型。

老版本反编译器最典型的短板就在这里。Reflector 7.4 编译年代偏早，遇到 async 方法会老老实实还原成<RunAsync>d__3这样的状态机类，MoveNext()里一堆switch加awaiter，语义没错，但读起来像天书，改起来更痛苦。新版 ILSpy 在这一块做了语法糖重建，能还原回async/await的形态。这不是谁强谁弱的问题，是工具的设计目标不同：一个追求结构还原的准确性，一个追求源码形态的可读性。

我的判断标准很土：拿一段自己写的、同时含泛型约束和 async 的代码编译出来，再反编译回去，看能不能一眼认出原样。认得出，精度够用；认不出但逻辑对，也算合格，只是改起来要多花时间。

2.2 工程级导出：单文件另存和整包还原是两个工作量

这是最容易被忽略的维度。单类型另存为 .cs 只解决“读”，工程级导出才解决“改”。一个能用的工程级导出至少要满足四条：生成可打开的工程文件、按命名空间保留目录层级、资源文件（.resx、图片、字符串表）跟着走、程序集引用关系写进工程里。

Reflector 原生只做单文件导出，这是它被诟病最多的地方，也是 FileDisassembler 和 FileGenerator 存在的理由。前者负责把整个程序集拆成源码树，后者负责把散落的 .cs 补成能打开的工程。两个插件分开设计是有道理的：你有时候只想拆不想建工程，有时候拆完了想换个 IDE 再建。

对比来看，ILSpy 自带“另存为项目”，dnSpy 也能导出工程，dotPeek 有 Export to Project。所以这个维度上 Reflector 靠插件追平，不是原生优势。但插件的好处是可脚本化，这个下面单独说。

2.3 批处理能力：三百个 dll 不可能靠右键

程序集数量一上来，图形界面的效率就崩了。三百个 dll，每个点五次菜单，就是一千五百次点击，中途还会因为某个 dll 卡住而中断。

所以我会重点看工具有没有可调用的命令行入口、有没有可编排的导出流程、失败时会不会留下可读的日志。Reflector 本身支持命令行加载，配合插件能做批量导出；ILSpy 有ilspycmd这样的命令行工具；dnSpy 更偏交互，批处理不是它的强项。

这条维度上，能不能写脚本决定了你是干一天还是干一周。后面第 4 章会给出一个可直接套用的 PowerShell 批处理骨架。

2.4 部署成本：免安装这一点在受限机器上是刚需

绿色版的价值不在“省了安装步骤”，在于它能在一个你没法装软件的机器上跑起来。客户现场的内网机、只给你一个远程桌面账户的跳板机、连管理员权限都申请不下来的开发机，这些环境下安装包形态的工具直接出局。

Reflector 7.4 是 .NET Framework 时代的 Windows 程序，解压即用，不写全局 GAC，不和其他版本打架，可以放 U 盘里带着走。代价是它依赖 .NET Framework 4.x 运行时，精简系统或者长期没打过补丁的机器上会缺组件，这个在第 5 章会展开。

顺带说一句，dnSpy 的上游项目早已停更，社区有分支在接着维护；ILSpy 有跨平台版本，Linux 和 macOS 上也能跑。如果你的机器不是 Windows，选型范围会立刻缩小。

2.5 混淆与强名称：工具的边界要提前划清

反编译器不是脱壳机，这句话要写在脑门上。经过名称混淆的程序集，还原出来就是一堆a.b.c；控制流平坦化过的，还原出来是一坨switch套switch；字符串加密过的，字面量全是乱码。这些不是换个工具能解决的，得上专门的脱壳和反混淆手段。

强名称是另一个坑。签名过的程序集导出后重新编译，签名校验一定失败，要么跳过验证，要么延迟签名再补。工具能帮你把源码还原出来，但还原不了签名私钥，这一点在动手前就要有预期，不然做到一半发现编译不过，会很被动。

3. 四款工具摆一起：Reflector、ILSpy、dnSpy、dotPeek 逐项拆

工具选型最怕“都行”，所以这一章我把四款摆在同一个基准上比。需要说明的是，这里比的是能力边界，不是版本号新旧，具体小版本的差异以你手上的实际版本为准。

3.1 一张表先看硬指标

这张表里最值得盯的是“原生工程导出”和“整包批量导出”这两行的组合。单独看，Reflector 在工程导出上是短板；但配上插件之后，它在批量场景下的表现反而是四款里最顺手的，因为拆和建被拆成了两步，每一步都能单独重跑。

3.2 拿同一段代码做基准：可读性差在哪

我习惯用同一段样本做基准，样本要同时踩到泛型约束、async、yield、闭包这几块：

// 基准样本：泛型约束 + async/await + yield + 闭包 public class Pipeline<T> where T : class, new() { private readonly List<Func<T, Task<T>>> _steps = new(); public Pipeline<T> Add(Func<T, Task<T>> step) { _steps.Add(step); // 闭包捕获 this return this; } public async Task<T> RunAsync(CancellationToken ct = default) { var current = new T(); foreach (var step in _steps) { ct.ThrowIfCancellationRequested(); current = await step(current).ConfigureAwait(false); } return current; } public IEnumerable<T> Repeat(int times) { for (var i = 0; i < times; i++) yield return new T(); // 迭代器状态机 } }

这段代码编译后会产生两个编译器生成的嵌套类型：<RunAsync>d__3和<Repeat>d__5。ILSpy 这一类新工具会尝试把它们重建回async方法和yield语句；Reflector 7.4 会把状态机原样摊开，MoveNext()里的switch (<>1__state)一目了然，逻辑是对的，但你要自己脑补回原来的写法。

所以可读性的差距集中在“语法糖重建”这一层，不在 IL 还原的准确性上。如果你只是要读懂逻辑，两者都够；如果你要把还原出来的代码当源码维护，重建能力强的工具省事得多。我的做法是：先看逻辑用谁都行，要落地成工程就用重建能力强的，或者接受状态机形态、在关键方法上手写注释。

3.3 导出产物对比：谁的工程更接近能 build

导出产物的差距比反编译结果的差距大得多。理想的产物应该长这样：一个 .sln，若干 .csproj，目录按命名空间分层，资源文件在对应位置，引用列表完整。

ILSpy 和 dotPeek 的原生导出偏向生成工程文件，产物结构规整，但工程文件格式跟工具的实现绑定，有时候是老式 csproj，需要手工换成 SDK 风格。dnSpy 的导出偏“能看”，工程完整度一般。

Reflector 加 FileDisassembler 的产物是纯源码树，一个类型一个 .cs，资源单独放；FileGenerator 再补上工程文件和引用。这种“拆”和“建”分离的设计有个实际好处：你可以只导源码不建工程，把源码丢进自己已有的解决方案里；也可以先建工程再按需删改，比一体化导出灵活。

代价是两步之间有依赖，第一步的产物质量直接决定第二步能不能成。如果 FileDisassembler 拆的时候因为路径过长中断了，FileGenerator 建出来的工程就是缺文件的，编译一堆红。这个坑第 5 章细说。

3.4 三条选型结论，照着选不会错

第一，只想快速看一个方法、一个类型的实现，选 ILSpy 或 dnSpy，启动快、语法糖重建好、搜索方便，这是日常使用频率最高的场景。

第二，要动态调试、下断点、改 IL 再回写，只有 dnSpy 这个方向可选，别的工具不提供这层能力。

第三，要把一整批程序集还原成可编译、可维护的工程，Reflector 加 FileDisassembler 和 FileGenerator 这个组合最省事，因为它能把重复劳动脚本化。这也是我为什么在一个老版本上留了这么久的原因——不是因为版本号，是因为整套流程已经磨顺了。

4. 两个插件才是重点：FileDisassembler 与 FileGenerator 怎么配合用

标题里“真正集成了两大插件”这几个字，多数人一眼扫过去就跳过了，实际上这才是这个包和网上随便下的裸版最大的区别。裸版 Reflector 只能一个类型一个类型地看，装了插件之后它才具备工程级还原的能力。

4.1 FileDisassembler：按命名空间把程序集摊成源码树

它的工作方式很直接：加载一个程序集，遍历里面所有类型，按命名空间建目录，每个类型写一个 .cs 文件，资源文件单独落盘。产物是一棵干净的源码树，没有工程文件，没有引用声明。

这层设计的好处是可控。你可以只导某个命名空间下的类型，可以先导一部分验证效果再全量导，也可以把多个程序集的源码导到同一个目录里合并。副作用是命名冲突要自己处理：两个程序集里有同名同命名空间的类型时，后导的会覆盖先导的，这个得在导出前规划好输出目录。

导出粒度上我一般按“一个 dll 一个目录”来切，目录名用程序集名，这样后面建工程的时候能一一对应，出问题也好定位是哪个包拆坏了。

4.2 FileGenerator：把散落的 .cs 补成能打开的工程

源码树有了，但一堆 .cs 文件不构成工程，没有 csproj 就打不开、编译不了。FileGenerator 干的就是这件事：扫描目录里的源码，按目录结构生成工程文件，把引用关系写进去。

产物大体是这个形态，注意这是老式工程格式，具体内容以你实际生成的结果为准：

<!-- FileGenerator 产物的大致形态：老式 csproj，需按目标框架调整 --> <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <OutputType>Library</OutputType> <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion> <!-- 导出产物默认不签名，还原签名程序集时必须关掉 --> <SignAssembly>false</SignAssembly> </PropertyGroup> <ItemGroup> <!-- 引用列表：缺一个就编译不过，需要人工补齐 --> <Reference Include="System" /> <Reference Include="System.Core" /> </ItemGroup> <ItemGroup> <!-- 源码清单：由扫描目录生成 --> <Compile Include="Order\OrderService.cs" /> </ItemGroup> </Project>

这里有两个参数要盯住。TargetFrameworkVersion决定编译基线，导出时如果不知道原程序集的目标框架，先随便填一个能过的，编译报错再往上调。SignAssembly一定要保持false，强名称程序集导出后没有私钥，开了签名必然失败。

4.3 批处理脚本：一次跑完整个 bin 目录

图形界面点三百次不现实，我一般用 PowerShell 做调度。下面这段只做三件事：遍历、调用、记日志，工具的具体参数以你手上版本的帮助输出为准，不同小版本可能有出入：

# 批量调度：遍历 bin 目录，逐个调用反编译器导出，失败写日志继续跑 $tool = "C:\Tools\Reflector\Reflector.exe" # 换成你的实际路径 $src = "D:\legacy\bin" $out = "D:\legacy\src" $log = "D:\legacy\export.log" Get-ChildItem -Path $src -Filter *.dll -Recurse | ForEach-Object { $target = Join-Path $out $_.BaseName New-Item -ItemType Directory -Path $target -Force | Out-Null # 先跑一次帮助确认参数名，避免全部失败还找不到原因 & $tool $_.FullName /project:$target 2>&1 | Out-File -Append $log if ($LASTEXITCODE -ne 0) { # 失败的单独记一行，方便回头补跑 "FAIL`t$($_.FullName)" | Out-File -Append $log } }

调度逻辑之外，还有一段我每次都会先跑的检查：在进反编译器之前，先判断这个文件到底是不是托管程序集，以及它带不带强名称。这一步能省掉大量无效等待——目录里混着原生 dll 是常事，反编译器打开它们只会报错。

# 预检：过滤出托管程序集，顺带看强名称标识 Get-ChildItem D:\legacy\bin -Filter *.dll -Recurse | ForEach-Object { try { $an = [System.Reflection.AssemblyName]::GetAssemblyName($_.FullName) [PSCustomObject]@{ File = $_.Name Name = $an.Name Version = $an.Version # 有 token 说明是强名称程序集，导出后重新编译要关签名 Token = ($an.GetPublicKeyToken() | ForEach-Object { $_.ToString("x2") }) -join "" } } catch { Write-Warning "$($_.Name) 不是托管程序集，跳过" } }

GetAssemblyName这个调用只读 PE 元数据，不加载程序集本身，所以不会因为依赖缺失而失败，很适合做前置过滤。Token为空说明没签名，重新编译时不用管签名的事；有值就要在第 4.2 节的工程里把SignAssembly关掉。

4.4 怎么确认插件真的生效了

这一步别跳过。装没装插件，看菜单最直接：Reflector 里选中一个程序集，右键菜单里出现导出为源码目录、导出为工程这类条目，说明 FileDisassembler 和 FileGenerator 被加载了；只有“导出为单个文件”，说明插件没起来。

第二个验证点是产物。真正生效时，导出的目录里会有多个 .cs 文件按命名空间分层，而不是一个合并的大文件。如果导出结果是几十个类型挤在一个文件里，那用的是原生单文件导出，插件没参与。

第三个验证点是日志。批处理跑完，统计一下目录数量和 dll 数量对不对得上，对不上就是中途有失败。我一般会把失败清单单独存一份，补跑的时候只跑这些，不用全量重来一遍。

5. 绿色版翻车现场：六种跑不起来的排查清单

绿色版省了安装，代价是所有运行环境问题都得自己扛。下面这几条是我在不下十台机器上踩过的，按“现象 → 原因 → 解决”写，照着对号入座。

5.1 双击一闪而过，进程里找不到

现象：双击主程序，鼠标转一下就没反应，任务管理器里连进程都不留。

原因通常是三个之一：一是机器上没装 .NET Framework 4.x 运行时，程序启动瞬间就崩了，来不及报错；二是文件是从别处拷过来的，被系统打了“来自网络”的标记，安全策略直接拦掉；三是解压路径里有中文或者空格，老程序对路径的处理不严谨。

解决：先在命令行里跑一次，让它把异常打出来，别双击；然后右键看文件属性底部有没有“解除锁定”勾选框，有就勾上；最后把整个目录挪到纯英文无空格路径下，比如C:\Tools\Reflector。

5.2 打开就报 could not load file or assembly

现象：程序本身起来了，一加载目标 dll 就弹异常，提示找不到某个程序集。

原因很直接：目标 dll 的依赖没放齐。反编译器要解析类型引用，引用链上任何一环缺失都会导致解析失败，哪怕你只想看其中一个小类。

解决：把目标 debug 目录里的所有 dll 一起拷到同一个文件夹，让反编译器从这个文件夹里解析依赖；如果工具支持设置程序集搜索路径，把输出目录加进去。实在找不齐依赖，就接受部分类型解析失败，先看能看的那部分，别在依赖缺失上死磕。

5.3 导出到一半停了，目录里全是半截文件

现象：批量导出跑了几十个程序集后卡住，后面的目录要么是空的，要么只有零星几个 .cs。

原因最常见的是路径过长。Windows 默认路径上限 260 字符，导出时会拼出“输出目录 + 命名空间层级 + 类名 + .cs”，嵌套深的库很容易超限。其次是文件名非法字符，泛型类型反编译出来的名字里带反引号和尖括号，写文件时会被系统拒绝。

解决：输出目录尽量短，比如D:\out这种；分批次导出，先导核心包，验证通过再导剩下的；跑完之后拿目录数量和 dll 数量对一遍，差多少心里有数，补跑的时候只跑差额。

5.4 导出的工程一编译几百个红

现象：目录结构和文件都在，打开工程按下生成，几百个错误刷屏。

原因分几类：引用没写全，缺 System 之外的第三方依赖；目标框架版本填错，用低版本框架去编高版本语法；资源文件没关联到工程里，代码里Resources.XXX找不到；原代码用了dynamic、指针、匿名类型这些反编译本身就还原不好的东西。

解决：先修引用和目标框架，这两类占错误的绝大多数，改完再编一次，看剩余错误量级；剩余错误集中看是不是资源文件和语法糖问题，能手工补的补，补不了的用#if false圈起来先让工程能过，后面再逐个处理。别指望一次编译零错误，那不现实。

5.5 插件菜单里根本没有 FileDisassembler / FileGenerator

现象：程序能跑，也能反编译，但右键菜单里只有单文件导出。

原因通常是插件版本和主程序版本对不上，插件是按特定主程序版本编译的，差一个小版本就加载失败；或者插件 dll 被系统标记为“来自网络”没解除锁定；也可能是 dll 放错目录，插件目录和主程序目录不是同一个。

解决：确认插件 dll 和主程序在同一套目录结构里，按插件说明放；右键插件 dll 解除锁定；版本对不上就换匹配的组合，别硬凑。装完重启程序，看菜单有没有新增条目，没有就继续查，别在不生效的插件上白跑一遍批量脚本。

提示：这些程序集如果要用于商业交付，反编译产物的使用边界按原授权条款走；工具本身在商业场景下也建议走正规渠道获取授权，技术验证和商业使用是两件事。

6. 我的固定动作：拿到陌生程序集先做这四步

踩过的坑多了以后，流程就固化了。现在不管拿到什么程序集，我都按下面四步走，顺序不换，能省掉大量返工。

这四步里最容易被跳过的是第 3 步。我一开始也图快，直接全量跑，结果插件没生效，三百个 dll 全是单文件导出，做完才发现，白等两个小时。从那以后我每次跑批之前，都强制先导一个最小的 dll，打开产物看一眼目录结构，确认是分层源码树而不是合并文件，再放开跑全量。

还有一个习惯：导出目录永远不复用。每次跑批开一个新目录，旧的留着不删，出问题能对比两次产物的差异，比凭空猜快得多。磁盘不够就压缩归档，别在原目录上覆盖，覆盖过一次之后就再也说不清哪个文件是哪次导出的了。

工具这块我的结论很简单：日常看代码用新工具，整包还原工程用 Reflector 加这两个插件。不是因为老版本更好，是因为这套组合的每一步都能脚本化、能重跑、能对比，出了岔子知道去哪儿找。希望帮到你。

本文还有配套的精品资源，点击获取