[API Proposal]: Provide an `IUnknown` IID constant

[AaronRobinsonMSFT]

Background and motivation

The IUnknown interface ID (IID) is a well known constant that has been set since the early 90's. This IID can be used in a myriad of cases, particularly with the new COM source generator. This constant should be defined in a way that can be used both as a declaration on an interface definition and as a way to easily implement QueryInterface().

Additional IIDs that could also be considered:

• IID_IClassFactory
• IID_IClassFactory2

API Proposal

The suggestion is a Guid member, but this could be a string, ReadOnlySpan<byte> or another type the Guid constructor can take. Another consideration is the constructor for GuidAttribute, which takes a string.

namespace System.Runtime.InteropServices;

public abstract class ComWrappers
{
+    public static readonly Guid IID_IUnknown;
}

API Usage

Used as a constant when implementing QueryInterface().

Alternative Designs

Define an IUnknown interface type in C# and define the value using the GuidAttribute. This approach is unfortunately not AOT compatible.

Risks

None. This is a well known value and one that should be available.

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

Issue Details

---

Background and motivation

The IUnknown interface ID (IID) is a well known constant that has been set since the early 90's. This IID can be used in a myriad cases, particularly with the new COM source generator. This constant should be defined in a way that can be used both as a declaration on an interface definition and as a way to easily implement QueryInterface().

Additional other IIDs that should be considered:

• IID_IClassFactory
• IID_IClassFactory2

API Proposal

namespace System.Runtime.InteropServices;

public abstract class ComWrappers
{
+    public const Guid IID_IUnknown;
}

API Usage

// Fancy the value
var c = new MyFancyCollection<int>();
c.Fancy(42);

// Getting the values out
foreach (var v in c)
    Console.WriteLine(v);

Alternative Designs

Define an IUnknown interface type in C# and define the value using the GuidAttribute.

Risks

None. This is a well known value and one that should be available.

Author:	AaronRobinsonMSFT
Assignees:	-
Labels:	api-suggestion, area-System.Runtime.InteropServices
Milestone:	9.0.0

[AaronRobinsonMSFT]

@tannergooding Your thoughts would be much appreciated on this proposal.

[Sergio0694]

Would it be possible to expose these as a static ref readonly Guid property like in TerraFX? That'd make them more flexible and marginally improve perf (no static ctor, just reading straight from RVA fields). I'm aware that the approach TerraFX uses is technically Windows specific due to alignment concerns, but given this is for .NET 9 could that be something we could fix, so that it can be used reliably and cross-platform? 🤔

[AaronRobinsonMSFT]

marginally improve perf (no static ctor, just reading straight from RVA fields)

Do we have measurements that show this has a performance impact?

[Sergio0694]

I think Tanner has some, as he specifically had to remove them from TerraFX as they were piling up and causing a significant slowdown at startup (admittedly, he had thousands of those). Though to clarify, it's not just about performance, but also convenience, as having them return a ref readonly also means you can eg. pin and pass them by pointer, or pass them to a method taking in/ref readonly without needing to use a local temp.

[jkotas]

The IUnknown interface ID (IID) is a well known constant that has been set since the early 90's

The same can be said about number of other COM related constants that one needs for most real-world COM scenarios. (For example, the E_... error codes.)

Our principle so far was to expose the absolute minimum APIs required for specific higher level interop variants. This would be a start of exposing additional surface for convenience. Where would we stop?

[jkotas]

Alternative Designs
Define an IUnknown interface type in C# and define the value using the GuidAttribute.

The COM interop packages out there use several different patterns:

• ref readonly Guid returning property in static class IID: https://github.com/terrafx/terrafx.interop.windows/blob/fadce5a41fa5e6f0282e80e96f033d0a2c130991/sources/Interop/Windows/Windows/um/Unknwnbase/IID.cs#L15
• interface IComIID with static property that returns the Guid: https://github.com/microsoft/CsWin32/blob/990484777aa161aebf62ee02ba457b2f5f8286cc/src/Microsoft.Windows.CsWin32/Generator.Com.cs#L1039-L1042

[AaronRobinsonMSFT]

The same can be said about number of other COM related constants that one needs for most real-world COM scenarios. (For example, the E_... error codes.)

That is fair about the entire HRESULT surface area, but in .NET we have exceptions that encapsulate those ideas (for example, Exception.HResult). There is nothing in .NET that attempts to encapsulate the bare minimum of a COM server. This means base class identifiers like IUnknown, IClassFactory and IClassFactory2 are helpful. An argument could be made the class factory IIDs are unnecessary and that does make sense. The IUnknown though comes up and will continue to come up as we lean more in COM source generation.

I see an argument for this being the only IID we provide.

[jkotas]

I do not see a problem with the COM interop source generator embedding own private copy of the IUnknown Guid in the shape that it finds convenient. The COM interop source generator needs to embed many Guids and other constants, saving it from embedding one less Guid does not move the needle.

[AaronRobinsonMSFT]

saving it from embedding one less Guid does not move the needle.

I don't think this is about moving a needle or trying to address some monumental short coming. The point of this was merely to handle the case because almost every COM interop library makes this define, it is systemic almost across all libraries, see terrafx or WinForms, when doing something outside of or low-level with the built-in COM system. Providing the most fundamental identifier in the entire COM system would appear to be a simple yet convenient constant for those who want to build one up. Even on the ComWrappers API we provide the functions to implement IUnknown, the option to override IUnknown, yet not how to say IUnknown.

[jkotas]

CsWin32 (used by WinForms) and Terrafx have IID_IUnknown naturally auto-generated just like any other IID. I do not expect that the BCL definition would be of much use for them.

I can see that the BCL definition can be useful for manual bespoke IUnknown implementations, like the one in dotnet/performance#3298 (comment) that motivated this issue. If the convenience of bespoke IUnknown implementations is the scenario, we may also want to expose other constants that are always needed for that: S_OK, E_NOINTERFACE and layout of IUnknown vtable.