Fix: one OLE2FRAME with no payload throws away the whole document

[redbluevn]

The problem

CadOle2FrameTemplate.build recovers the frame's four corners by parsing the OLE2 payload, and builds a StreamIO over CadObject.BinaryData without checking there is one:

if (this.Chunks.Any())
{
    this.CadObject.BinaryData = this.Chunks.SelectMany(c => c).ToArray();
}

StreamIO reader = new StreamIO(CadObject.BinaryData);   // null here

AutoCAD's own DXF export writes an OLE2FRAME's geometry as XDATA — 1001 ACAD / 1000 OLEBEGIN / 1070+1040 pairs — and emits no binary chunk at all. So Chunks is empty, BinaryData stays null, and new MemoryStream(null) throws ArgumentNullException.

That exception comes out of CadDocumentBuilder.BuildDocument, so it is not one frame that is lost — it is the whole file. A drawing of 32,571 entities holding twenty OLE frames could not be read back from AutoCAD's own DXF export of it at all:

Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'buffer')
   at CSUtilities.IO.StreamIO..ctor(Byte[] arr)
   at ACadSharp.IO.Templates.CadOle2FrameTemplate.build(CadDocumentBuilder builder)
   at ACadSharp.IO.CadDocumentBuilder.BuildDocument()
   at ACadSharp.IO.DXF.DxfDocumentBuilder.BuildDocument()

The fix

Return early when there is no payload, or one too short for the block that follows (two bytes plus four points of three doubles), and notify rather than fail silently. The corners keep their defaults, which is all that can honestly be said when the data they come from is absent.

How it was found

By asking a question the round-trip census cannot: not "did we keep what we read" but "did we read what is there". Comparing a reading of a DWG against a reading of AutoCAD's DXF export of the same drawing crashed on the second half before it could compare anything.

Tests

Ole2FrameWithoutPayloadTests writes a real document, splices in an OLE2FRAME shaped the way AutoCAD writes one — subclass, flags, an OLE label, and no 310 anywhere — and asserts the rest of the document survives.

Worth noting how the first attempt at this test was useless: constructing an Ole2Frame in code and round-tripping it passed against the unfixed code, because the writer never emits an entity in that state. Only a fixture that reproduces AutoCAD's actual shape goes red. It does, with exactly the exception above.

dotnet test on this branch: 2314 passed / 17 failed, against master at 592d70a on this machine at 2313 / 17 — the same pre-existing failures, plus the one test added here.

Related

#1223-#1232, DomCR/CSUtilities#23.

[DomCR]

Tests not needed, you can remove it.

[redbluevn]

Done in 28cefb4 — test removed.

[DomCR]

This can be simplified, the Ole2Frame implementation is not complete right now, instead add an 'else' with a return.

[redbluevn]

Simplified in 28cefb4 — the length check and the notification are gone, and the guard is now an else that returns.

One detail worth flagging, since it is not quite a bare else: it reads else if (this.CadObject.BinaryData == null). The two readers fill BinaryData by different routes — the DXF reader collects the 310 chunks into Chunks (DxfSectionReaderBase.cs:1697), while the DWG reader assigns BinaryData directly and never touches Chunks (DwgObjectReader.cs, ReadBytes(dataLength)). A plain else { return; } would therefore skip corner parsing for every OLE2FRAME read from DWG. Happy to shape it differently if you prefer.

Checked the fix still holds without the test: a DXF whose OLE2FRAME carries no 310 chunk no longer throws ArgumentNullException out of BuildDocument. Suite 2313/2332 on this branch, the same 17 failures as upstream master.