Bugfix :: Fix F# exception serialization to preserve fields by T-Gro · Pull Request #19342 · dotnet/fsharp

T-Gro · 2026-02-20T16:09:02Z

Fixes F# exceptions losing their field values during serialization.

Fixes Serialization of F#-defined exception variants doesn't serialize fields #878

Exceptions with fields now emit a GetObjectData override and a deserialization constructor that save/restore the fields via SerializationInfo, enabling correct ISerializable roundtrips.

Note: This fix is primarily relevant for users targeting .NET Framework 4.x or .NET Core ≤7, where BinaryFormatter / ISerializable serialization is still available. On .NET 8+, StreamingContext is removed and the serialization members are not emitted. The entire ISerializable infrastructure is deprecated (SYSLIB0051) — no modern serializer (System.Text.Json, DataContractSerializer, etc.) uses GetObjectData.

FSharp.Core exception caveat: FSharp.Core has [assembly: SecurityTransparent], which on .NET Framework prevents overriding the SecurityCritical method Exception.GetObjectData. FSharp.Core exceptions (e.g. MatchFailureException) therefore get only the base-call deserialization constructor (status quo) but not the GetObjectData override. This is tested explicitly. User-defined exceptions are unaffected — they get full serialization support.

github-actions · 2026-02-20T16:09:46Z

❗ Release notes required

✅ Found changes and release notes in following paths:

Change path Release notes path Description

src/Compiler docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

T-Gro · 2026-02-20T19:24:30Z

/azp run fsharp-ci

azure-pipelines · 2026-02-20T19:24:43Z

Azure Pipelines successfully started running 1 pipeline(s).

abonie · 2026-03-23T16:53:14Z

An edge case, but now this causes a runtime crash due to field name collision with Exception.GetObjectData keys

open System
open System.Runtime.Serialization

exception Foo of Message:string


let e = Foo("hello")
let info = SerializationInfo(e.GetType(), FormatterConverter())
let ctx = StreamingContext(StreamingContextStates.All)
e.GetObjectData(info, ctx)

T-Gro · 2026-03-27T08:59:06Z

Good catch! Fixed in 234f944 — serialization keys now use the backing field name (e.g. "Message@" instead of "Message"), which is guaranteed unique due to the @ suffix from CompilerGeneratedName. This avoids the collision with keys written by base.GetObjectData.

Added a dedicated test (Issue_878_ExceptionSerialization_MessageFieldCollision) that exercises exactly your repro scenario and verifies the roundtrip succeeds.

T-Gro · 2026-03-27T12:07:41Z

/azp run fsharp-ci

azure-pipelines · 2026-03-27T12:07:53Z

Azure Pipelines successfully started running 1 pipeline(s).

abonie · 2026-03-30T09:36:31Z


-    let events = eventsWhen events (received Finished)
+    // Wait for all 10 outdated jobs to be canceled and the new one to finish.
+    let events = eventsWhen events (fun e -> countOf Canceled e = 10 && countOf Finished e = 1)


Is this related to the rest of the PR?

abonie

What happens if exception is serialized with an older compiler and deserialized with one that has these changes? If it's not going to work then perhaps this should be marked as a breaking change? Or not because it wasn't working before either?

abonie · 2026-03-30T09:59:58Z

+                    let securityCriticalAttr =
+                        mkILCustomAttribute (g.attrib_SecurityCriticalAttribute.TypeRef, [], [], [])
+
+                    mdef.With(customAttrs = mkILCustomAttrs [ securityCriticalAttr ])


Should this also have CompilerGenerated and DebuggerNonUserCode attributes?

Fixes #878 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The generated GetObjectData override on F# exception types must have the [SecurityCritical] attribute to match the security accessibility of Exception.GetObjectData on .NET Framework. Without this, the CLR rejects the override with 'Inheritance security rules violated', causing FS0193 errors when any project references FSharp.Core (which contains MatchFailureException with the new GetObjectData override). Also update IL baselines and FSharp.Core surface area baseline. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

