版本声明本篇基线为AVEVA E3D Design 3.1前代产品统一写作AVEVA PDMS。政策事实自 2024 年 4 月 1 日起AVEVA PDMS 不再销售、不再提供支持研发投入全部转向 E3D Design。迁移路径包括本地或云端部署也可作为 AVEVA Unified Engineering 的一部分交付官方口径是 E3D Design 仍与 PDMS 后续版本兼容客户可在两平台并行PDMS 最终被淘汰。必须如实交代的关键事实官方并未给出旧命名空间 → 新命名空间的迁移对照表。社区帖中出现的对应关系Aveva.Pdms.PMLNet→Aveva.Core.PMLNet、Aveva.Pdms.Presentation→Aveva.Core.Presentation、Aveva.Pdms.Presentation.PDMSCommands→Aveva.Core.Commands来源性质为社区仅作线索不得当作官方结论。版本纠错15.x 不是 E3D Design 的版本而是 AVEVA Engineering 的版本线。文档站同时列出 “E3D Design 3.1” 与 “Engineering 15.8”。E3D Design 未发现 15.x 命名。本篇脚本为纯文本扫描与差异报表工具不调用 AVEVA API所有命中数量、文件数量一律为示意真实值须在本机跑出。一句话结论PDMS 到 E3D 的定制迁移最大的风险不是语法变了而是旧程序集在新环境里根本不存在、而官方又没有给对照表——所以迁移的正确姿势是扫描 → 分级 → 逐个验证而不是改个命名空间就交差。〇 认知问题PDMS 现在到底还能不能用迁移是必须做还是想做再做我手上的定制资产哪些能直接搬过去哪些必须重写旧的程序集名如Pdms.Database.dll、PDMSFilters.dll在 E3D Design 里对应谁有没有官方对照表社区帖里说的那些命名空间对应关系能不能直接拿去批量替换迁移之后我怎么向项目证明行为没变一 机制解析1.1 政策背景迁移窗口是真实存在的先把政策事实摆清楚来源官方产品页与官方博客项事实停售与停支持自 2024 年 4 月 1 日起AVEVA PDMS 不再销售、不再提供支持研发投入全部转向AVEVA E3D Design迁移路径本地部署或云端部署亦可作为AVEVA Unified Engineering的一部分交付并行期官方称 E3D Design 仍与 PDMS 后续版本兼容客户可在两个平台并行推进终局PDMS 最终被淘汰第 1 个认知问题的答案是明确的PDMS 还能用但不再销售、不再提供支持意味着新问题不会再有官方补丁迁移是必答题只是答得早晚而已。而在并行期迁移恰恰是最有利的时间窗——两个平台都在可以用来做对照验证这也是本篇强调逐个验证的现实基础。1.2 三类迁移资产成本差异极大定制代码要迁移的资产分三类迁移成本从低到高资产类别典型内容迁移成本主要风险① PML 宏 / 函数 / 表单.pmlfnc、.pmlfrm、.pmlobj低语言本身跨代基本延续风险在引用了什么数据/命令② PML.NET 程序集用PMLNetCallable暴露给 PML 的 .NET 类中程序集名与命名空间换代加载路径与验证方式要重做③ .NET Addin实现IAddin的 CAF 插件、命令类、UIC高程序集全换代 装载配置 界面机制command ribbon三重变化第 2 个认知问题的答案一句话概括PML 资产是搬PML.NET 资产是改.NET Addin 资产是重建至少要重新验证装载与界面两块。原因是三层技术依赖的稳定性不同PML 语法本身是语言层跨代延续性最好PML.NET 依赖程序集与命名空间.NET Addin 除了依赖程序集还依赖装载配置文件模块名Addins.xml与界面机制.uic与命令Key而界面机制正是官方明确指出旧式方式仍受支持但不推荐、与 command ribbon 不兼容的地方。1.3 程序集与命名空间的代际差异可核实的差异如下来源官方 NCUG 与历史版本文档代数据库程序集过滤器程序集PDMS 12.0 时代Pdms.Database.dllPDMSFilters.dllE3D Design 3.1Aveva.Core.Database.dllAveva.Core.Database.Filters.dllE3D Design 3.1 侧可用的核心程序集还包括Aveva.ApplicationFramework.dll、Aveva.ApplicationFramework.Presentation.dll、Aveva.Core.Geometry.dll、Aveva.Core.Maths.Geometry.dll、Aveva.Core.Shared.dll、Aveva.Core.Utilities*.dll、Aveva.Core3D.Graphics.dll、Aveva.Engineering.Tags.Pml.dllStandalone 程序集为Aveva.Core3D.Standalone、Aveva.E3D.Standalone。关键观察旧名Pdms.Database.dll与新名Aveva.Core.Database.dll之间“Pdms” 与 “Core” 的替换看起来天经地义但PDMSFilters.dll→Aveva.Core.Database.Filters.dll就不是简单替换还多了.Database这层。一键替换在这里立刻失效——这就是第 3 个认知问题的答案旧程序集在 E3D Design 里对应谁官方没有公开对照表只能逐个去实际安装目录里确认该程序集是否存在。1.4 官方没有对照表社区说法怎么用第 4 个认知问题是本篇最重要的一条纪律。事实是官方未提供PDMS → E3D 的命名空间/程序集迁移对照表本次调研在官方文档渠道中未找到社区帖提到的三条对应关系是Aveva.Pdms.PMLNet→Aveva.Core.PMLNetAveva.Pdms.Presentation→Aveva.Core.PresentationAveva.Pdms.Presentation.PDMSCommands→Aveva.Core.Commands这三条只能当线索不能当结论。使用纪律有四条不批量替换。按线索逐个替换、逐个编译、逐个运行验证不写进项目规范。项目规范里只能写已验证存在的程序集与命名空间清单不能写社区说应该等于……验证方式唯一在本地 E3D Design 环境的安装目录里找出该程序集文件是否存在再用反射/IntelliSense 确认类型是否存在把验证结果落表。每验证一条就登记一条最终这份表就是你项目的私人对照表——它比任何网上流传的表都可靠。另外要牢记系列铁律 2混合开发前先确认产品版本Aveva.Pdms.*与Aveva.Core.*是两代命名空间官方未给迁移表只能逐个验证。1.5 迁移的四个阶段阶段目标产出完成判据A 清点知道有哪些资产资产清单文件级文件数与仓库对得上B 扫描找出所有代际敏感的引用命中清单行级每处命中都有风险等级C 分级改造按风险等级处理改造后的代码 验证记录每处命中都有已改/已证/已弃结论D 回归验证证明行为未变对照测试记录既定用例全部通过四阶段里B 阶段的扫描器是全流程的性价比之王它不依赖任何 AVEVA API纯文本就能跑却能把埋在几千个文件里的旧引用一次性挖出来。1.6 回归测试设计等价性优先第 5 个认知问题的答案是对照测试。设计要点三条黄金样本在 PDMS 环境里把关键场景的输出清单、报表、日志保存下来作为黄金样本同输入同输出在 E3D 环境里跑同一批输入把输出与黄金样本逐行比对差异必须可解释任何差异都要落到预期内或缺陷二选一不允许大致相同。其中第二条要特别注意一个陷阱输出里的时间戳、路径、版本号必然不同比对前要先把这些字段规范化掉否则比对结果全是噪声。二 完整代码与逐行剖析2.1 迁移自查器旧引用扫描脚本这段脚本扫描定制代码仓库里的代际敏感字符串输出一份差异报表。它不调用任何 AVEVA API因此在迁移开始前就能跑——这是全流程里唯一零依赖、可立刻上手的一步。# scan-legacy.ps1 —— PDMS → E3D 定制迁移自查器只读扫描param([Parameter(Mandatory $true)][string]$Root,# 代码仓库根目录[Parameter(Mandatory $true)][string]$OutCsv# 输出命中清单 CSV)# 扫描规则每条 一个代际敏感特征# 注意这里是发现线索不是判定结论# 社区流传的命名空间对应关系只作线索必须逐个在本机验证。$rules ({Type旧数据库程序集;Rx (?i)\bPdms\.Database\.dll\b},{Type旧过滤器程序集;Rx (?i)\bPDMSFilters\.dll\b},{Type旧命名空间;Rx (?i)\bAveva\.Pdms\.[A-Za-z0-9_.]*},{Type旧命令命名空间;Rx (?i)\bAveva\.Pdms\.Presentation\.PDMSCommands\b},{Type版本号误标;Rx (?i)\bE3D\s*1[5-9]\.[0-9]},{Type硬编码安装路径;Rx (?i)[A-Z]:\\[^:]*\\(AVEVA|Cadcentre|Program Files)})# 覆盖 PML 与 .NET 两侧的常见文件类型# PML 侧扩展名清单与第三方 PML 语言服务支持的扩展名一致见参考文献第三方资源说明$exts*.pml,*.pmlfnc,*.pmlfrm,*.pmlobj,*.pmlmac,*.pmlcmd,*.cs,*.xml$hitsforeach($ein$exts){Get-ChildItem-LiteralPath$Root-Recurse-File-Filter$e-ErrorAction SilentlyContinue|ForEach-Object{$file$_$ln 0foreach($linein(Get-Content-LiteralPath$file.FullName-Encoding UTF8)){$lnforeach($rin$rules){if($line-match$r.Rx){[pscustomobject]{文件 $file.FullName.Substring($Root.Length).TrimStart(\)行号 $ln命中类型 $r.Type命中原文 $Matches[0]风险等级 if($r.Type-in(旧数据库程序集,旧过滤器程序集,旧命名空间,旧命令命名空间)){高}else{中}结论 待验证# 一律初始为待验证禁止直接标已改}break# 同一行只记第一条命中避免噪声}}}}}$hits|Export-Csv-LiteralPath$OutCsv-NoTypeInformation-Encoding UTF8$summary$hits|Group-Object命中类型|Sort-ObjectCount-Descending|Select-ObjectName,Count命中总数$($hits.Count)$summary|Format-Table-AutoSize2.2 逐行剖析为什么是扫描文本而不是解析代码因为迁移期最需要的是广度而不是精度解析器只能处理语法正确的代码而真实迁移中最麻烦的恰恰是语法有问题、早已没人维护的老脚本。纯文本扫描能把这些一起捞出来。{ Type …; Rx … }规则表把要查什么与怎么查分离成数据是让这个脚本能持续演进的关键。以后发现新的代际敏感特征例如某个界面类名往规则表里加一行即可不用改逻辑。(?i)\bPdms\.Database\.dll\b(?i)忽略大小写旧代码里字符串大小写常不一致\b词边界避免匹配到XxxPdms.Database.dll这类误命中把.转义为\.以保证按字面匹配。(?i)\bAveva\.Pdms\.[A-Za-z0-9_.]*这条是最关键的线索收集规则。它不假设任何对应关系只把Aveva.Pdms.*家族全部列出——因为社区线索里三条对应关系远远覆盖不了真实代码里出现过的所有Aveva.Pdms.*命名空间。先列出全部再逐个验证。(?i)\bE3D\s*1[5-9]\.[0-9]这条规则本身就是一处事实纠错的固化15.x 不是 E3D Design 的版本而是 AVEVA Engineering 的版本线。老代码或老注释里若写了E3D 15.x说明其版本认知本身就是错的迁移时必须一并纠正。(?i)[A-Z]:\\[^:]*\\(AVEVA|Cadcentre|Program Files)硬编码安装路径是迁移期最容易被低估的坑代码在新机器上能编译但在错误的位置找东西。这条规则把这类路径挖出来提醒改用环境变量如AVEVA_DESIGN_EXE、CAF_ADDINS_PATH。$exts里的扩展名清单PML 侧的.pml / .pmlfnc / .pmlfrm / .pmlobj / .pmlmac / .pmlcmd与第三方 PML 语言服务扩展所支持的扩展名集合一致来源性质第三方资源说明非官方清单。覆盖这些扩展名是为了不漏掉宏文件和命令文件。break同一行只记第一条命中一行里同时命中多条规则时只记第一条否则命中清单会被噪声淹没。迁移清单的第一要求是能被人看完。结论 待验证所有命中一律初始化为待验证。这是刻意的机制设计不允许出现扫描完就直接标已改的流程因为扫描器只负责发现线索不负责判定正确性系列铁律 2。2.3 差异报表结构扫描产出只是原料要变成可执行的迁移计划还得加工成下面这张表文件行号命中类型命中原文建议动作风险等级结论验证记录…/ModelUtil.cs42旧数据库程序集Pdms.Database.dll查新环境是否存在同名/对应程序集高待验证—…/menu.uic8旧命令命名空间Aveva.Pdms.Presentation.PDMSCommands按线索试Aveva.Core.Commands再验证高待验证—…/report.pmlfnc15硬编码安装路径C:\Program Files\AVEVA…改用环境变量中待验证—三条填写纪律结论只能取四值已改、已验证未改、已废弃、待验证。大概改好了不是结论。验证记录必须写清怎么验的在哪台机器、哪个版本、用哪个操作、看到什么结果。风险等级允许上调不允许下调拿不准的往高放宁可多验一遍。2.4 迁移风险分级表等级特征处置高出现旧程序集名、旧命名空间、旧命令命名空间必须逐个在本机验证存在性后再改不允许批量替换中硬编码路径、版本号误标、注释里的旧信息可批量处理但改完要抽查低纯 PML 语法、无外部引用直接搬跑一遍原用例即可这张表的作用是分配时间把 80% 的验证精力放在高档上因为只有它会造成编译通过但运行期加载失败这类最难查的问题。2.5 回归测试用例设计#用例输入期望输出比对方式1数据巡检指定 ZONE元素清单名称类型与黄金样本逐行比对2批量改名已知命名冲突集改名前后对照表逐行比对3报表导出指定报表定义表格字段与行数字段名全等、行数相等4规则校验已知含缺陷样本FAIL清单失败集合完全相等5界面挂载从菜单/工具栏触发命令可执行且状态正确人工确认 日志一致性6装载验证冷启动一次Addin 与 PML Add-in 均加载日志中出现装载记录比对前必须做规范化剔除时间戳、路径、版本号统一换行符与大小写敏感度。否则比对结果全是噪声等于没比。三 常见报错与排查现象 1代码能编译但运行期报找不到程序集/无法加载类型。原因候选引用的旧程序集如Pdms.Database.dll、PDMSFilters.dll在新环境里根本不存在——这正是迁移的最大风险点。处置到本地 E3D Design 安装目录实际查找该程序集文件不存在就换用已确认存在的对应程序集如Aveva.Core.Database.dll、Aveva.Core.Database.Filters.dll改完重新编译并运行验证。不要用命名空间替换去猜程序集名。现象 2USING NAMESPACE报解析失败。原因候选写了部分命名空间。官方机制明确USING NAMESPACE string指定命名空间时大小写不敏感但不允许书写部分命名空间写父级命名空间再取子对象会报错。处置一次写全整条命名空间路径。迁移期特别容易犯这个错因为旧代码里的命名空间层级与新代码不同。现象 3PML 宏在新环境下什么都没做也不报错。原因候选一PML 错误机制——错误不会立即报错是否输出取决于下一行输入没有匹配的handle命令时错误表现会非常隐晦原因候选二宏依赖的某个命令/对象在新版本下语义不同。处置在关键步骤前后插心跳输出逐段缩小范围不要以没报错作为迁移成功的证据。现象 4.NET Addin 完全不加载界面上什么都没有。原因候选一装载配置文件名不对——每个 CAF 应用有各自的模块名Addins.xml例如 MODEL 对应DesignAddins.xml原因候选二文件位置不对默认与可执行文件同目录可用CAF_ADDINS_PATH覆盖支持;分隔多路径与 UNC 路径原因候选三程序集里没有实现IAddin的类CAF 是反射查找这样一个类不是靠配置声明。处置按上面三条逐一核对开发期打开AVEVA_CAF_TRACING看装载跟踪。现象 5界面挂上了但菜单/工具栏项点了没反应。原因候选.uic靠命令对象的Key关联若命令类构造函数里没有设置Key关联就断了系列铁律 5。处置确认命令类在构造时设置了Key且.uic中的键与之完全一致同时确认模块级模块名Customisation.xml已把该.uic列入注意其中的$1会被当前工程名替换。现象 6迁移文档里写着E3D 15.x。原因候选版本认知错误。15.x 是 AVEVA Engineering 的版本线不是 E3D Design 的。处置改为 E3D Design 3.1本系列基线同时用 2.1 脚本的版本号误标规则全文扫一遍把这类错误一并纠正。四 动手练习练习 1清点判定标准文件数与仓库对得上列出你的定制资产清单按三类PML / PML.NET / .NET Addin分组。判定标准每组文件数之和等于仓库内相关文件总数且每个文件都归属到某一组。练习 2扫描判定标准每条命中都有风险等级用 2.1 的脚本扫描你的仓库。判定标准输出的 CSV 中每行都有命中类型与风险等级且命中总数的分组统计能打印出来。练习 3逐个验证判定标准至少验证三条从命中清单里挑高档的三条到本地 E3D Design 环境逐个验证程序集是否存在、类型是否可用。判定标准三条都在验证记录列写明了机器、版本、操作与结果且结论只取四值之一。练习 4对照测试判定标准六条用例全部有结论按 2.5 的表格设计 6 条对照测试用例可以只用其中 3 条真正跑通。判定标准每条用例都有输入、期望输出与比对方式且比对前做过时间戳/路径规范化。练习 5纪律自查判定标准零批量替换检查你的迁移记录里有没有批量替换命名空间的操作痕迹。判定标准若存在必须能举证每一处的验证记录举证不出的一律改回待验证。五 小结与下一篇预告本篇三句话PDMS 自 2024 年 4 月 1 日起不再销售、不再提供支持迁移是必答题并行期是最好的验证窗口。三类资产迁移成本递增PML 是搬PML.NET 是改.NET Addin 是重建装载与界面两块都必须重验。官方没有命名空间迁移对照表社区说法只是线索——所以流程必须是扫描 → 分级 → 逐个验证扫描器只负责发现线索不负责判定正确性。到这里19 篇的技术件已经齐了语言PML1/PML2、界面Command UIC、数据DbElement、桥接PML.NET、出图报表、元件库、规则检查、应力对接、批量作业、迁移。但它们还是一堆散件。第 20 篇《收官项目E3D 二次开发工具箱》把它们组装成一个可运行的整体环境自检器、PML 代码库、命令与 UI 挂载、数据访问层、批量调度与日志、迁移自查器六个模块给出目录结构、模块职责、接口契约与上线检查清单并附一次完整的端到端运行记录其中的数值是占位真实值必须在你自己的机器上跑出来。文末 FAQFAQ 1PDMS 现在还能不能用迁移是必须的吗能用但官方口径是自 2024 年 4 月 1 日起PDMS 不再销售、不再提供支持研发投入全部转向 E3D Design。迁移路径包括本地或云端部署也可作为 AVEVA Unified Engineering 的一部分交付官方称 E3D Design 仍与 PDMS 后续版本兼容客户可以在两个平台并行推进PDMS 最终被淘汰。所以迁移是必答题只是时间早晚而在并行期内两侧都在正好可以用来做对照验证是最有利的迁移窗口。FAQ 2我的定制资产里哪些能直接搬哪些必须重写按三类看PML 宏/函数/表单.pmlfnc、.pmlfrm、.pmlobj迁移成本低语言层跨代延续性好重点是排查它引用了什么数据与命令PML.NET 程序集成本中等因为程序集名与命名空间换代加载与验证方式要重做.NET Addin成本最高因为除了程序集换代还要重做装载配置模块名Addins.xml与界面机制.uic与命令Key而界面机制正是官方指出旧式方式仍受支持但不推荐、与 command ribbon 不兼容的地方。一句话记法PML 是搬PML.NET 是改.NET Addin 是重建。FAQ 3旧程序集名在 E3D 里对应谁有官方对照表吗官方没有给出旧→新的命名空间/程序集迁移对照表。可核实的两代差异举例是PDMS 12.0 时代的Pdms.Database.dll、PDMSFilters.dll对应 E3D Design 3.1 侧可用的Aveva.Core.Database.dll、Aveva.Core.Database.Filters.dll。注意这两组并不是简单替换第二组多了.Database这一层说明一键替换的做法从一开始就站不住。正确做法是到本地 E3D Design 的安装目录里逐个确认程序集文件是否存在、类型是否可用并把验证结果登记成你自己的对照表。FAQ 4社区帖里的命名空间对应关系能直接用吗只能当线索。社区提到过Aveva.Pdms.PMLNet→Aveva.Core.PMLNet、Aveva.Pdms.Presentation→Aveva.Core.Presentation、Aveva.Pdms.Presentation.PDMSCommands→Aveva.Core.Commands来源性质是社区不是官方结论。使用纪律有四条不做批量替换只逐个替换逐个验证不写进项目规范规范里只写已验证存在的清单验证方式唯一——在本机安装目录确认程序集存在、并用反射或 IntelliSense 确认类型存在每验证一条就登记一条。另外真实代码里的Aveva.Pdms.*家族远比这三条多所以扫描器应先列出全部再逐条验证。FAQ 5迁移之后怎么证明行为没变做对照测试核心是同一批输入、同一套输出。三步一是在 PDMS 环境里把关键场景的输出元素清单、报表、日志保存为黄金样本二是在 E3D 环境里跑同一批输入与黄金样本逐行比对三是任何差异都必须判为预期内或缺陷之一不允许大致相同。比对前必须先规范化剔除时间戳、安装路径、版本号统一换行符。此外要特别提醒两句USING NAMESPACE必须一次写全、不允许写部分命名空间否则报解析失败PML 的错误不会立即报错是否输出取决于下一行输入所以没报错绝对不能当作迁移成功的证据。