Issues with pruning - AddIns missing. #3972

Activity

1. marcschier

   changed the title [-]@opcfoundation-org With https://github.com/larws/repro-issue-3843 you can reproduce the issue I am talking about. I generated the code for your demo nodeset with the current model compiler version and added it to a server. With version 1.5.378.152 it does not work, the `AddIn` nodes are not visible. With version 1.5.378.145 the `BuildingBlock1` and `BuildingBlock2` nodes are visible in the address space.[/-] [+]Issues with pruning - AddIns missing.[/+] on Jul 9, 2026
2. marcschier

   assigned

   mrsuciu

   ,

   randy-armstrong

   and

   opcfoundation-org

   on Jul 9, 2026
3. marcschier

   added

   needs investigation

   on Jul 9, 2026
4. marcschier

   added the

   Bug

   issue type on Jul 9, 2026
5. romanett

   added

   1.5.378Only affects 1.5.378 (pre 2.0)Only affects 1.5.378 (pre 2.0)

   on Jul 9, 2026
6. marcschier

   added a sub-issue on Jul 9, 2026

   • Revert pruning change in master378 and release another maintenance release #3975
7. marcschier

   added

   bugA bug was identified and should be fixed.A bug was identified and should be fixed.

   codegenModelCompiler and source generation relatedModelCompiler and source generation related

   and removed

   needs investigation

   on Jul 23, 2026
8. marcschier

   modified the milestones: 2.0, 2.1 on Sep 8, 2026
9. biancode commented on Sep 30, 2026

   

   biancode

   on Sep 30, 2026

   Contributor

   More actions

   Status summary from the Machinery side, in case it helps to decide what is left here:

   • 1.5.378: the pruning from Prune extra decoded children that should stay on the type definition only. #3843 was reverted with Revert "Prune extra decoded children that should stay on the type defnition only. (#3843)" #3976 (sub-issue Revert pruning change in master378 and release another maintenance release #3975) and shipped in 1.5.378.156 and 1.5.378.176; with those, the BuildingBlock1/BuildingBlock2 AddIns of the repro are instantiated again.
   • master (2.0): the pruning was never ported, and the in-repo source generator emits ModellingRuleId on every generated child (Mandatory, Optional and the placeholder rules; an instance declaration can only promote the type's rule). So Mandatory AddIns would survive even if the pruning came to master later.
   • The Machinery SDK merged with Machinery: the OPC 40001 companion SDK with Jobs, Result Transfer, Process Values and Energy #4578 builds MachineryBuildingBlocks with its HasAddIn references on 2.0, and its tests browse them over a real session.

   What seems to remain is the ModelCompiler side for 1.5.378 (children emitted without a ModellingRuleId), which would have to be fixed before the pruning comes back to master378. If a regression test on master with the demo NodeSet from #3843 would help to close the 2.0 part, I can add one.
10. romanett commented on Sep 30, 2026

    

    romanett

    on Sep 30, 2026

    Contributor

    More actions

    The ModelCompiler side is addressed in OPCFoundation/UA-ModelCompiler#260.

    Root cause: ClearModellingRules removed the ModellingRuleId from a type's instance state and from all of its children. That instance state is emitted as the InitializationString of the generated class. Children without a strongly typed property, such as the BuildingBlock1/BuildingBlock2 AddIns below Identification, were therefore decoded as dynamic children without a modelling rule. The pruning from #3843 removes exactly those.

    Fix: only the instance's own modelling rule is cleared. The instance declarations below it keep their rules (Mandatory, Optional, placeholders). This matches what the 2.0 source generator already emits. With the repro NodeSet from https://github.com/larws/repro-issue-3843, the generated DemoMachineTypeState initializer now carries ModellingRuleId = i=78 for Identification, BuildingBlock1 and BuildingBlock2. A regression test covers this.

    Side effect: children of instances created from generated classes now expose HasModellingRule when browsed, as on 2.0.

    The PR also bumps the ModelCompiler's Opc.Ua.Core/Opc.Ua.Types references from 1.5.378.152 (no longer on nuget.org) to 1.5.378.176. Code generated with this change should be compatible with bringing the pruning back to master378.
11. opcfoundation-org

    closed this as completedon Oct 17, 2026