FSharp.Core has [assembly: SecurityTransparent] which makes all methods transparent. On .NET Framework, transparent methods cannot override SecurityCritical methods (Exception.GetObjectData) nor call SecurityCritical base constructors (Exception(SerializationInfo, StreamingContext)). Skip emitting serialization members for FSharp.Core exceptions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…, add test FSharp.Core has [assembly: SecurityTransparent]. On .NET Framework, transparent code cannot override SecurityCritical methods (GetObjectData). Without GetObjectData to write fields, the field-restoring ctor would crash. So for FSharp.Core exceptions: - Keep the base-call-only deserialization ctor (status quo, SecuritySafeCritical base) - Skip GetObjectData override (can't override SecurityCritical from transparent) For user exceptions (no SecurityTransparent): - Emit both GetObjectData and field-restoring ctor (full serialization) Add test verifying FSharp.Core MatchFailureException: - Loads without TypeLoadException - Has deserialization ctor - Does NOT have GetObjectData override Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The compilingFSharpCore guard skips GetObjectData, so the surface area baseline should not include it for MatchFailureException. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ctors Add deserialization constructor bodies (reading fields from SerializationInfo) and GetObjectData overrides to match the netcore baselines. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Changed eventsWhen condition in 'Cancel running jobs with the same key' test to wait until all 10 outdated jobs are canceled and the new job finishes, instead of stopping at the first Finished event. This prevents race conditions where assertions run before all cancellations complete. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…issue #18411) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Use IL backing field name (with @ suffix) as the serialization key instead of the property name. This prevents duplicate key crashes when an F# exception field name collides with a key already used by Exception.GetObjectData (e.g., 'exception Foo of Message:string'). The backing field name (e.g., 'Message@', 'Data0@') is guaranteed to not collide with base Exception serialization keys. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Add Issue_878_ExceptionSerialization_MessageFieldCollision test that reproduces the exact edge case where an F# exception field named 'Message' collides with Exception.GetObjectData's 'Message' key. The test verifies: - GetObjectData does not throw with duplicate key - F# field is serialized under backing field name 'Message@' - Base Exception's 'Message' key remains accessible - Full serialization roundtrip preserves the field value Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- Eliminate ilBaseOnlyCtorInstrs/ilBaseOnlyCtor block that duplicated ilInstrsForSerialization/ilCtorDefForSerialization by introducing shouldRestoreFields flag - Simplify 3-branch if/elif/else to 2-branch conditional - Remove unused ilPropName parameter from emitSerializationFieldIL callback Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…yIL list Replace the duplicated getActualIL helper and Assert.Contains call with a proper IL fragment in the verifyIL list, verifying the AddValue callvirt instruction is emitted in the GetObjectData method. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…rt unrelated AsyncMemoize fix - Add [CompilerGenerated] and [DebuggerNonUserCode] attributes to the generated serialization constructor and GetObjectData override on exception types, matching the pattern used by other compiler-generated methods in IlxGen. - Update verifyIL test to check for the new attributes. - Update all EmittedIL baselines (Nullness, SerializableAttribute) for both netcore and net472, debug and release configurations. - Revert unrelated AsyncMemoize flaky test fix (not part of this PR scope). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-project-automation Bot added this to F# Compiler and Tooling Feb 20, 2026

T-Gro requested a review from abonie February 20, 2026 16:09

github-project-automation Bot moved this to New in F# Compiler and Tooling Feb 20, 2026

T-Gro force-pushed the codegen/fix-exception-serialization branch 3 times, most recently from c9b17c0 to f6f7424 Compare February 20, 2026 17:31

T-Gro force-pushed the codegen/fix-exception-serialization branch 2 times, most recently from 675d541 to 4b0a72e Compare February 20, 2026 19:29

T-Gro marked this pull request as ready for review March 6, 2026 11:46

T-Gro requested a review from a team as a code owner March 6, 2026 11:46

T-Gro changed the title ~~WIP :: Bugfix :: Fix F# exception serialization to preserve fields~~ Bugfix :: Fix F# exception serialization to preserve fields Mar 6, 2026

T-Gro force-pushed the codegen/fix-exception-serialization branch from 1b2f39a to 2debec9 Compare March 27, 2026 02:42

T-Gro requested review from abonie and removed request for abonie March 27, 2026 13:58

abonie reviewed Mar 30, 2026

View reviewed changes

abonie approved these changes Mar 30, 2026

View reviewed changes

github-project-automation Bot moved this from New to In Progress in F# Compiler and Tooling Mar 30, 2026

T-Gro force-pushed the codegen/fix-exception-serialization branch 5 times, most recently from 773eba0 to d485a32 Compare April 20, 2026 14:20

Fix F# exception serialization to preserve fields

053ad37

Fixes #878 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

T-Gro and others added 14 commits April 21, 2026 08:34

Revert surface area baseline: no GetObjectData on FSharp.Core exceptions

566a9a8

The compilingFSharpCore guard skips GetObjectData, so the surface area baseline should not include it for MatchFailureException. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Move release notes to 11.0.100

e43e937

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Retrigger CI: sole failure was known flaky test AsyncMemoize.Cancel (…

39923ae

…issue #18411) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fix Fantomas formatting in GenExnDef serialization ctor

a95e61c

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

T-Gro force-pushed the codegen/fix-exception-serialization branch from d485a32 to bb46647 Compare April 21, 2026 06:34

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bugfix :: Fix F# exception serialization to preserve fields#19342

Bugfix :: Fix F# exception serialization to preserve fields#19342
T-Gro wants to merge 15 commits intomainfrom
codegen/fix-exception-serialization

T-Gro commented Feb 20, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Feb 20, 2026 •

edited

Loading

Uh oh!

T-Gro commented Feb 20, 2026

Uh oh!

azure-pipelines Bot commented Feb 20, 2026

Uh oh!

abonie commented Mar 23, 2026

Uh oh!

T-Gro commented Mar 27, 2026

Uh oh!

T-Gro commented Mar 27, 2026

Uh oh!

azure-pipelines Bot commented Mar 27, 2026

Uh oh!

abonie Mar 30, 2026

Uh oh!

abonie left a comment

Uh oh!

abonie Mar 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

T-Gro commented Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

❗ Release notes required

Uh oh!

T-Gro commented Feb 20, 2026

Uh oh!

azure-pipelines Bot commented Feb 20, 2026

Uh oh!

abonie commented Mar 23, 2026

Uh oh!

T-Gro commented Mar 27, 2026

Uh oh!

T-Gro commented Mar 27, 2026

Uh oh!

azure-pipelines Bot commented Mar 27, 2026

Uh oh!

abonie Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

abonie left a comment

Choose a reason for hiding this comment

Uh oh!

abonie Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

T-Gro commented Feb 20, 2026 •

edited

Loading

github-actions Bot commented Feb 20, 2026 •

edited

Loading