Fix issue with ABI delegates in collections for .NET Standard projection #1330
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.
Our .NET Standard embedded projection can be used with both .NET core and .NET Framework. But it seems our generic collection types runs into issues with the latter due to using
Expression.GetDelegateType
to generate custom delegates withvoid*
parameters doesn't seem to be supported there. To address that, in our .NET Standard projection, we are now code generating all the ABI delegates that we can detect as being needed while generating the projection. This is then used by the collection types for when they need the delegate via a lookup mechanism. There is a fallback toExpression.GetDelegateType
which handles the scenario where we couldn't detect a certain ABI delegate is needed and didn't generate it as the WinRT boundary takes the value as anobject
. .NET Core users would be handled via that fallback, but .NET Framework users would see an error. In those cases, there is a way for the app to declare their own ABI delegates and register them if needed.