[release/7.0] Fix argument validation in RuntimeType.InvokeMember #75006
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.
Backport of #74998 to release/7.0
/cc @stephentoub
Customer Impact
Type.InvokeMember has historically allowed the member name argument to be null when specifying
BindingFlags.CreateInstance
, since in that caseActivator.CreateInstance
is used and the member name is ignored. But the overhaul earlier in the release to use!!
and then again to useArgumentNullException.ThrowIfNull
erroneously resulting in the null check for non-CreateInstance cases being moved earlier in the method. The net result is passing a null name withBindingFlags.CreateInstance
now throws an ArgumentNullException rather than successfully instantiating the object. This fixes that to put the throw back where it should have been.Testing
New automated test, plus all CI testing plus local runs of the reflection tests.
Risk
Minimal