简介RevitLookup 2020 是一款面向 Revit 二次开发者的表格查找工具可在调试插件时直观查看项目数据库、元素属性及各类几何信息。资源包共 161 个文件压缩后约 1.05MB既提供可直接加载的 RevitLookup.addin 与 RevitLookup.dll也保留完整的 Visual Studio 源码工程文件类型以 78 个 C# 源文件、17 个位图资源、13 个 RESX 资源文件为主并含 sln、csproj 工程文件以及 PDB 调试符号、ICO 图标等目录结构清晰便于定位核心代码与配置。将 addin 和 dll 复制到 Revit 的 Addins 目录即可在 Revit 2020 中使用若环境或引用路径异常可打开源码重新编译并据此调整版本与引用深入理解插件加载机制。同时通过源码还能自定义查询项、扩展界面功能适配个人开发习惯。自发布以来已有 1654 人学习下载适合 Revit 二次开发入门及中高级开发者作为查看数据库、排查元素信息和编写插件时的参考工具。1. 一切 API 都是黑匣子先用 Lookup 把它拆开看一眼写过 Revit 插件的人多半经历过这种时刻某个属性文档上写得很含糊你设了断点也只看得到对象类型名想看它内部到底挂了什么数据只能一条条猜。RevitLookup 2020 解决的就是这件事——它把 Revit 模型里的任意元素、参数、几何对象全部用反射方式展开成一棵可逐层下钻的对象树相当于给 API 黑匣子开了一扇观察窗。拿到这个含源码和 addin 的包你能直接编译出一个带外部工具按钮的插件在 Revit 2020 里点选任意墙体、族实例或视图就能看到它下面挂了几十个属性、参数和几何节点。适合所有做 Revit 二次开发、BIM 工具集成的人尤其是那些被 API 文档坑过、想知道对象真实结构的开发者。2. 三个启动入口Pick / Db / App 模式下能看到什么RevitLookup 的定位是一个“运行时对象浏览器”但它的入口设计比普通调试工具更讲究。插件加载后你会看到三个外部工具命令Snoop Current Selection、Snoop Db、Snoop Application。三个命令分别对应三个粒度当前选中对象、当前模型数据库、Revit 应用上下文。第一次接触时别急着全点理解它们的区别能省下不少瞎翻的时间。2.1 Snoop Current Selection最小闭环的调试姿势这是最常用也最不容易出错的入口。选一个元素点 Snoop Current Selection插件会弹出一个树视图窗口根节点就是当前选中元素本身。你会看到 Element 级别的 Id、UniqueId、Category、Level、Parameters、Geometry 等节点每一个都可以继续展开。举个例子我想查一面墙的 LocationCurve 是用哪两个点定位的。选中墙运行 Snoop展开 Location 节点能看到 LocationCurve 和 LocationPoint 两个子节点。点进 LocationCurve里面就是 Curve 的 StartPoint 和 EndPoint再往下是 XYZ 的 X、Y、Z 坐标值。整个过程不需要写一行测试代码。这个入口适合“验证 API 行为是否符合文档描述”的场景。文档里写某个属性返回 Element但实际返回的是 Wall 还是 WallType展开节点看类型名一眼就知道。常见做法是把树窗口和 Visual Studio 的调试器一起用——在插件代码里打上断点再用 Lookup 对照对象结构定位错误参数的速度能快一倍。2.2 Snoop Db全模型按类检索Snoop Db 打开的是模型数据库视角根节点是 Document下面直接挂着所有类别的元素列表。这个入口在模型很大的时候加载会比较慢因为它要把整个类别树构建出来。实际使用我一般会配合“按类别过滤”的思维先展开 Walls 类别再找目标墙体而不是从头到尾翻。Db 模式最大的价值在于能看到模型里“有什么”而不是“选中了什么”。比如你想知道当前模型里到底有没有用某种共享参数展开 ProjectInformation 节点或者遍历所有 Element 的 Parameters 就能定位。它和当前选择模式的区别在于选择模式依赖 UI 选中态Db 模式不依赖任何选中操作适合批量检查数据的场景。打开这个窗口之后树节点上有个搜索框可以直接输入属性名或类型名过滤节点。Revit 的类别层级比较深手动展开很累这个搜索功能是高频使用点。2.3 Application 和 Document 层级低频但必要Snoop Application 展开的是 Application 对象往里能看到 Revit 版本信息、产品名称、参数选项等。这个入口在排查“为什么两台机器上行为不一致”时有用——直接对比两台机器的 Application 节点下的差异往往能找到版本导致的问题。严格来说还有一个 Snoop DB 输出内部细节的模式叫 Snoop Document它和 Snoop Db 的区别是前者直接展开 Document 对象属性后者按类别组织元素列表。两者底层都是同一个反射树逻辑只是起始节点不同。对多数人来说记住“选中元素用 Current Selection查全模型用 Db”就够了Application 和 Document 级节点用于极端场合。3. 核心源码拆解反射枚举对象图的 Lookup 机制这个工具能通用地展开任意对象关键不在于给每个类型写专门的解析器而在于一套统一的“可查看对象”抽象。源码的核心就是把 Element、Parameter、GeometryObject、反射属性和集合全部包装成同一种节点结构再交给树控件递归渲染。3.1 程序集结构与职责分层拿到源码后先看解决方案的项目结构主要分三层。最底层是 Snoopable 抽象定义所有可查看对象的行为中间层是各种类别的 Snoopable 实现负责把 Revit API 对象翻译成树节点最上层是 UI 窗体承载树视图、搜索框和节点懒加载逻辑。这样的分层带来的好处是新增一种可查看对象不需要改动 UI只需要新增一个 Snoopable 子类。如果你以后想二次开发支持第三方 API 返回的对象基本不需要动现有代码只需在核心逻辑里注册一个包装器UI 会自动识别。3.2 从 Element 到 Snoopable数据桥接Element 是整个 Revit 模型里最核心的基类RevitLookup 对它的处理也最重。它会同时解析三块数据内置参数集合、几何信息、反射属性。参数集合来自 Element.Parameters几何信息来自 Geometry 属性和 GetGeometryObjects 的调用反射属性则是用 .NET 的 PropertyInfo 逐个枚举。下面这段代码是 ElementSnoopable 的核心逻辑会被其他 Snoopable 复用public class ElementSnoopable : Snoopable { protected Element Element { get; } public ElementSnoopable(Element element) { Element element; } public override string Name ${Element.GetType().Name} ({Element.Id.IntegerValue}); public override IEnumerableSnoopable Children { get { // 优先枚举参数与几何因为这两块是 Revit 数据的核心 foreach (Parameter parameter in Element.Parameters) { yield return new ParameterSnoopable(parameter); } // 反射枚举属性放到后面避免个别 getter 抛异常阻塞主路径 foreach (PropertyInfo propertyInfo in Element.GetType().GetProperties()) { yield return new PropertySnoopable(Element, propertyInfo); } } } }参数的枚举直接由 Revit API 提供Geometry 部分需要单独分支处理。这里我把参数排在反射属性之前是因为实际排查问题时参数的可读性远高于反射属性。树节点的名字是类型名加元素 Id这样在大量节点里能快速定位到当前看的是哪个元素。反射属性节点是通用兜底方案它能把任何 net 对象的公开属性继续往下展开。这个设计看起来很“懒”但正是这种通用性让 Lookup 不需要针对每个 API 类型单独写代码public class PropertySnoopable : Snoopable { private readonly object _target; private readonly PropertyInfo _propertyInfo; public PropertySnoopable(object target, PropertyInfo propertyInfo) { _target target; _propertyInfo propertyInfo; } public override string Name _propertyInfo.Name; public override IEnumerableSnoopable Children { get { // 使用 try/catch 是因为某些属性的 getter 在非活动文档上下文中会炸 try { object value _propertyInfo.GetValue(_target); return WrapValue(value); } catch (Exception ex) { return new[] { new ErrorSnoopable(ex.Message) }; } } } private IEnumerableSnoopable WrapValue(object value) { if (value null) return Enumerable.EmptySnoopable(); // 集合类型递归展开每个元素普通对象直接包装成新节点 if (value is IEnumerable enumerable !(value is string)) { return enumerable.Castobject().Select(WrapSingle).Where(x x ! null); } return new[] { WrapSingle(value) }; } }参数说明部分GetValue 是反射的核心调用第二个参数传入绑定标志和 index 是为了处理带复杂签名和索引器的场景这里简化成单参调用实际源码里会同时处理 BindingFlags 匹配避免拿到隐式属性或受保护属性导致目标调用崩溃。ErrorSnoopable 是统一异常节点展开后只显示异常文本这样不会让整个树构建失败。3.3 递归展开与安全保障有个容易被忽略的实现细节树的子节点是懒展开的。也就是说Root 节点被创建时它并不会立刻枚举全部子节点而是在用户首次展开时才触发 Children 的枚举。这个设计对性能影响很大因为一个 Element 的反射属性可能有几十个而用户往往只需要看其中一两个。懒展开在实现上有一个常见坑如果某个属性 getter 导致异常Children 枚举过程中断树控件可能会直接崩溃。所以每个反射节点都必须在 try/catch 里包一层把异常转成可见的 ErrorSnoopable 而不是抛给 UI。这是我的实战经验原项目源码里也有类似处理逻辑自己改造时务必保留。另一个保障是循环引用检测。对象图里可能出现互相引用的对象比如 Element 的 Application 属性最终又引用回来。不做处理的话展开会产生无限递归。处理方式是维护一个“已访问对象哈希集”当发现当前节点指向同一个对象时只显示类型名而不继续展开避免死循环。4. 从源码到按钮Revit 2020 编译与 addin 加载拿到源码之后第一关是编译。Revit 2020 对应 .NET Framework 4.7.2解决方案文件的 TargetFramework 一般已经配好但如果你本机装了 Visual Studio 2022 并默认创建的是新式项目格式需要注意 SDK 版本兼容问题。我建议直接用 Visual Studio 2019 打开选中 Release 配置目标框架设为 .NET Framework 4.7.2平台选 AnyCPU。4.1 编译环境准备先确认你本地已经装了 Revit 2020。引用 RevitAPI.dll 和 RevitAPIUI.dll 时路径指向 Revit 安装目录下的公共程序集也就是 ProgramData 或安装目录的对应位置。引用时一定把 Copy Local 设为 False否则编译会把 Revit 的程序集复制到你插件目录里加载时版本冲突很难排查。编译出来的 RevitLookup.dll 会带有几个依赖文件但核心的插件入口就一个程序集。如果你编译时报“引用程序集不匹配”看看是不是本机装了 Revit 2021 且误引用了 2021 的 API。Lookup 2020 的源码必须严格引用 2020 版本的 API版本号对不上会导致 Revit 启动时加载失败。4.2 addin 清单文件写法Revit 加载外部工具靠的是 addin 清单文件它决定按钮出现在外部工具哪个类别下。下面是一个标准清单的写法?xml version1.0 encodingutf-8? RevitAddIns AddIn TypeCommand AssemblyD:\Dev\RevitLookup2020\src\bin\Release\RevitLookup.dll/Assembly FullClassNameRevitLookup.SnoopCurrentSelectionCommand/FullClassName ClientId12345678-aaaa-bbbb-cccc-123456789abc/ClientId VendorIdMyCompany/VendorId VendorDescriptionRevitLookup 2020/VendorDescription NameRevitLookup/Name /AddIn AddIn TypeCommand AssemblyD:\Dev\RevitLookup2020\src\bin\Release\RevitLookup.dll/Assembly FullClassNameRevitLookup.SnoopDbCommand/FullClassName ClientId12345678-aaaa-bbbb-cccc-123456789abd/ClientId VendorIdMyCompany/VendorId VendorDescriptionRevitLookup 2020/VendorDescription NameRevitLookup/Name /AddIn /RevitAddIns这个文件要放到 %APPDATA%\Autodesk\Revit\Addins\2020\ 目录下文件名建议是 RevitLookup.addinRevit 启动时会扫描该目录下所有 addin 文件。ClientId 每一行都要不同否则两个命令会互相覆盖Assembly 要指向你编译后 dll 的绝对路径用相对路径会出现“加载 addin 失败”的提示。FullClassName 必须和源码里 IExternalCommand 实现类完全一致包括命名空间。这个最容易翻车改过命名空间之后忘了同步清单点外部工具时会提示找不到命令。4.3 加载后的入口配置清单生效后重启 Revit 2020你会发现外部工具菜单下多了三个命令。Tool 面板不一定直接显示按钮它们默认放在“附加模块”选项卡下的“外部工具”下拉列表里。想让它们变成显式按钮可以右键 Ribbon 面板手动把命令拖到自定义面板上。我一般建议把 Snoop Current Selection 单独放到外部工具面板第一位因为它的使用频率最高。Snoop Db 和 Snoop Application 放到第二位平时很少点。如果团队里有多个开发人员addin 文件建议提交到版本库里内部统一使用一条路径编译输出避免本地路径不一致导致别人加载失败。5. 常见问题排查五个最容易翻车的地方这类工具源码不长但跑不通的概率不低。我把实际使用中撞过的坑按现象、原因、解决三个层次列出来按出现频率从高到低排。5.1 外部工具菜单里看不到命令现象addin 文件放好了Revit 也重启了但附加模块菜单下就是没有 RevitLookup 的入口。原因addin 文件格式不对或者 Assembly 路径指向不存在。最常见的是从网页复制时引号被转成了弯引号Revit 解析不了。解决用记事本或 Visual Studio 重新打开 addin 文件确认所有标签成对闭合引号是真英文引号。Assembly 路径先手动确认这个 dll 确实存在再确认 FullClassName 和源码类名一致。检查完以后删除 Revit 的 Temp 缓存目录再重启看是否恢复。5.2 编译报错找不到 RevitAPI.dll现象Visual Studio 编译时报错 CS0006提示找不到元数据文件 RevitAPI.dll。原因程序集引用路径写的是本机某个固定目录但实际 Revit 安装在别的盘或版本目录。解决修改引用的 SpecificVersion 为 False同时把 Copy Local 置 False。我一般会新建一个 Revit 引用目录把所有 API dll 统一放到一个固定位置解决方案里引用绝对路径。这样换机器时不需要改每台机器的路径只要把目录映射到相同盘符即可。5.3 展开几何节点时崩溃现象Snoop 一个体量族或复杂曲面时树窗口直接卡死或弹出未处理异常。原因GeometryObject 的某些属性 getter 依赖文档中的几何计算结果在扩展事务上下文中调用可能抛异常或者几何体量太大导致递归层级过深。解决把 GeometrySnoopable 的展开逻辑里加 try/catch捕获异常后显示错误节点。同时限制 Geometry 子节点的递归深度超过三层就停止展开只显示类型名。这样最坏情况是看到的基本结构不完整但不会崩掉 Revit。5.4 Snoop Db 加载非常慢现象模型一大会员多点 Snoop Db 后界面等待时间超过三十秒甚至无响应。原因Snoop Db 要枚举整个 Document 的类别树和每个类别下的全部元素模型元素上百万时反射操作量很大UI 线程同步构建导致假死。解决在 Snoop Db 的入口处加类别过滤先只构建类别节点元素列表延迟到节点首次展开时才枚举。另外Snoop 命令的 TransactionMode 一定要是 ReadOnly这样不会与 Revit 的文档事务产生锁竞争。5.5 Lookup 窗口打开后部分属性没有值现象树节点里某个属性显示为空但文档里说明该属性应该有值。原因Revit API 的很多元素属性受“使用状态”影响。某些属性只有在传递特定参数时才返回有效结果还有很多属性属于内部 API根本不能用反射直接取值。解决判断属性是否在 API 的公开文档里。Revit 的 dll 元数据里标注了哪些成员是对外公开的哪些是内部接口。遇到取不到值的属性优先检查它是不是被标记为 Obsolete 或 Reserved 的内部字段。这个坑属于认知成本比较高的很多开发者一开始会以为是 Lookup 坏了其实只是 Revit 自身的 API 设计如此。6. 二次开发改造给 Lookup 加一个按 Id 批量检索的入口RevitLookup 默认只能看当前选中元素或全模型枚举实际开发里还有一个高频场景你在代码里拿到了一个元素 Id想把它丢进 Lookup 里看内部结构。这个场景可以利用外部命令的入口参数实现改造量很小。思路是新增一个外部命令接收字符串类型的 Id 参数解析成 ElementId 后直接构造 ElementSnoopable 并打开窗口。命令执行时窗口不会自动刷新你可以把它和调试器配合使用断点停住时把 id 传进去。[Transaction(TransactionMode.ReadOnly)] public class SnoopByIdCommand : IExternalCommand { public Result Execute( ExternalCommandData commandData, ref string message, ElementSet elements) { Document doc commandData.Application.ActiveUIDocument.Document; // 从调试器或日志中获得的元素 Id ElementId targetId new ElementId(123456); Element element doc.GetElement(targetId); if (element null) { message $Element {targetId.IntegerValue} not found; return Result.Failed; } SnoopForm.Show(new ElementSnoopable(element)); return Result.Succeeded; } }这种改造方式不需要动原有架构只新增一个命令和一个 addin 条目风险很低。更多的改造方向是把 Lookup 的节点结果导出成结构化数据比如把某个 Element 的所有参数项写成 CSV方便批量对比几个元素的参数差异。我认为这比给工具加更多外观功能更实用——Lookup 本身的价值在于“看清对象”把它变成检查脚本的一部分才是二次开发的上限。从那以后我每次拿到一个陌生 API都强制自己先跑一遍 Snoop 再看文档因为文档里不会写清楚对象内部挂了多少层属性更不会提示你哪些 getter 是雷区。希望这种“先拆开看再猜测”的调试习惯能帮到你。本文还有配套的精品资源点击获取