Add missing type forwards #90669
Add missing type forwards #90669
Conversation
Fixes #90578 IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsFixes #90578 IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
|
|
/backport to release/8.0-rc1 |
|
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922 |
Do we need to add these (unused) types back for compat? |
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion. |
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change... |
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true. My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point. |
|
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types). |
|
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode |
|
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
|
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases. I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?". |
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled. |
|
I'm fine with that as well but regarding Jan's point above:
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others? |
BCN: dotnet/docs#36729 |
ghost
locked as resolved and limited conversation to collaborators
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.