runtime: PlatformNotSupportedException when attempting to serialize DirectoryInfo instance with Newtonsoft.Json

Cross-posting with https://github.com/JamesNK/Newtonsoft.Json/issues/1404 to demonstrate the pain this can cause with 3rd party libraries that have historically relied on this behavior vs simply removing the API which would bring attention to the problem immediately, instead of at runtime.

Please consider removing these APIs in the future

Source/destination types

System.IO.DirectoryInfo

Source/destination JSON

None/serialization fails.

Expected behavior

Serialization of the DirectoryInfo object to function how it works on .net 4.x

Actual behavior

Message: System.PlatformNotSupportedException : Operation is not supported on this platform.
at System.IO.FileSystemInfo.GetObjectData(SerializationInfo info, StreamingContext context)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeISerializable(JsonWriter writer, ISerializable value, JsonISerializableContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.Serialize(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonSerializer.SerializeInternal(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonConvert.SerializeObjectInternal(Object value, Type type, JsonSerializer jsonSerializer)
   at CSDiscordService.EvalTests.<JsonConvertOfDirectoryInfoObject>d__15.MoveNext() in C:\src\CSDiscord\CSDiscordService.Tests\EvalTests.cs:line 88
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Result Message:	System.PlatformNotSupportedException : Operation is not supported on this platform.

Appears to be related to a change made in the .net core implementation to no longer support serializing several types. https://github.com/dotnet/corefx/pull/20220

Steps to reproduce

PM> dotnet --info
.NET Command Line Tools (2.0.1-servicing-006924)

Product Information:
 Version:            2.0.1-servicing-006924
 Commit SHA-1 hash:  1ed6be56ca

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16257
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.1-servicing-006924\

Microsoft .NET Core Shared Framework Host
  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
var di = Directory.CreateDirectory("C:\\this\\doesnt\\exist");
var json = JsonConvert.SerializeObject(di);
Console.WriteLine(json);

Other Observations

SerializerSettings.Error = (s, e) => e.ErrorContext.Handled = true; does not handle this exception setting SerializerSettings.ContractResolver = new DefaultContractResolver { IgnoreSerializableInterface = true }; does not change this behavior

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 21 (16 by maintainers)

Most upvoted comments

@Cisien this probably isn’t the info you want to hear, but you see it’s a tradeoff- even where we had serialization implemented in earlier builds of .NET Core 2.0 , it wasn’t all working (and as you know it wasn’t in 1.x at all).

If a type (even DirectoryInfo) that we don’t serialize was heavily binary serialized in the .NET Framework world, and we get lots of feedback about that, we would certainly consider whether we should add it. But I recommend not using binary serialization for this – and 3rd party serializers that do binary serialization probably should catch PNSE and try some other scheme.