简介：面向 .NET 开发者的反编译工具整合包，主体是已注册的 Reflector 7.4.1.179 绿色版，并把 FileDisassembler、FileGenerator 两款高使用率插件直接集成在同一目录，省去自行寻找、编译和拼装的麻烦。原生 Reflector 只能逐个方法浏览，遇到整包导出或批量反汇编时效率有限；这份整合版适合阅读第三方程序集、研究未开源控件的实现、做代码比对与学习的开发者。压缩包共 21 个文件，以 dll 插件及依赖库、exe 主程序与命令行工具、txt 与 rtf 授权说明文档、config 配置文件和调试符号为主，整体约 4.79MB，解压后按说明注册插件即可使用。其中 FileGenerator 能把 dll 内的源文件成批导出，除缺少注释、变量名有变化外与原实现差别不大，便于补注释后复用；命令行入口则适合批量处理。已有 395 人学习下载。

1. Reflector 7.4.1.179 绿色版落地：先看清运行时和插件目录这两道门槛

手里只剩一个编译好的 dll、源码早就没了，这种活我接过好几次，最后都是靠 Reflector 7.4.1.179 绿色版把整个程序集还原成能编译的工程。真正干活的不只是主程序，而是集成进去的 FileDisassembler 和 FileGenerator 两个插件：前者把 dll 导出成 sln + csproj，后者把改完的源码再打回 dll。这套东西看着解压即用，实际卡人的地方只有两处——它依赖 .NET Framework 3.5 运行时，Win10/11 默认不带；插件必须落在正确的 Plugins 目录且版本对得上，否则右键菜单里那一项就是不出现，连报错都不给。下面按我实际装机的顺序走一遍，从解压位置一路讲到编译验证。

2. 环境准备：.NET Framework 3.5 与解压目录的取舍

装这类绿色版最容易犯的错，是把它当成“双击 exe 就行”的软件。Reflector 7.4.1.179 的主程序本身是托管代码编译出来的，进程跑起来第一件事就是找 .NET Framework 运行时；找不到就静默退出，任务管理器里连进程都留不下。第二件事是启动时扫描插件目录，扫描规则和版本校验都在主程序里写死了，你放错位置或者版本差一代，它不会弹窗告诉你，只会在菜单里少两项。所以环境这步必须先把运行时和目录定下来，再谈插件。

2.1 先确认运行时：Win10/11 上必装的 NetFx3

Reflector 7.x 这一代是按 .NET Framework 3.5 的基线构建的，机器上只装了 4.x 不够用。Win7 SP1 自带 3.5.1，解压就能跑；Win10、Win11 和 Server 2016 以后的系统默认只带 4.x，3.5 变成了一个需要手动启用的可选功能。对照关系大概是这样：

启用命令用管理员权限的 CMD 执行，在线环境直接走更新源：

:: 启用 .NET Framework 3.5，/NoRestart 避免立刻重启打断后续操作 DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /NoRestart :: 查状态，State 显示 Enabled 才算真的装好 DISM /Online /Get-FeatureInfo /FeatureName:NetFx3

/All会把父功能一起启用，/NoRestart只是压着不重启，功能本身照样生效。没有外网或者组策略把更新源掐了的时候，DISM 会卡在 0.0% 然后报 0x800f0954，这时候挂载系统安装镜像，把 sxs 目录指过去：

:: 离线源，E: 换成你挂载的镜像盘符 DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:E:\sources\sxs

/LimitAccess的作用是禁止 DISM 去连更新源，只认/Source指定的本地目录，这一步能省掉很多“等半天然后失败”的时间。习惯用 PowerShell 的话等价命令是Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -NoRestart，效果一样。判断有没有装成功的标准不看命令回显的“操作成功”，看第二次查询时 State 那一行；我见过回显成功但实际只装了一半的情况，多查一次不费事。

2.2 解压位置与目录规划：别放进 Program Files

绿色版的好处是所有东西都在一个目录里，拷走就能用，但目录选错会带来一堆莫名其妙的权限问题。三条硬规矩：不放C:\Program Files及其子目录，UAC 会拦写配置的动作；路径里不要有中文和空格，FileDisassembler 导出的 csproj 里会把路径原样写进 HintPath，带空格的路径在部分 MSBuild 版本下要额外转义；不放 OneDrive 之类的同步目录，反编译过程中会频繁读写临时文件，同步客户端锁定文件导致的导出中断排查起来很折磨人。

我一般按这个结构铺：

D:\DevTools\Reflector-7.4.1.179\ ├── Reflector.exe ├── Plugins\ │ ├── FileDisassembler.dll │ └── FileGenerator.dll ├── Output\ # FileDisassembler 的默认导出位置 └── Backup\ # 改配置前把整个目录打包一份

Output单独建的意义在于，导出产物和程序目录混在一起时，第二次导出会覆盖第一次，中间的差异就找不回来了。Backup是后悔药，绿色版所有状态基本都在目录内，出问题直接整个目录覆盖回去，比逐项回滚配置快得多。另外注意路径总长度，Windows 默认 260 字符的上限在深层命名空间导出时是真的会撞上的，Output尽量放在盘符靠前的位置。

2.3 首次启动：拦截图、杀软与初始设置

从压缩包里解出来的 exe 和 dll 默认带“来自其他计算机”的标记，Windows 会因此加载失败但表面上看不出异常，尤其是插件 dll，被标记锁住之后主程序照样启动，只是插件不加载。解压完先跑一遍：

# 解除下载标记（Zone.Identifier），插件 dll 尤其要处理 Get-ChildItem -Path .\Plugins\*.dll -ErrorAction SilentlyContinue | Unblock-File Get-Item .\Reflector.exe | Unblock-File

反编译类工具被启发式引擎误判是常事，首次启动前把整个目录加进杀软的排除列表，比启动到一半被拦下来再回头找原因省事。首次运行可能遇到 SmartScreen 的蓝色拦截框，点“更多信息”再点“仍要运行”即可，这一步过后不会再问。主程序起来之后先别急着拖 dll 进去，把窗口布局和默认展开层级调一下，这些设置绿色版大多写在程序目录里，换机器拷目录就能带走。

提示：如果发现换了机器之后窗口尺寸、最近打开列表没跟着走，说明部分 UI 状态落在用户配置单元里，用reg query HKCU\Software /f "Reflector" /s /k能搜出相关键，导出成 reg 文件一起备份即可。

3. 插件挂载：FileDisassembler 与 FileGenerator 怎么才算真集成

“集成了两大插件”这句话的实际含义，是两个 dll 已经在 Plugins 目录里躺着了。但躺着不等于被加载，这里是最容易产生误会的地方：主程序启动时会扫描目录、读取每个 dll 声明的宿主版本号，对不上就跳过，全程没有任何提示。所以装完之后必须自己确认菜单项出来了没有——右键程序集节点能看到导出源码的选项，才算 FileDisassembler 真的挂上了。

3.1 插件加载原理与 dll 落位

Reflector 的插件模型很朴素：启动时遍历Plugins子目录下的 dll，反射读取宿主程序集版本，匹配成功就注册它提供的菜单项和面板。这套机制不检查文件完整性，也不校验数字签名，所以半截下载的 dll 同样会被尝试加载，失败后静默丢弃。落位规则就一条：两个 dll 直接放在Plugins目录下，不要再套一层子目录，嵌套目录不会被递归扫描。

先确认文件本身是完整的：

# 列出插件目录里每个 dll 的版本号和大小，用来判断是否完整 Get-ChildItem .\Plugins -Filter *.dll | ForEach-Object { $v = (Get-Item $_.FullName).VersionInfo [PSCustomObject]@{ Name = $_.Name FileVersion = $v.FileVersion SizeKB = [math]::Round($_.Length / 1KB, 1) } } | Format-Table -AutoSize

