Skip to content

Conversation

@brianrob
Copy link
Member

Implements a set of breaking changes for FastSerialization.

Highlights:

  • SerializationSettings are now required when creating a stream for use with FastSerialization.
  • All non-primitive types must be registered with Deserializer before they can be deserialized. Failure to do so will cause the deserialization operation to fail.

More Details:

  • Rename SerializationConfiguration to SerializationSettings and make it a required parameter when creating a stream for use with FastSerialization.
  • Make SerializationSettings read-only once passed into a reader or writer implementation by cloning the object whenever a setting is changed.
  • Move StreamReaderAlignment from an optional parameter to reader constructors to a property on SerializationSettings.
  • All non-primitive types must be registered with Deserializer before they can be deserialized. Failure to do so will cause the deserialization operation to fail. Registration can occur via a call to Deserializer.RegisterType or Deserializer.RegisterFactory.
  • Deserializer also supports on-the-fly registration of types and factories via the Deserializer.OnUnregisteredType event.
  • Removed Deserializer.RegisterDefaultFactory and Deserializer.TypeResolver in favor of Deserializer.OnUnregisteredType which allows for type resolution and factory creation to be performed in one place instead of two.

 - Require an instance of SerializationSettings for serializers and
   deserializers.
IStreamWriter to allow writers to directly create readers.
usres can't change the set of allowed types after it is set and handed
to the deserialization code.
Remove the ability for FastSerialization to create arbitrary types that
are specified in serialized files.  Instead, force users to register all
types before or during serialization.  Types can be registered via calls
to Deserializer.RegisterType and Deserializer.RegisterFactory.  Users
can also implement Deserializer.OnUnregisteredType to handle
unregistered types encountered during deserialization.  It is incumbent
on the implementor to not just blindly call Type.GetType in
OnUnregisteredType, and instead only create known types.
provide enough context to find the right assembly.
return ret;
}

internal Func<IFastSerializable> GetFactory(string fullName)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GrabYourPitchforks, you will be most interested in the changes to GetFactory.

Copy link
Collaborator

@cincuranet cincuranet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some small nits and comments. Overall LGTM.

@brianrob
Copy link
Member Author

brianrob commented Nov 5, 2024

Thanks @cincuranet. I have made all of the suggested changes.

@cincuranet cincuranet merged commit a358962 into microsoft:main Nov 5, 2024
@brianrob brianrob deleted the dev/brianrob/serialization-type-list branch November 6, 2024 00:36
wiktork added a commit to dotnet/diagnostics that referenced this pull request May 5, 2025
Code updates are based on
microsoft/perfview#2121

Would like to incorporate
microsoft/perfview#2180 into dotnet-monitor, to
potentially improve memory usage.

~~Test failures are most likely due to changes from
microsoft/perfview#2170 Fixed with newest
version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants