jaredpar
commented
7 years ago Unfortunately the reasoning listed in #3528 is still valid. Our core assemblies must target .NET Standard and serialization is not supported in .Net Standard 1.1 (our current target). Hence there isn't really much of a decision for us to make here, it's simply not an option.
The serialization question is being reconsidered for Net Standard 2.0. If serialization is included in Net Standard 2.0 I imagine we'll mark our exceptions as serializable at that point.
jasonmalinowski
jcouv
Since collectible assemblies don't exist yet, it's absolutely guaranteed repeated execution of scripts will create out of memory exceptions. The only solution at this time is to create a separate app domain to execute Roslyn's script engine and unload the app domain after execution completes. Since none of the exceptions in Roslyn's code base are marked as serializable, they each have to be manually wrapped or flattened to push them across the app domain boundary. This is a huge pain point and create loss of fidelity in exceptions, especially since many of them have protected internal constructors and cannot be directly wrapped. This also violates the principle of least surprise given all other exceptions in the .NET framework are marked as serializable. I recognize the notion of serializable does not exist in .NET Core but if that's the justification to use compiler directives to mark them when building against 4.6, it suggests there's very limited value in producing Roslyn for 4.6 at all until collectible assemblies are supported. This issue was brought up in #3528 but dismissed. Please reconsider this decision.