runtime: `FormatterServices.GetUninitializedObject` replacement?
I’m author of FsPickler, a multi-format message serialization library intended as a replacement to BinaryFormatter. The focus of the library is serialization of closures, which means that I need to support things like subtyping and internal, compiler-generated classes that often have no accessible constructors or serialization attribute annotations.
I would be interested in porting FsPickler (and its father project, mbrace) to CoreCLR, however there are many obstacles, mostly related to deprecated APIs. The component I’m more concerned about is the FormatterServices.GetUninitializedObject
method which is used for instantiating objects without relying on a parameterless constructor. This is crucial for us since many closure types (particularly F# lambdas) do not come with such constructors.
Do you have any plans for replacing this with equivalent functionality?
/cc https://github.com/dotnet/corefx/issues/6564#issuecomment-212620200 https://github.com/dotnet/coreclr/issues/2715
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 15 (14 by maintainers)
FormatterServices.GetUninitializedObject()
is absolutely necessary for Orleans-generated serializers. Without it we’ll be entirely broken.FormatterServices.GetUninitializedObject has been added to .NET Core 1.2. Related discussion at https://github.com/dotnet/corefx/issues/8133.
Hi, While evaluating whether we could eventually build a port of Orleans that supports CoreCLR, I’ve done some tests with manually creating serializers for exceptions using the
FormatterServices.GetUninitializedObject
method (via reflection), and seems to unblock us for now. Compared to just having the binary formatter, we are of course constrained with what parts of the exceptions we can serialize, and also of non-Exception types we want to serialize too for inter grain communication. For now I’m only serializing a subset of the Exception fields, but that means custom properties from exceptions will not flow through in any kind of grain interaction (such as ParamName, or ErrorCode, or HttpStatus from different exception types). This is a limitation that I guess we can live with until we get proper support for serialization in .NET Core (as was announced post-RTM).In a nutshell, I’m serializing the following private fields from
System.Exception
using reflection:_className
,_innerException
,_message
,_remoteStackTraceString
,_stackTraceString
. This allows for some troubleshooting of remote logic, since this allows us to preserve the exception type and becauseException.ToString()
uses only those fields to print the exception details (unless of course a derived exception decides to override ToString). I only tested that this works in .NET Core RC2 running on Windows, but I’m not familiar whether accessing these private fields through reflection could cause issues in other platforms, could you guys validate?These are the relevant portions (without any extra optimizations, as this is not production code yet) of the steps I took to serialize exceptions in Orleans:
Just as FYI, this is in an exploratory branch I have here: https://github.com/jdom/orleans/blob/coreclr-multi/src/Orleans/Core/ExceptionSerializer.cs