StandardDocumentModel UpdateGeneralApiNode NRE

[JohannesSchaeufeleJse]

Am encountering the following error with various versions, including 2026.1.20

SHFB: Error BE0065: BUILD FAILED: Object reference not set to an instance of an object.
   at Sandcastle.Core.PresentationStyle.StandardDocumentModel.UpdateGeneralApiNode(ApiMember memberNode) in C:\GH\SHFB\SHFB\Source\SandcastleCore\PresentationStyle\StandardDocumentModel.cs:line 319
   at Sandcastle.Core.PresentationStyle.StandardDocumentModel.ApplyDocumentModel(String reflectionDataFile, String docModelReflectionDataFile) in C:\GH\SHFB\SHFB\Source\SandcastleCore\PresentationStyle\StandardDocumentModel.cs:line 159
   at SandcastleBuilder.MSBuild.BuildEngine.BuildProcess.Build() in C:\GH\SHFB\SHFB\Source\SandcastleBuilderMSBuild\BuildEngine\BuildProcess.cs:line 1017

Adjusting UpdateGeneralApiNode in StandardDocumentModel.cs with a consistent type null checks and apiMembers ContainsKey checks and patching Sandcastle.Core.dll fixes the issue for me.

[EWSoftware]

Can you supply the fixes you made or an example to reproduce it? Without an example or more details, I'm just guessing about the actual cause.

[JohannesSchaeufeleJse]

Can you supply the fixes you made or an example to reproduce it? Without an example or more details, I'm just guessing about the actual cause.

@EWSoftware
The actual projects are quite large and not something I can share here. They use both .NET Framework and .NET 5+ (Framework projects as base, other ones added via version builder).
Specifically, the first exception occurs with typeNode.Node.Element("elements") which can evaluate to null
typeNode.Node evalutes to something like (replaced some specific values)

<api id="T:Some.Name.Space.SomeType">
  <topicdata group="api" />
  <apidata name="SomeType" group="type" subgroup="interface" />
  <typedata visibility="public" abstract="true" serializable="false" />
  <implementors>
    <type api="T:Some.Name.Space.OtherType1" ref="true" />
    <type api="T:Some.Name.Space.OtherType2" ref="true" />
    <type api="T:Some.Name.Space.OtherType3" ref="true" />
  </implementors>
  <containers>
    <library assembly="Some.Name.Space" module="Some.Name.Space" kind="DynamicallyLinkedLibrary">
      <assemblydata version="MAJOR.MINOR" />
    </library>
    <namespace api="N:Some.Name.Space" />
  </containers>
  <versions>
    <versions name="SHFB_VBPI_Lbl_FOR_NET10">
      <version name="SHFB_VBPI_DifferentHashes" />
      <version name="SHFB_VBPI_DifferentHashes" />
      <!-- and more versions -->
    </versions>
    <versions name="SHFB_VBPI_Lbl_FOR_NET_FRAMEWORK">
      <version name="SHFB_VBPI_DifferentHashes" />
      <version name="SHFB_VBPI_DifferentHashes" />
      <!-- and more versions -->
    </versions>
  </versions>
</api>

This started happening after some of the projects (part of the versions) were switched from .NET 8 to .NET 10. It only occurs for very few types, all of them interfaces (all of which are empty for .NET 10 via defines and have members for .NET Framework - but this was also already the case for .NET 8 and it was not a problem there).

The absolute minimal change I could make to have it work in the specific scenario was

diff --git a/SHFB/Source/SandcastleCore/PresentationStyle/StandardDocumentModel.cs b/SHFB/Source/SandcastleCore/PresentationStyle/StandardDocumentModel.cs
index 3082966f..6e100ba7 100644
--- a/SHFB/Source/SandcastleCore/PresentationStyle/StandardDocumentModel.cs
+++ b/SHFB/Source/SandcastleCore/PresentationStyle/StandardDocumentModel.cs
@@ -318,8 +318,8 @@ public class StandardDocumentModel : IApplyDocumentModel
         var typeNode = apiMembers[type.Attribute("api").Value];
         string overloadId = DetermineOverloadId(typeNode, memberNode);
 
-        if(typeNode.Node.Element("elements").Elements("element").Any(
-          el => el.Attribute("api").Value == overloadId))
+        if(typeNode.Node.Element("elements")?.Elements("element").Any(
+          el => el.Attribute("api").Value == overloadId) ?? false)
         {
             memberData.Add(new XAttribute("overload", overloadId));
         }

[JohannesSchaeufeleJse]

Also think I have now figured out why this dormant issue came up now: .NET 10 sorts lexicographically before .NET 8, which means our .NET 10 version is now sorted first and used as the base version (rather than the .NET Framework version).
@EWSoftware: Is there a way to keep the version labels the same, but still have the lexicographically larger version be used as the base version (such that the base version can be kept the same, while still being able to choose label names freely)?

[EWSoftware]

The sort on the framework label is in ascending order but within the same label, versions are sorted in descending order. It's a requirement of the version builder plug-in noted in the comments though I don't recall the details or if it really is necessary anymore. I plan on implementing proper platform/Applies To section support in a future release which would replace the version builder plug-in for cases like this where your documenting supported platforms and it would support multi-targeted or a mix of projects natively. That will be a while though.