ILSpy

9645 Commits

54 Branches

94 Tags

91 MiB

Branch: fix/lambda-parameter-syntax

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	5343d849d4	Revive BAML decompiler tests as two projects and run them in CI The BAML tests were orphaned: in no solution, no CI, and missing their ICSharpCode.BamlDecompiler reference. Revive them split by platform, mirroring ILSpy.Tests / ILSpy.Tests.Windows: ILSpy.BamlDecompiler.Tests (net11.0) holds platform-agnostic tests - including a regression test that decompiles with the WPF assemblies hidden, covering the missing-assembly fix - and ILSpy.BamlDecompiler.Tests.Windows (net11.0-windows) holds the WPF round-trip cases that compile XAML into BAML. Single-TFM projects keep normal lock files; the Windows one declares all RIDs so its lock is generatable and verifiable on any host. Wire the cross-platform project into ILSpy.sln, ILSpy.XPlat.slnf and ILSpy.Desktop.slnf so it builds and runs on the Linux/macOS legs; the Windows project stays in ILSpy.sln (its tests execute in the Windows leg). The Windows job also archives that assembly, whose embedded BAML lets the decompiler be exercised against real BAML on a host without WPF. Assisted-by: Claude:claude-opus-4-8:Claude Code	2 months ago
Christoph Wille	3f32d4a5e9	Harden BAML reader against crafted-resource crashes Browsing an embedded .baml resource runs it through BamlReader.ReadDocument, whose post-parse defer pass walks the record list with NavigateTree. That walk recursed on every nested StaticResourceStart/KeyElementStart record with no depth cap and indexed the record list with no bound. A crafted resource could therefore drive recursion into a StackOverflowException -- which is uncatchable and kills the process despite the resource node's try/catch -- or walk the index off the end of the list. Both are reachable from ordinary resource browsing, no project export required. Consolidate the duplicated defer walk into one bounded, depth-capped helper that fails with a catchable InvalidDataException, so the existing UI catch turns a malformed resource into a "BAML decompilation failed" message instead of a crash. Reject an oversized signature length before it drives a multi-gigabyte allocation (it is read before the MSBAML check), and resolve defer offsets with TryGetValue so a bogus offset reports malformed data rather than escaping as a bare KeyNotFoundException. Assisted-by: Claude:claude-opus-4-8:Claude Code	3 months ago

Author

SHA1

Message

Date

Siegfried Pammer

5343d849d4

Revive BAML decompiler tests as two projects and run them in CI

The BAML tests were orphaned: in no solution, no CI, and missing their
ICSharpCode.BamlDecompiler reference. Revive them split by platform,
mirroring ILSpy.Tests / ILSpy.Tests.Windows: ILSpy.BamlDecompiler.Tests
(net11.0) holds platform-agnostic tests - including a regression test that
decompiles with the WPF assemblies hidden, covering the missing-assembly
fix - and ILSpy.BamlDecompiler.Tests.Windows (net11.0-windows) holds the
WPF round-trip cases that compile XAML into BAML. Single-TFM projects keep
normal lock files; the Windows one declares all RIDs so its lock is
generatable and verifiable on any host.

Wire the cross-platform project into ILSpy.sln, ILSpy.XPlat.slnf and
ILSpy.Desktop.slnf so it builds and runs on the Linux/macOS legs; the
Windows project stays in ILSpy.sln (its tests execute in the Windows leg).
The Windows job also archives that assembly, whose embedded BAML lets the
decompiler be exercised against real BAML on a host without WPF.

Assisted-by: Claude:claude-opus-4-8:Claude Code

2 months ago

Christoph Wille

3f32d4a5e9

Harden BAML reader against crafted-resource crashes

Browsing an embedded .baml resource runs it through BamlReader.ReadDocument,
whose post-parse defer pass walks the record list with NavigateTree. That walk
recursed on every nested StaticResourceStart/KeyElementStart record with no
depth cap and indexed the record list with no bound. A crafted resource could
therefore drive recursion into a StackOverflowException -- which is uncatchable
and kills the process despite the resource node's try/catch -- or walk the index
off the end of the list. Both are reachable from ordinary resource browsing, no
project export required.

Consolidate the duplicated defer walk into one bounded, depth-capped helper that
fails with a catchable InvalidDataException, so the existing UI catch turns a
malformed resource into a "BAML decompilation failed" message instead of a crash.
Reject an oversized signature length before it drives a multi-gigabyte allocation
(it is read before the MSBAML check), and resolve defer offsets with TryGetValue
so a bogus offset reports malformed data rather than escaping as a bare
KeyNotFoundException.

Assisted-by: Claude:claude-opus-4-8:Claude Code

3 months ago

1 Commits (fix/lambda-parameter-syntax)