SerializationGuard bloats the binary size on NAOT #87470
Comments
|
Related #44369. Noticed it after I changed the title to be more general last minute. I'm more concerned about the |
danmoseley
added
the
linkable-framework
|
Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr, @marek-safar Issue DetailsCurrently when calling The
|
|
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsCurrently when calling The
|
Can we at least introduce a feature switch to allow people who do not want to pay for the serialization guard overheads to opt-out of it? |
I'd be in favor of deleting it entirely, especially with BinaryFormatter disabled by default in most workloads and scheduled for extinction. Short of that, a feature switch in the meantime makes sense. Could we not just use the existing one for BinaryFormatter to also guard the guard? |
|
Per #44369 (comment) this is also used in deserialization of DataTable so it's not BinaryFormatter only. Looks like users can configure DataSet/DataTable deserialization to be a binaryformatter-like security nightmare. I wonder whether that mode should also be obsoleted together with BinaryFormatter. |
Use `UnsafeAccessor` instead of a delegate. Shrinks the size of a `PublishAot` app that just `Process.Start`s a new process from 2.2 MB to 1.7 MB. It's still half a MB bigger than what I would expect but now it's `Process`'s fault (the `ToString()` brings some serious amount of garbage and we can't practically trim `ToString`). Fixes dotnet#87470.
ghost
added
the
in-pr
Use `UnsafeAccessor` instead of a delegate. Shrinks the size of a `PublishAot` app that just `Process.Start`s a new process from 2.2 MB to 1.7 MB. It's still half a MB bigger than what I would expect but now it's `Process`'s fault (the `ToString()` brings some serious amount of garbage and we can't practically trim `ToString`). Fixes #87470.
ghost
removed
in-pr
ghost
locked as resolved and limited conversation to collaborators
Currently when calling
Process.Startit brings the whole reflection stack with it even when theSwitch.System.Runtime.Serialization.SerializationGuard.AllowProcessCreationis specified. This adds about 1MB to the final binary size.The
SerializationGuardseems to use reflection internally to retrieve the switch here which ends up rooting the reflection stack. It would be nice if the whole reflection guard concept would be possible to trim away on NAOT.The text was updated successfully, but these errors were encountered: