Remove serialization support in DynamicProxy #512
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stakx
force-pushed
the
retire-dynamicproxy-serialization
branch
3 times, most recently
from
a55d4e1
to
479a937
Compare
|
I won't get time to review this PR today, quite a lot to look at. Did you want to submit your first bullet point to clean up exceptions (and maybe one other commit to fix a ifdef) as a separate pull request so we can get those in. |
This was referenced Jun 15, 2020
stakx
force-pushed
the
retire-dynamicproxy-serialization
branch
from
479a937
to
09c5f9b
Compare
|
I did as you suggested and moved some things into separate PRs. The one for the incorrect compilation symbol is already merged, it was trivial and you've got enough boring conditional symbol obliteration PRs to review as it is. 😆 |
Those tests will now fail. Change two of them to document that proxy types are now no longer made serializable.
stakx
force-pushed
the
retire-dynamicproxy-serialization
branch
from
09c5f9b
to
a1dac2c
Compare
|
Let's close this... at least for the time being. If we really do want to remove serialization support, we can always reactivate this PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am making this a draft to prevent accidental merging (although it's mostly ready); after all, we haven't decided yet whether to keep or retire serialization support in DynamicProxy. Until that time, consider this an "exploration" to help us better understand serialization in DynamicProxy.
This PR is perhaps best reviewed commit by commit, for the following reason:
#501 (comment) gave a summary of the different usages of
FEATURE_SERIALIZATIONin DynamicProxy, and appears to have been largely correct. I used it as a guideline to "undo" serialization from DynamicProxy, in the following order:Make all exception types serializable across all targets.(Update: Moved into a separate PR Make all exception types serializable #515.)Change DynamicProxy so generated proxy and invocation types are no longer serializable. (
Those two kinds of generated types cannot be easily done piecemeal because they share a common base class,Incorrect: Invocation type generators ultimately subtypeBaseProxyGenerator.IGenerator<T>, notBaseProxyGenerator.)Finally, abandon
LoadAssemblyIntoCacheand get rid of the requirement that "supporting types" (hooks, interceptors, interceptor selectors, mixins) should be made serializable.The net result is that DynamicProxy code no longer makes use of
FEATURE_SERIALIZATION—the remaining usages are inside DictionaryAdapter and the logging facility.Closes #367.