FileVersion 应当和主程序的 7.4.1.x 属于同一代，差一个大版本基本可以放弃。SizeKB 是更直观的指标：正常插件是几十到一百多 KB 的量级，如果某个 dll 只有几 KB 甚至 0 字节，那是解压或下载环节断了，换一份重新放。顺序上两个插件的加载先后无所谓，但如果目录里还混着别的第三方插件，排查阶段先只留这两个，避免某个插件抛异常导致后面的注册流程整体中断。

加载成功的判定不看日志，看菜单：树里选中一个程序集根节点（图标是 dll 的那个，不是命名空间），右键菜单里应该出现导出源码的选项；选中源码文件或文件夹节点，右键应该出现生成程序集的选项。两个都在，说明挂载完成，可以进入下一步。

3.2 FileDisassembler 导出：参数怎么选

FileDisassembler 解决的是“Reflector 一次只能看一个类型”的问题，它把整个程序集按类型拆成独立文件，再拼出一个能直接打开的工程。操作路径是右键程序集节点，选导出源码，然后填一个对话框。这个对话框的参数看着不多，选错了返工成本很高：

导出过程是单线程的，大程序集会明显卡住，进度条不动不代表死了，看任务管理器的 CPU 占用更准。导出完成后第一件事不是打开 VS，而是数一下输出目录里的 csproj 数量——正常情况下和程序集里的项目数一致，通常是 1 个；如果目录里只有一堆 cs 却没有工程文件，那是“生成工程文件”没勾上，重导一次比手工拼 csproj 快得多。

注意：导出目录不要选在和上一次相同的路径，FileDisassembler 覆盖同名文件时不提示，改过的代码会直接没。

3.3 FileGenerator 反向生成：从源码打回程序集

FileGenerator 是反方向：把树里的源码节点编译成 dll。它的价值不只是“改完打回去”，更实用的是拿它验证导出的代码完不完整——如果导出的源码能原样编译过，说明 FileDisassembler 这一侧没有丢东西；编译不过的地方，正好是需要手工补的地方。

操作是选中源码文件夹节点，右键调用生成，然后在参数面板里指定目标框架、输出目录和引用。三条经验：输出目录不要和输入目录相同，否则生成的 dll 会盖掉你手上那份原始文件，而原始文件往往是唯一的对照样本；引用其它程序集时优先把依赖 dll 复制到输出目录同级，绝对路径在换机器后必断；生成失败时看错误列表里的 CS 编号，比看那句“生成失败”有用一百倍，CS0246 是找不到类型（缺引用），CS0103 是名字不存在（方法体没还原全），CS0117 是成员不匹配（版本对不上）。

这一步的常见结果是“能生成但有几十个警告”，警告大多来自未使用的变量和可空性提示，不影响验证；真正要盯的是错误数为 0。如果错误集中在少数几个类型上，先把这几个类型从工程里排除，让其余部分编译通过，再单独啃硬骨头，比一开始就全线死磕效率高。

4. 参数细调：目标框架、引用路径与编码

到这一步工程能打开了，但离“能编译、能维护”还差一层。导出的 csproj 是机器生成的，里面的目标框架版本、引用路径、程序集签名信息全是按导出时的上下文硬写进去的，换台机器或者换个 VS 版本就全红。这一章处理的就是这些默认值，改完之后工程才算真正可移植。

4.1 目标框架版本与语言语法

导出的工程默认目标框架跟原程序集一致，但 7.4 这一代对高版本框架的支持是有限的，需要按来源分情况处理：

第三行是最常见的认知落差。打开一个 4.5 的程序集，你以为会看到async Task Foo()，实际看到的是一个叫<Foo>d__0的类实现了状态机接口，方法体被拆成MoveNext()里的一堆 switch。这不是导出出错，是这一代工具链的能力边界。处理方式是切到 IL 视图对照着看，手工把状态机还原成 async 语法；类型不多的话值得做，类型成百上千就老老实实保留状态机原样，能编译通过优先于好看。

改目标框架版本直接在 csproj 里改<TargetFrameworkVersion>节点，改完记得在 VS 里重新加载工程，只改文件不重载是不生效的。语言版本低于框架要求时会报一片语法错误，那种情况不是代码坏了，是把 C# 6 以上的语法写进了 v4.0 的工程。

4.2 引用路径可移植化

FileDisassembler 写进 csproj 的 HintPath 是绝对路径，原机器上的D:\somewhere\lib\Foo.dll换台机器就是一片“找不到类型”。手工一个个改不现实，用脚本批量转成相对路径：

# 把 csproj 里的绝对引用路径统一替换成相对目录 param( [string]$ProjDir = "D:\DevTools\Reflector-7.4.1.179\Output", [string]$OldRoot = "D:\somewhere\lib", # 导出时记录的原引用根目录 [string]$NewRoot = "..\libs" # 工程内的相对位置 ) Get-ChildItem -Path $ProjDir -Recurse -Filter *.csproj | ForEach-Object { $file = $_.FullName $xml = Get-Content $file -Raw # 只替换引用根目录，保留后面的文件名和子目录结构 $xml = $xml.Replace($OldRoot, $NewRoot) Set-Content -Path $file -Value $xml -Encoding UTF8 Write-Host "已处理 $($_.Name)" }

脚本的核心就是字符串替换，$OldRoot必须和导出时 csproj 里实际写的路径完全一致，差一个反斜杠都替换不到，处理前先Select-String抽查一条 HintPath 确认格式。替换完成后把依赖 dll 统一放到工程目录下的libs文件夹，相对路径..\libs\Foo.dll就从工程文件所在目录算起，整包拷走也不会断。

还有一种更省事的做法：如果依赖的 dll 本身在全局程序集缓存里，直接把 HintPath 整行删掉，让 MSBuild 从缓存解析。缺点是换机器如果没装对应的运行时就会失败，适合依赖是标准库的场景，业务库还是老实放libs目录。

4.3 强名称、编码与换行

强名称程序集导出的AssemblyInfo.cs里通常带着[assembly: AssemblyKeyFile("..\\..\\key.snk")]这样的特性，而那个 snk 你根本没有，编译直接失败。三种处理：注释掉这行特性，改成不签名的普通程序集，适合只做本地调试；用sn -k new.snk自己生成一对密钥重新签，适合需要保持强名称引用的场景；本机调试图省事的话用sn -Vr *,*跳过验证，但这条只对当前机器有效，别写进任何构建脚本。

编码问题更隐蔽。导出的 cs 文件编码不一定统一，中文注释和环境里原有的字符串常量会出现乱码，VS 打开一片问号。统一转成带 BOM 的 UTF-8 最稳：

# 递归把导出目录里的 cs 文件统一成 UTF-8 with BOM + CRLF Get-ChildItem -Path .\Output -Recurse -Filter *.cs | ForEach-Object { $text = Get-Content $_.FullName -Raw -Encoding UTF8 $text = $text -replace "`r?`n", "`r`n" # 统一换行 [IO.File]::WriteAllText($_.FullName, $text, (New-Object Text.UTF8Encoding $true)) }

UTF8Encoding $true那个布尔参数就是“写 BOM”，少了它 VS 可能按本地代码页猜编码，中文继续乱。换行统一成 CRLF 是因为部分老编译器对单独的 LF 会报 CS1010 换行符错误，看着莫名其妙，其实是文件格式问题。这两步做完再打开工程，会少掉一大半与代码逻辑无关的红线。

5. 常见问题排查：五类翻车现场与处置

这一节按我实际遇到的频率排序，每条都按“现象—原因—解决”写，遇到对不上的情况优先往第一条上靠，因为它占了差不多一半。

现象一：双击 exe 完全没反应，任务管理器里也看不到进程。原因几乎都是缺 .NET Framework 3.5，主程序在 CLR 加载阶段就退出了，连错误框都来不及弹。解决是先按 2.1 节查 NetFx3 状态，State 不是 Enabled 就先启用。少数情况是杀软直接把进程掐了，看杀软的拦截日志能确认，把目录加排除后重试。

现象二：Plugins 目录里两个 dll 明明在，右键菜单就是没有导出源码那一项。原因有两个：dll 被“来自其他计算机”标记锁住，或者插件版本和 7.4.1 主程序不匹配被静默跳过。解决是先用Unblock-File解除标记，重启主程序；还是不行就换一份与 7.4.x 同代的插件，版本差一代的 dll 放进去不会报错，只会安静地不工作。

现象三：导出成功，但 VS 打开后几百个类型全部报“找不到类型或命名空间”。原因是 HintPath 里的绝对路径在本机不存在，或者目标框架版本低于源码语法要求。解决是先跑 4.2 的替换脚本把引用路径改成相对路径，再把 csproj 的TargetFrameworkVersion调到与原程序集一致，两步做完错误数通常会掉到个位数。

现象四：能展开类型，但方法体是空的或者只有一句抛异常。原因是被反编译的程序集是 4.5 以上版本，或者它依赖的 dll 没在同一目录导致类型解析不全。解决是把所有依赖 dll 复制到目标程序集同级目录重新加载，切 IL 视图确认方法体是否真的存在——IL 里有内容而 C# 视图里没有，那就是还原能力的问题，不是文件损坏。

现象五：FileGenerator 生成时提示“未能加载文件或程序集”。原因是它在编译时需要的引用没找到，或者输出目录里有同名文件被占用。解决是把依赖 dll 放到输出目录同级，关掉还开着这个 dll 的进程（包括上一次没退干净的 Reflector 实例），再重试。生成失败后不要反复点，先看错误列表里的第一行，后面往往都是第一行引发的连锁。

提示：排查阶段养成一个习惯，每次改动前把整个 Reflector 目录复制一份到Backup，出问题直接换目录启动，比回滚单个配置快。

6. 装完怎么验证：用一个小程序集跑完导出到回写的闭环

真正能说明这套环境装好了的，不是菜单项出现了，而是你能拿一个自己写的 dll 完整走一遍“反编译导出 → 编译通过 → 反向生成 → 重新加载”的闭环。这一步我每次都做，材料自己造，不碰任何真实项目。

先写一个最小的类库当靶子，里面故意放一个泛型方法、一个迭代器和一个资源引用，这三样是导出最容易出问题的点：

:: 用 4.0 的编译器编一个最小类库，注意路径换成你自己的 "C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe" ^ /target:library /out:Demo.Lib.dll .\src\Calculator.cs

编出 dll 之后拖进 Reflector，右键程序集节点导出源码到Output\Verify\，然后在 VS 里打开生成的工程直接编译。判定标准只有一条：错误数为 0。警告可以有，错误一个都不能留，因为错误说明导出或配置环节确实丢了东西。

第二步是把编译产物和自己写的那份 dll 做 IL 层面对比：

:: 分别 dump 出 IL 文本，注意 /text 才会输出可读文本 ildasm /text /out:before.il Demo.Lib.dll ildasm /text /out:after.il Rebuilt.Lib.dll :: 逐行对比，第一次跑必然会有一堆差异 fc /b before.il after.il

第一次 diff 出来的差异不要慌，模块版本号（MVID）和编译时间戳每次生成都不一样，这两块差异是正常的。真正要盯的是方法体那几段：如果 IL 指令序列在方法级别一致，说明导出—编译这条链路是通的；如果某个方法在after.il里指令明显变少，回到源码看那个方法，八成是迭代器或泛型被还原成了简化版。

第三步用 FileGenerator 把改过的源码反打回 dll，再拖回 Reflector 里加载，比较类型数量和成员数量是否与原始一致。三步都过，说明 FileDisassembler 的导出方向、FileGenerator 的生成方向、运行时和目录配置全部到位，可以拿去处理真正的程序集了。

从那以后我每次装完这套东西，都强迫自己先拿一个自造的小 dll 走完整个闭环，确认两个插件都活着，再去碰真项目——被静默不加载的插件坑过一次之后，这个习惯就再没改过。希望帮到你。

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