简介面向 Revit/Dynamo 用户的离线节点包合集适合因网络不稳或官方包管理器访问受限难以在线安装扩展的 BIM 设计师、参数化建模爱好者与二次开发初学者。资源共 2000 个文件压缩包约 63.86MB以 .dyf/.dyn 节点定义、.backup 备份文件为主同时包含 .dll 程序集、.xml 配置、.py 脚本及少量 .rfa/.rvt 族与项目文件其中 .dyf/.dyn 是可直接拖入画布的节点脚本.backup 保留历史版本便于回溯.dll/.py 支撑底层函数与自动化扩展。内容覆盖钢筋路径创建、幕墙分布、曲面放样等多种实际工作流整体按备份目录归档便于手动放置到 Dynamo Packages 文件夹后离线调用。已有 3105 人学习下载。通过该资源可一次获得大批量自定义节点省去逐个下载与版本排查成本适合需要搭建本地节点库、离线扩展 Dynamo 功能或研究节点封装思路的用户收藏备用。1. 自己收集的 Dynamo 节点包值不值得压成一个 packages.zip做 Dynamo 自动化项目的人桌面深处一定躺着几个自己收集的 Dynamo 节点包有人管这叫「自己攒的包」。我从几个 BIM 深化项目里东拼西凑了四十多个自定义节点和十几个零触点 DLL散在五六台机器的不同目录里真正开会演示的时候总是搜不到节点翻车翻到不敢现场改图。后来我把它们统一整理成一份 packages.zip配合目录还原脚本和验证清单离线环境装一次十分钟搞定。这件事的完整做法就是本文要讲清楚的Dynamo 包的内部结构、怎么整理打包、怎么在目标机器上安装验证、坑都在哪。适合正在维护 Dynamo 节点库的工程师也适合准备在团队里统一分发节点包的人。2. 一个能用的 Dynamo 包长什么样目录、清单与加载机制2.1 Dynamo 启动时去哪找包三种包目录与扫描顺序Dynamo 查找自定义包的路径和你从库里拖节点时的体验直接相关。默认情况下包管理器安装的包放在用户目录下%APPDATA%\Dynamo\运行形态子目录\版本号\packages。独立版和宿主内置版的子目录名不一样同一台机器上不同 Dynamo 版本也各有独立目录版本号不同互不干扰。这就是为什么同事装好的节点在你机器上永远搜不到——他装进了他用户名下的那个目录跟你的是两个地方。除了用户目录还有两个位置要留意。一个是 ProgramData 下的 Dynamo 共享目录适合团队统一装一次、每台机器都能读到另一个是 Dynamo 设置里可添加的「包搜索路径」让你指向任意自定义文件夹。我一般会把收集包解压到这个自定义搜索路径下而不是塞进默认 packages 目录这样以后更新收集包不用动系统目录删错了也好恢复。Dynamo 启动时按「自定义搜索路径 → 用户目录 → 共享目录」的顺序扫描并合并包列表扫描发生在启动阶段。这意味着装完新包必须重启 Dynamo 才能看到这句判断后面排错会反复用到。还有个细节同一个包出现在两个搜索路径下时以先扫到的为准版本不对时很难察觉这也是后面要专门做去重的原因。2.2 包内四大件pkg.json、dyf、bin、extra 各管什么一个被 Dynamo 正确识别的包根目录下至少要有 pkg.json 描述文件其余内容按类型分文件夹放。最典型的结构是这样PointTools/ ├── pkg.json // 包元数据Dynamo 靠它识别包名、版本和依赖 ├── dyf/ // 自定义节点文件放这里 │ ├── 01_取点/ // dyf 下的子目录决定节点在库里的分类路径 │ │ └── 墙中心线.dyf │ └── 02_工具/ └── bin/ // 零触点节点C# DLL放这里 └── PointTools.dllpkg.json 是包的脸面。Dynamo 启动时先找 pkg.json读不到就整个包跳过连提示都不给。字段里最关键的是 name、version、engine_version 和 engine_metadata.node_libraries一个典型的离线收集包 pkg.json 长这样{ name: PointTools, version: 1.2.0, description: 常用点处理工具集离线收集自某项目组, group: Company.PtTools, keywords: [point, pointtool], dependencies: [], contents: 自定义节点 12 个零触点 DLL 2 个, engine_version: 2.13.0, engine: dynamo, engine_metadata: { target_versions: [2.13.0], node_libraries: [PointTools.dll, Version1.2.0.0, Cultureneutral, PublicKeyTokennull] }, contains_binaries: true, node_libraries: [PointTools.dll] }这里要逐条解释name 和 version 是包管理器识别身份的主键重名或版本重复都会导致加载异常engine_version 写的是作者打包时的 Dynamo 版本目标机器版本差太多时 Dynamo 可能拒绝加载node_libraries 专门声明零触点 DLL缺了它 bin 里的 DLL 不会被登记成可用节点dependencies 在在线下载场景会被自动解析并拉取依赖但离线收的包没人帮你拉收集时必须把依赖一起收进来。另外包文件夹名最好和 pkg.json 里的 name 保持一致不一致时依赖解析很可能出问题这是包管理器下载包不会遇到、手工收集包却最常见的坑。dyf 目录下的子目录层级就是你在节点库左侧看到的分类路径。比如dyf/01_取点/墙中心线.dyf会显示为 PointTools.01_取点.墙中心线。想改分类直接改子目录名再重启 Dynamo 即可不用动节点内部逻辑。bin 目录对应零触点包零触点节点是编译好的 .NET DLL加载成功后节点名由 DLL 内类的属性决定不是由文件夹名决定。这解释了为什么有人把 DLL 拷进 dyf 目录半天没反应——放错地方了。extra 目录是可选的放图标、示例图、说明文档Dynamo 不强制要求但收集时建议保留原始 extra方便追溯出处和复用示例。2.3 自己收集的包和包管理器下载的包差在哪对比两类包来源你就清楚收集包需要补什么功课对比项包管理器在线下载自己收集的离线包来源官方仓库自动拉取各处拷贝、手工整理依赖pkg.json 声明后自动拉取没人自动拉依赖容易缺版本匹配按当前 Dynamo 版本筛兼容包可能混入旧版本包元数据完整规范经常缺 pkg.json 或字段不全追溯有作者和更新记录出处靠记忆结论很直接离线包最大的风险不在包本身而在「元数据不全 依赖缺失」这两件事。所以下一章的整理步骤核心就是在打包前把这两件事堵住。你收集的包如果都是从包管理器下载过又手动导出的元数据通常完整风险小很多如果是同事之间传来传去、从项目文件夹里翻出来的那 pkg.json 大概率是残缺的必须走一遍校验。3. 把散落的节点包收拢成 packages.zip整理、校验、打包三步走3.1 盘点和去重哪些包值得收、从哪挖常见做法是先把机器上所有 Dynamo 相关目录扫一遍把候选包全部列出来。值得挖的地方包括默认用户目录下的 packages、ProgramData 共享目录、各项目文件夹里附带的 dyf、同事发来的压缩包解出的包以及你自己写零触点包时 bin 的发布目录。收集规则我建议定三条只收还能跑得起来的包pkg.json 缺失且自己也确认有问题的直接丢弃同名多版本的留版本号高的其余列入待清理依赖其他包才能用的必须连同依赖包一起收否则后面还原时一定会报节点未找到。盘点脚本用 PowerShell 最顺手# 列出指定根目录下所有含 pkg.json 的包输出包名和版本顺带找重名 $roots ( D:\DynamoPkgs\collected, $env:APPDATA\Dynamo ) $pkgPaths () foreach ($root in $roots) { if (Test-Path $root) { $pkgPaths Get-ChildItem $root -Recurse -Filter pkg.json -Depth 4 } } $pkgPaths | ForEach-Object { $pkg Get-Content $_.FullName -Raw -Encoding UTF8 | ConvertFrom-Json [PSCustomObject]{ Name $pkg.name Version $pkg.version Path $_.Directory.FullName } } | Sort-Object Name, Version | Format-Table -AutoSize逻辑说明Get-ChildItem 加 -Recurse 和 -Depth 4 是为了在扫描深度的同时避免挖到系统临时目录和备份-Filter pkg.json 只挑包描述文件每个命中项的父亲目录就是一个包根目录。ConvertFrom-Json 把包名和版本拉出来排序同名不同版本一眼就能看出。注意 -Encoding UTF8pkg.json 一般存成 UTF-8如果读出来中文乱码说明源文件是带 BOM 或 GBK 编码打包前最好统一转成无 BOM 的 UTF-8。3.2 校验 pkg.json批量检查关键字段收集过来的包很多是毛坯直接用容易翻车。我建议打包前先跑一遍字段检查只保留「名字、版本、engine_version、node_libraries如有 DLL、dependencies」这几项都合法的包。# 批量校验收集目录下所有包的 pkg.json 关键字段 $root D:\DynamoPkgs\collected $report () Get-ChildItem $root -Directory | ForEach-Object { $pkgFile Join-Path $_.FullName pkg.json if (-not (Test-Path $pkgFile)) { $report 缺少 pkg.json : $($_.Name) return } try { $pkg Get-Content $pkgFile -Raw -Encoding UTF8 | ConvertFrom-Json $hasBin Test-Path (Join-Path $_.FullName bin) if (-not $pkg.name) { $report name 为空 : $($_.Name) } if (-not $pkg.version) { $report version 为空 : $($_.Name) } if (-not $pkg.engine_version) { $report engine_version 为空 : $($_.Name) } if ($hasBin -and $pkg.node_libraries.Count -eq 0) { $report 有 bin 但 node_libraries 未声明 : $($_.Name) } foreach ($dep in $pkg.dependencies) { $depPath Join-Path $root $dep if (-not (Test-Path $depPath)) { $report 依赖缺失 : $($_.Name) - $dep } } } catch { $report JSON 解析失败 : $($_.Name) } } if ($report.Count -eq 0) { 全部通过 } else { $report }逻辑说明脚本把每个包目录当作一个包先查 pkg.json 是否存在再解析 JSON。最容易忽略的两个检查项是「有 bin 但没声明 node_libraries」和「dependencies 点名但收集目录里没有对应包」。前者会导致零触点 DLL 不被登记后者会导致打开图形时依赖节点报未找到。注意 dependencies 里的依赖包名必须和对应包的 pkg.json name 一致光文件夹名对上了没用。参数说明-Directory 是为了只扫一层包目录不会把包内 dyf 子目录误认为新包如果你的收集目录里还套着子分类目录可以把函数换成 Get-ChildItem -Recurse -Depth 1 再配合 pkg.json 过滤。3.3 打成规范 zip目录层级和压缩方式的硬性要求打包这件事九成问题出在层级。最常见的翻车是把整个 collected 文件夹压进去解压出来变成 collected/包A、collected/包BDynamo 拿不到包名直接全部跳过。正确做法是让 zip 的根目录直接就是各个包文件夹。# 将 collected 下的各包目录直接压进 zip 根目录 $src D:\DynamoPkgs\collected $zip D:\DynamoPkgs\packages.zip if (Test-Path $zip) { Remove-Item $zip } Compress-Archive -Path $src\* -DestinationPath $zip -CompressionLevel Optimal # 立刻回读 zip确认根目录下直接是包名而不是外层目录 Add-Type -AssemblyName System.IO.Compression.FileSystem $z [System.IO.Compression.ZipFile]::OpenRead($zip) $z.Entries | Select-Object -First 6 | ForEach-Object { $_.FullName } $z.Dispose()逻辑说明$src\*通配符是关键它取的是 collected 目录下的内容而不是 collected 本身回读 zip 时如果第一条是包A/pkg.json这种形式说明层级正确如果看到collected/包A/pkg.json说明多套了一层要重新打包。压缩级别选 Optimal 就行包里主要是 XML 和 DLL压缩率差异不大。第二个硬性要求是压缩工具的选择。同一个 zip在不同系统上打出来中文文件名的编码可能不一样。Windows 右键的「发送到压缩文件夹」、第三方压缩工具、macOS 和 Linux 上打的 zip对中文目录名的编码处理各不相同解压后经常出现乱码目录Dynamo 一个节点都认不出。我现在的固定做法是统一在 Windows 上用 PowerShell 的 Compress-Archive 打包、用 Expand-Archive 解压绝不在目标机器上用鼠标右键解压收集包。这不是玄学是踩过乱码坑之后定下来的流程。4. 在目标机器上还原 packages.zip安装、路径设置与验证4.1 两个安装方向解压覆盖 vs 设置自定义包路径拿到 packages.zip 后目标机器上有两种装法。方法一是解压进用户目录的 packages适合临时演示和单机使用。# 方法一解压进目标机器的用户 packages 目录 $zipFile D:\DynamoPkgs\packages.zip $hostDir Join-Path $env:APPDATA Dynamo\运行形态子目录 $target Join-Path $hostDir 2.13\packages if (-not (Test-Path $target)) { New-Item -ItemType Directory -Path $target -Force } Expand-Archive -Path $zipFile -DestinationPath $target -Force Get-ChildItem $target -Directory | Select-Object -First 10 Name逻辑说明-Force 表示同名文件直接覆盖配合前面「先盘点去重」的步骤可以确保新包覆盖旧包而不是叠出两个版本最后一行列出 packages 下的一级目录确认解压后直接是包文件夹。运行形态子目录要换成目标机器实际用的子目录名独立版和宿主内置版不一样不确定的话可以先执行一条命令看看本机有哪些 Dynamo 目录Get-ChildItem $env:APPDATA\Dynamo -Directory | Select-Object FullName方法二是解压到自定义目录再在 Dynamo 设置里的包管理器搜索路径中添加这个目录。优点是收集包和系统目录彻底分开以后换版本、删包都干净缺点是要每台机器手动加一次路径批量交付时不如方法一省事。我一般是给临时演示的机器用方法一给长期维护的团队环境用方法二。4.2 装完之后在 Dynamo 里验证搜索、查看已安装包、跑最小样例装完包不是结束验证才是。打开 Dynamo 后按顺序做三件事第一重启后先在左侧节点库搜索框输入包内某个节点的名字确认能搜到且图标不是灰色第二打开包管理器切到「已安装」面板逐个核对包名和版本号和收集清单比对第三把最常用的三五个节点拖进画布连一个最小样例跑通确认节点能算出值而不是拖进去就报错。这里有个容易误判的点搜索框搜不到不代表包没装上。节点名和包名不一定一致dyf 文件名才是搜出来的节点名而零触点节点的名字来自 DLL 里的类名。所以验证时要有意识地区分「这个包装了没」和「这个节点叫什么名」。提前把「包名 → 主要节点名」的对照表写在收集清单里能省大量排查时间。如果验证中发现某个包加载异常第一反应不是删包重装而是先看包管理器已安装面板里这个包的状态。Dynamo 对加载失败的包通常是有记录的提示信息会指出是 JSON 解析失败还是 DLL 加载失败顺着提示定位比盲目重装快得多。安装之后节点库没刷出来最稳妥的恢复手段是把包目录整个删掉、重启 Dynamo、再放回去、再重启一次多数情况下问题就消失了。4.3 自定义节点和零触点节点的加载时机差异两类节点看起来都在库里加载机制完全不同。自定义节点dyf本质是 XML 文本Dynamo 扫描目录时直接解析 dyf 内容所以包一放进目录、重启就生效不需要编译。零触点节点DLL则要等 Dynamo 加载 .NET 程序集加载失败的提示也完全不同——库里有节点拖进画布才报异常这是零触点包的典型症状。理解这个差异对排错很有用搜不到节点先怀疑目录层级和 pkg.json节点能搜到但拖进去报「无法加载程序集」再往 DLL 版本和依赖上查别在错误方向浪费半天。另外 Dynamo 对 DLL 是有缓存的同一个包反复覆盖偶尔会遇到旧程序集还在内存里的情况这时候只重启 Dynamo 不一定有效把包目录整个删掉重放一遍更可靠。我见过同事在一个零触点包上反复覆盖了五次重启三次都没用最后删目录重放一次就正常了这类问题用「先删后放」基本都能解决。5. 收集包还原过程的避坑清单五个高频问题与排查路径5.1 压缩包里多套了一层目录节点全部失踪现象解压后目录结构看着没问题但 Dynamo 里一个节点都搜不到包管理器已安装列表也是空的。原因打包时把收集根目录整个压了进去zip 根目录是 collected/包A/...而不是 包A/...。Dynamo 在扫描路径下没直接看到包根目录里的 pkg.json整个包被静默跳过。解决重新打包用 3.3 节Compress-Archive -Path $src\*的方式把包内容压进 zip 根目录解压前先跑回读脚本看一眼 zip 条目路径再决定解压目标。这个检查三十秒就能做完能拦住九成「装完搜不到」的问题。5.2 pkg.json 手改导致 JSON 解析失败包被静默跳过现象包管理器里看不到这个包但也没有明确报错用编辑器打开 pkg.json 一眼看不出问题。原因最常见两种一是加了注释JSON 标准不允许注释二是字符串里混入中文引号或末尾多逗号。手改 pkg.json 时极易踩中尤其从网页或聊天工具里复制内容时引号被自动转成中文标点。解决用 PowerShell 的 ConvertFrom-Json 解析一遍再入库养成「改完必跑校验脚本」的习惯。保存时不要用系统记事本直接存成带 BOM 的 UTF-8统一用无 BOM UTF-8否则某些 Dynamo 版本读取中文描述时会出现乱码。5.3 包之间的依赖没带上打开图形一堆「节点未找到」现象某个包自己正常但打开包含它的图形时画布上冒出大量橙色警告提示找不到某个自定义节点。原因收集时只收了一个包没收它 pkg.json dependencies 里点名的依赖包。在线包管理器会自动拉依赖离线 zip 不会这是收集包和在线包最大的体验差。解决收集时按 dependencies 字段把依赖包一并收进 zip排查时看警告里缺失节点的分类路径反推它属于哪个包再决定要不要补收。补收后重启 Dynamo 再打开图形。若依赖包本身也有依赖就顺着链条往下收直到 dependencies 全部为空为止。5.4 零触点包 DLL 加载失败版本与运行库不匹配现象节点能在库里搜到拖进画布就报「无法加载 DLL」或程序集相关异常某些包只有特定 Dynamo 版本能跑换个版本就出问题。原因DLL 是按作者打包时的 Dynamo 和宿主程序版本编译的目标机器版本偏旧或偏新都可能加载失败另外 DLL 依赖的第三方运行库没被收集进 bin也是一个隐藏原因。解决优先选与目标 Dynamo 主版本一致的包版本把 bin 目录下所有 DLL 一起带走不要只拿主 DLL实在不兼容去找该包更高版本重新打包而不是硬解。排查时在画布上打开节点的详细报错看到 assembly 字样基本就是这类问题。5.5 同名包新老版本混放节点分类下出现两个同名项现象节点库里同一个分类下出现两个同名节点拖哪个都心里没底包管理器里看到同一个包的两个版本。原因收集时去重没做干净新老版本被分别放进了 packages 目录Dynamo 按目录加载两个都算数。解决回到 3.1 的盘点脚本按包名列出所有版本保留与目标 Dynamo 版本对应的那个其余移出搜索路径。以后更新收集包时先把旧包目录移走再放新包避免覆盖失败后的残留。养成这个习惯后「版本混乱」这类问题基本不会再出现。6. 让收集包长期好用的三个习惯6.1 版本号写进 pkg.json别只记在文件夹名上我吃过一次亏把一个包文件夹命名为 PointTools_final_2024结果包管理器显示版本还是 1.0.0半个月后自己都分不清哪份是最新的。现在每收一个包第一件事就是打开 pkg.json 核对 name 和 version不对就改文件夹名反而不用太在意。6.2 每次打包顺手写一份收集清单清单里记三行包名、版本、从哪个项目或哪台机器收来的再补一行「主要节点名对照」。这份清单放进 zip 根目录命名为 README.txt。半年后再打开 packages.zip你能靠它想起每个包是干什么的也能快速判断某台机器缺哪个包。这个文本文件不占空间但价值比很多包都大。6.3 先隔离验证、再批量分发每次整理完收集包先在备用机或新建的独立 Dynamo 用户目录里完整验证一遍再对外分发。验证内容就是 4.2 节那三步搜索、查已安装、跑最小样例。批量分发时只发 zip 和还原脚本不让人手动改路径从源头减少操作差异带来的问题。我现在每个季度会把各项目里新增的节点包重新盘一次更新 packages.zip并在团队共享目录里留一份最新版。这样做之后新同事入职装环境的时间从半天缩短到半小时我也再没遇到「现场演示时节点失踪」的尴尬。整理收集包不是一次性工作而是一个持续维护的习惯希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 13:59:59 · 阅读 1.2k Dynamo节点包离线打包与还原：packages.zip制作与部署
简介面向 Revit/Dynamo 用户的离线节点包合集适合因网络不稳或官方包管理器访问受限难以在线安装扩展的 BIM 设计师、参数化建模爱好者与二次开发初学者。资源共 2000 个文件压缩包约 63.86MB以 .dyf/.dyn 节点定义、.backup 备份文件为主同时包含 .dll 程序集、.xml 配置、.py 脚本及少量 .rfa/.rvt 族与项目文件其中 .dyf/.dyn 是可直接拖入画布的节点脚本.backup 保留历史版本便于回溯.dll/.py 支撑底层函数与自动化扩展。内容覆盖钢筋路径创建、幕墙分布、曲面放样等多种实际工作流整体按备份目录归档便于手动放置到 Dynamo Packages 文件夹后离线调用。已有 3105 人学习下载。通过该资源可一次获得大批量自定义节点省去逐个下载与版本排查成本适合需要搭建本地节点库、离线扩展 Dynamo 功能或研究节点封装思路的用户收藏备用。1. 自己收集的 Dynamo 节点包值不值得压成一个 packages.zip做 Dynamo 自动化项目的人桌面深处一定躺着几个自己收集的 Dynamo 节点包有人管这叫「自己攒的包」。我从几个 BIM 深化项目里东拼西凑了四十多个自定义节点和十几个零触点 DLL散在五六台机器的不同目录里真正开会演示的时候总是搜不到节点翻车翻到不敢现场改图。后来我把它们统一整理成一份 packages.zip配合目录还原脚本和验证清单离线环境装一次十分钟搞定。这件事的完整做法就是本文要讲清楚的Dynamo 包的内部结构、怎么整理打包、怎么在目标机器上安装验证、坑都在哪。适合正在维护 Dynamo 节点库的工程师也适合准备在团队里统一分发节点包的人。2. 一个能用的 Dynamo 包长什么样目录、清单与加载机制2.1 Dynamo 启动时去哪找包三种包目录与扫描顺序Dynamo 查找自定义包的路径和你从库里拖节点时的体验直接相关。默认情况下包管理器安装的包放在用户目录下%APPDATA%\Dynamo\运行形态子目录\版本号\packages。独立版和宿主内置版的子目录名不一样同一台机器上不同 Dynamo 版本也各有独立目录版本号不同互不干扰。这就是为什么同事装好的节点在你机器上永远搜不到——他装进了他用户名下的那个目录跟你的是两个地方。除了用户目录还有两个位置要留意。一个是 ProgramData 下的 Dynamo 共享目录适合团队统一装一次、每台机器都能读到另一个是 Dynamo 设置里可添加的「包搜索路径」让你指向任意自定义文件夹。我一般会把收集包解压到这个自定义搜索路径下而不是塞进默认 packages 目录这样以后更新收集包不用动系统目录删错了也好恢复。Dynamo 启动时按「自定义搜索路径 → 用户目录 → 共享目录」的顺序扫描并合并包列表扫描发生在启动阶段。这意味着装完新包必须重启 Dynamo 才能看到这句判断后面排错会反复用到。还有个细节同一个包出现在两个搜索路径下时以先扫到的为准版本不对时很难察觉这也是后面要专门做去重的原因。2.2 包内四大件pkg.json、dyf、bin、extra 各管什么一个被 Dynamo 正确识别的包根目录下至少要有 pkg.json 描述文件其余内容按类型分文件夹放。最典型的结构是这样PointTools/ ├── pkg.json // 包元数据Dynamo 靠它识别包名、版本和依赖 ├── dyf/ // 自定义节点文件放这里 │ ├── 01_取点/ // dyf 下的子目录决定节点在库里的分类路径 │ │ └── 墙中心线.dyf │ └── 02_工具/ └── bin/ // 零触点节点C# DLL放这里 └── PointTools.dllpkg.json 是包的脸面。Dynamo 启动时先找 pkg.json读不到就整个包跳过连提示都不给。字段里最关键的是 name、version、engine_version 和 engine_metadata.node_libraries一个典型的离线收集包 pkg.json 长这样{ name: PointTools, version: 1.2.0, description: 常用点处理工具集离线收集自某项目组, group: Company.PtTools, keywords: [point, pointtool], dependencies: [], contents: 自定义节点 12 个零触点 DLL 2 个, engine_version: 2.13.0, engine: dynamo, engine_metadata: { target_versions: [2.13.0], node_libraries: [PointTools.dll, Version1.2.0.0, Cultureneutral, PublicKeyTokennull] }, contains_binaries: true, node_libraries: [PointTools.dll] }这里要逐条解释name 和 version 是包管理器识别身份的主键重名或版本重复都会导致加载异常engine_version 写的是作者打包时的 Dynamo 版本目标机器版本差太多时 Dynamo 可能拒绝加载node_libraries 专门声明零触点 DLL缺了它 bin 里的 DLL 不会被登记成可用节点dependencies 在在线下载场景会被自动解析并拉取依赖但离线收的包没人帮你拉收集时必须把依赖一起收进来。另外包文件夹名最好和 pkg.json 里的 name 保持一致不一致时依赖解析很可能出问题这是包管理器下载包不会遇到、手工收集包却最常见的坑。dyf 目录下的子目录层级就是你在节点库左侧看到的分类路径。比如dyf/01_取点/墙中心线.dyf会显示为 PointTools.01_取点.墙中心线。想改分类直接改子目录名再重启 Dynamo 即可不用动节点内部逻辑。bin 目录对应零触点包零触点节点是编译好的 .NET DLL加载成功后节点名由 DLL 内类的属性决定不是由文件夹名决定。这解释了为什么有人把 DLL 拷进 dyf 目录半天没反应——放错地方了。extra 目录是可选的放图标、示例图、说明文档Dynamo 不强制要求但收集时建议保留原始 extra方便追溯出处和复用示例。2.3 自己收集的包和包管理器下载的包差在哪对比两类包来源你就清楚收集包需要补什么功课对比项包管理器在线下载自己收集的离线包来源官方仓库自动拉取各处拷贝、手工整理依赖pkg.json 声明后自动拉取没人自动拉依赖容易缺版本匹配按当前 Dynamo 版本筛兼容包可能混入旧版本包元数据完整规范经常缺 pkg.json 或字段不全追溯有作者和更新记录出处靠记忆结论很直接离线包最大的风险不在包本身而在「元数据不全 依赖缺失」这两件事。所以下一章的整理步骤核心就是在打包前把这两件事堵住。你收集的包如果都是从包管理器下载过又手动导出的元数据通常完整风险小很多如果是同事之间传来传去、从项目文件夹里翻出来的那 pkg.json 大概率是残缺的必须走一遍校验。3. 把散落的节点包收拢成 packages.zip整理、校验、打包三步走3.1 盘点和去重哪些包值得收、从哪挖常见做法是先把机器上所有 Dynamo 相关目录扫一遍把候选包全部列出来。值得挖的地方包括默认用户目录下的 packages、ProgramData 共享目录、各项目文件夹里附带的 dyf、同事发来的压缩包解出的包以及你自己写零触点包时 bin 的发布目录。收集规则我建议定三条只收还能跑得起来的包pkg.json 缺失且自己也确认有问题的直接丢弃同名多版本的留版本号高的其余列入待清理依赖其他包才能用的必须连同依赖包一起收否则后面还原时一定会报节点未找到。盘点脚本用 PowerShell 最顺手# 列出指定根目录下所有含 pkg.json 的包输出包名和版本顺带找重名 $roots ( D:\DynamoPkgs\collected, $env:APPDATA\Dynamo ) $pkgPaths () foreach ($root in $roots) { if (Test-Path $root) { $pkgPaths Get-ChildItem $root -Recurse -Filter pkg.json -Depth 4 } } $pkgPaths | ForEach-Object { $pkg Get-Content $_.FullName -Raw -Encoding UTF8 | ConvertFrom-Json [PSCustomObject]{ Name $pkg.name Version $pkg.version Path $_.Directory.FullName } } | Sort-Object Name, Version | Format-Table -AutoSize逻辑说明Get-ChildItem 加 -Recurse 和 -Depth 4 是为了在扫描深度的同时避免挖到系统临时目录和备份-Filter pkg.json 只挑包描述文件每个命中项的父亲目录就是一个包根目录。ConvertFrom-Json 把包名和版本拉出来排序同名不同版本一眼就能看出。注意 -Encoding UTF8pkg.json 一般存成 UTF-8如果读出来中文乱码说明源文件是带 BOM 或 GBK 编码打包前最好统一转成无 BOM 的 UTF-8。3.2 校验 pkg.json批量检查关键字段收集过来的包很多是毛坯直接用容易翻车。我建议打包前先跑一遍字段检查只保留「名字、版本、engine_version、node_libraries如有 DLL、dependencies」这几项都合法的包。# 批量校验收集目录下所有包的 pkg.json 关键字段 $root D:\DynamoPkgs\collected $report () Get-ChildItem $root -Directory | ForEach-Object { $pkgFile Join-Path $_.FullName pkg.json if (-not (Test-Path $pkgFile)) { $report 缺少 pkg.json : $($_.Name) return } try { $pkg Get-Content $pkgFile -Raw -Encoding UTF8 | ConvertFrom-Json $hasBin Test-Path (Join-Path $_.FullName bin) if (-not $pkg.name) { $report name 为空 : $($_.Name) } if (-not $pkg.version) { $report version 为空 : $($_.Name) } if (-not $pkg.engine_version) { $report engine_version 为空 : $($_.Name) } if ($hasBin -and $pkg.node_libraries.Count -eq 0) { $report 有 bin 但 node_libraries 未声明 : $($_.Name) } foreach ($dep in $pkg.dependencies) { $depPath Join-Path $root $dep if (-not (Test-Path $depPath)) { $report 依赖缺失 : $($_.Name) - $dep } } } catch { $report JSON 解析失败 : $($_.Name) } } if ($report.Count -eq 0) { 全部通过 } else { $report }逻辑说明脚本把每个包目录当作一个包先查 pkg.json 是否存在再解析 JSON。最容易忽略的两个检查项是「有 bin 但没声明 node_libraries」和「dependencies 点名但收集目录里没有对应包」。前者会导致零触点 DLL 不被登记后者会导致打开图形时依赖节点报未找到。注意 dependencies 里的依赖包名必须和对应包的 pkg.json name 一致光文件夹名对上了没用。参数说明-Directory 是为了只扫一层包目录不会把包内 dyf 子目录误认为新包如果你的收集目录里还套着子分类目录可以把函数换成 Get-ChildItem -Recurse -Depth 1 再配合 pkg.json 过滤。3.3 打成规范 zip目录层级和压缩方式的硬性要求打包这件事九成问题出在层级。最常见的翻车是把整个 collected 文件夹压进去解压出来变成 collected/包A、collected/包BDynamo 拿不到包名直接全部跳过。正确做法是让 zip 的根目录直接就是各个包文件夹。# 将 collected 下的各包目录直接压进 zip 根目录 $src D:\DynamoPkgs\collected $zip D:\DynamoPkgs\packages.zip if (Test-Path $zip) { Remove-Item $zip } Compress-Archive -Path $src\* -DestinationPath $zip -CompressionLevel Optimal # 立刻回读 zip确认根目录下直接是包名而不是外层目录 Add-Type -AssemblyName System.IO.Compression.FileSystem $z [System.IO.Compression.ZipFile]::OpenRead($zip) $z.Entries | Select-Object -First 6 | ForEach-Object { $_.FullName } $z.Dispose()逻辑说明$src\*通配符是关键它取的是 collected 目录下的内容而不是 collected 本身回读 zip 时如果第一条是包A/pkg.json这种形式说明层级正确如果看到collected/包A/pkg.json说明多套了一层要重新打包。压缩级别选 Optimal 就行包里主要是 XML 和 DLL压缩率差异不大。第二个硬性要求是压缩工具的选择。同一个 zip在不同系统上打出来中文文件名的编码可能不一样。Windows 右键的「发送到压缩文件夹」、第三方压缩工具、macOS 和 Linux 上打的 zip对中文目录名的编码处理各不相同解压后经常出现乱码目录Dynamo 一个节点都认不出。我现在的固定做法是统一在 Windows 上用 PowerShell 的 Compress-Archive 打包、用 Expand-Archive 解压绝不在目标机器上用鼠标右键解压收集包。这不是玄学是踩过乱码坑之后定下来的流程。4. 在目标机器上还原 packages.zip安装、路径设置与验证4.1 两个安装方向解压覆盖 vs 设置自定义包路径拿到 packages.zip 后目标机器上有两种装法。方法一是解压进用户目录的 packages适合临时演示和单机使用。# 方法一解压进目标机器的用户 packages 目录 $zipFile D:\DynamoPkgs\packages.zip $hostDir Join-Path $env:APPDATA Dynamo\运行形态子目录 $target Join-Path $hostDir 2.13\packages if (-not (Test-Path $target)) { New-Item -ItemType Directory -Path $target -Force } Expand-Archive -Path $zipFile -DestinationPath $target -Force Get-ChildItem $target -Directory | Select-Object -First 10 Name逻辑说明-Force 表示同名文件直接覆盖配合前面「先盘点去重」的步骤可以确保新包覆盖旧包而不是叠出两个版本最后一行列出 packages 下的一级目录确认解压后直接是包文件夹。运行形态子目录要换成目标机器实际用的子目录名独立版和宿主内置版不一样不确定的话可以先执行一条命令看看本机有哪些 Dynamo 目录Get-ChildItem $env:APPDATA\Dynamo -Directory | Select-Object FullName方法二是解压到自定义目录再在 Dynamo 设置里的包管理器搜索路径中添加这个目录。优点是收集包和系统目录彻底分开以后换版本、删包都干净缺点是要每台机器手动加一次路径批量交付时不如方法一省事。我一般是给临时演示的机器用方法一给长期维护的团队环境用方法二。4.2 装完之后在 Dynamo 里验证搜索、查看已安装包、跑最小样例装完包不是结束验证才是。打开 Dynamo 后按顺序做三件事第一重启后先在左侧节点库搜索框输入包内某个节点的名字确认能搜到且图标不是灰色第二打开包管理器切到「已安装」面板逐个核对包名和版本号和收集清单比对第三把最常用的三五个节点拖进画布连一个最小样例跑通确认节点能算出值而不是拖进去就报错。这里有个容易误判的点搜索框搜不到不代表包没装上。节点名和包名不一定一致dyf 文件名才是搜出来的节点名而零触点节点的名字来自 DLL 里的类名。所以验证时要有意识地区分「这个包装了没」和「这个节点叫什么名」。提前把「包名 → 主要节点名」的对照表写在收集清单里能省大量排查时间。如果验证中发现某个包加载异常第一反应不是删包重装而是先看包管理器已安装面板里这个包的状态。Dynamo 对加载失败的包通常是有记录的提示信息会指出是 JSON 解析失败还是 DLL 加载失败顺着提示定位比盲目重装快得多。安装之后节点库没刷出来最稳妥的恢复手段是把包目录整个删掉、重启 Dynamo、再放回去、再重启一次多数情况下问题就消失了。4.3 自定义节点和零触点节点的加载时机差异两类节点看起来都在库里加载机制完全不同。自定义节点dyf本质是 XML 文本Dynamo 扫描目录时直接解析 dyf 内容所以包一放进目录、重启就生效不需要编译。零触点节点DLL则要等 Dynamo 加载 .NET 程序集加载失败的提示也完全不同——库里有节点拖进画布才报异常这是零触点包的典型症状。理解这个差异对排错很有用搜不到节点先怀疑目录层级和 pkg.json节点能搜到但拖进去报「无法加载程序集」再往 DLL 版本和依赖上查别在错误方向浪费半天。另外 Dynamo 对 DLL 是有缓存的同一个包反复覆盖偶尔会遇到旧程序集还在内存里的情况这时候只重启 Dynamo 不一定有效把包目录整个删掉重放一遍更可靠。我见过同事在一个零触点包上反复覆盖了五次重启三次都没用最后删目录重放一次就正常了这类问题用「先删后放」基本都能解决。5. 收集包还原过程的避坑清单五个高频问题与排查路径5.1 压缩包里多套了一层目录节点全部失踪现象解压后目录结构看着没问题但 Dynamo 里一个节点都搜不到包管理器已安装列表也是空的。原因打包时把收集根目录整个压了进去zip 根目录是 collected/包A/...而不是 包A/...。Dynamo 在扫描路径下没直接看到包根目录里的 pkg.json整个包被静默跳过。解决重新打包用 3.3 节Compress-Archive -Path $src\*的方式把包内容压进 zip 根目录解压前先跑回读脚本看一眼 zip 条目路径再决定解压目标。这个检查三十秒就能做完能拦住九成「装完搜不到」的问题。5.2 pkg.json 手改导致 JSON 解析失败包被静默跳过现象包管理器里看不到这个包但也没有明确报错用编辑器打开 pkg.json 一眼看不出问题。原因最常见两种一是加了注释JSON 标准不允许注释二是字符串里混入中文引号或末尾多逗号。手改 pkg.json 时极易踩中尤其从网页或聊天工具里复制内容时引号被自动转成中文标点。解决用 PowerShell 的 ConvertFrom-Json 解析一遍再入库养成「改完必跑校验脚本」的习惯。保存时不要用系统记事本直接存成带 BOM 的 UTF-8统一用无 BOM UTF-8否则某些 Dynamo 版本读取中文描述时会出现乱码。5.3 包之间的依赖没带上打开图形一堆「节点未找到」现象某个包自己正常但打开包含它的图形时画布上冒出大量橙色警告提示找不到某个自定义节点。原因收集时只收了一个包没收它 pkg.json dependencies 里点名的依赖包。在线包管理器会自动拉依赖离线 zip 不会这是收集包和在线包最大的体验差。解决收集时按 dependencies 字段把依赖包一并收进 zip排查时看警告里缺失节点的分类路径反推它属于哪个包再决定要不要补收。补收后重启 Dynamo 再打开图形。若依赖包本身也有依赖就顺着链条往下收直到 dependencies 全部为空为止。5.4 零触点包 DLL 加载失败版本与运行库不匹配现象节点能在库里搜到拖进画布就报「无法加载 DLL」或程序集相关异常某些包只有特定 Dynamo 版本能跑换个版本就出问题。原因DLL 是按作者打包时的 Dynamo 和宿主程序版本编译的目标机器版本偏旧或偏新都可能加载失败另外 DLL 依赖的第三方运行库没被收集进 bin也是一个隐藏原因。解决优先选与目标 Dynamo 主版本一致的包版本把 bin 目录下所有 DLL 一起带走不要只拿主 DLL实在不兼容去找该包更高版本重新打包而不是硬解。排查时在画布上打开节点的详细报错看到 assembly 字样基本就是这类问题。5.5 同名包新老版本混放节点分类下出现两个同名项现象节点库里同一个分类下出现两个同名节点拖哪个都心里没底包管理器里看到同一个包的两个版本。原因收集时去重没做干净新老版本被分别放进了 packages 目录Dynamo 按目录加载两个都算数。解决回到 3.1 的盘点脚本按包名列出所有版本保留与目标 Dynamo 版本对应的那个其余移出搜索路径。以后更新收集包时先把旧包目录移走再放新包避免覆盖失败后的残留。养成这个习惯后「版本混乱」这类问题基本不会再出现。6. 让收集包长期好用的三个习惯6.1 版本号写进 pkg.json别只记在文件夹名上我吃过一次亏把一个包文件夹命名为 PointTools_final_2024结果包管理器显示版本还是 1.0.0半个月后自己都分不清哪份是最新的。现在每收一个包第一件事就是打开 pkg.json 核对 name 和 version不对就改文件夹名反而不用太在意。6.2 每次打包顺手写一份收集清单清单里记三行包名、版本、从哪个项目或哪台机器收来的再补一行「主要节点名对照」。这份清单放进 zip 根目录命名为 README.txt。半年后再打开 packages.zip你能靠它想起每个包是干什么的也能快速判断某台机器缺哪个包。这个文本文件不占空间但价值比很多包都大。6.3 先隔离验证、再批量分发每次整理完收集包先在备用机或新建的独立 Dynamo 用户目录里完整验证一遍再对外分发。验证内容就是 4.2 节那三步搜索、查已安装、跑最小样例。批量分发时只发 zip 和还原脚本不让人手动改路径从源头减少操作差异带来的问题。我现在每个季度会把各项目里新增的节点包重新盘一次更新 packages.zip并在团队共享目录里留一份最新版。这样做之后新同事入职装环境的时间从半天缩短到半小时我也再没遇到「现场演示时节点失踪」的尴尬。整理收集包不是一次性工作而是一个持续维护的习惯希望帮到你。本文还有配套的精品资源点击获取