Remove the TypeKey concept as the primary user for the concept is unable to use it effectively. by jkoritzinsky · Pull Request #79418 · dotnet/runtime

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

jkoritzinsky · 2022-12-08T21:07:43Z

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

…ble to use it effectively.

ghost · 2022-12-08T21:07:50Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Previously, each of the interface types for the vtable stub generator was generic on a type T to represent a type key. The T types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example IIDs in COM, without interfering with each other or requiring using reflection-based types like System.Type.

However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the IUnmanagedVirtualMethodTableProvider<T> implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the System.Type instance without causing additional problems.

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-System.Runtime.InteropServices`, `source-generator`
Milestone:	-

jkoritzinsky · 2023-01-19T01:09:35Z

Failures were #79874

elinor-fung · 2023-01-19T01:17:14Z

-The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`.
+The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs.
+
+Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems.


nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?

I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.

…ble to use it effectively. (dotnet#79418)

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Remove the TypeKey concept as the primary user for the concept is una…
9233f3d
…ble to use it effectively.

jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Dec 8, 2022

jkoritzinsky requested review from AaronRobinsonMSFT, elinor-fung and jtschuster December 8, 2022 21:07

ghost assigned jkoritzinsky Dec 8, 2022

build-analysisBot mentioned this pull request Dec 9, 2022
System.Tests.ArrayTests.CreateInstance test failing in NativeAOT #79403
Closed

AustinWise reviewed Dec 13, 2022
View reviewed changes

Comment threaddocs/design/libraries/ComInterfaceGenerator/VTableStubs.md Outdated

Update design doc
1679787

build-analysisBot mentioned this pull request Jan 3, 2023
emcc received SIGKILL #79874
Closed

AaronRobinsonMSFT approved these changes Jan 19, 2023
View reviewed changes

jkoritzinsky merged commit 170587e into dotnet:mainJan 19, 2023

elinor-fung reviewed Jan 19, 2023
View reviewed changes

mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
Remove the TypeKey concept as the primary user for the concept is una…
e06a702
…ble to use it effectively. (dotnet#79418)

ghost locked as resolved and limited conversation to collaborators Feb 18, 2023

jkoritzinsky deleted the no-typekey branch March 22, 2024 01:25

Uh oh!

Conversation

jkoritzinsky commented Dec 8, 2022

Uh oh!

ghost commented Dec 8, 2022

Uh oh!

Uh oh!

jkoritzinsky commented Jan 19, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

jkoritzinsky commented Dec 8, 2022

Uh oh!

ghost commented Dec 8, 2022

Uh oh!

Uh oh!

jkoritzinsky commented Jan 19, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

jkoritzinsky commented Dec 8, 2022

Uh oh!

ghost commented Dec 8, 2022

Uh oh!

Uh oh!

jkoritzinsky commented Jan 19, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

jkoritzinsky commented Dec 8, 2022

Uh oh!

ghost commented Dec 8, 2022

Uh oh!

Uh oh!

jkoritzinsky commented Jan 19, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects