Add COM interface IID as public const string

[Rick Brewster]

For example:

[Guid(ID2D1Factory.IIDString)]
public struct ID2D1Factory : ID2D1Factory.Interface
{
    public const string IIDString = "06152247-6F50-465A-9245-118BFD3B6007";
}

This would allow me to not need my own const string definitions of these guids, which helps power my code generator, and a few corner cases at runtime where I need to map from a wrapper interface Type to its associated native COM IID:

[NativeInterfaceID(Direct2D1InterfaceID.ID2D1Factory)]
[PreferDerivedInterface(typeof(IDirect2DFactory1))]
public interface IDirect2DFactory
    : IObjectRef
{
}

// I could remove this class
internal static class Direct2D1InterfaceID
{
    public const string ID2D1Factory = "06152247-6f50-465a-9245-118bfd3b6007";
}

I may be able to rewrite my code to not need the string representation, but it's still useful for applying attributes that use Guids. You need a compile-time constant, which means a string.

For my purposes, the format of the guid doesn't matter, whether it's "06152247-6F50-465A-9245-118BFD3B6007" or "{06152247-6F50-465A-9245-118BFD3B6007}".

[Tanner Gooding]

Is there any reason you can't just pull it from the existing [Guid()] attribute? It's available via typeof(T).GUID or just directly querying the attribute off the type from metadata.

[Rick Brewster]

I can certainly change my NativeInterfaceID attribute to just NativeInterface and have it take a Type instead of a Guid. This would work for me.

In the general sense, I still feel not having the string constrains the ability to work with these Guids in .NET code. Attributes that take Guids require a compile-time constant, so unfortunately a string is required. However, I don't know of a specific scenario that actually needs this right now.

[Tanner Gooding]

Could you elaborate on if you're working with these via build time or runtime?

For build time, I'd expect that simply typeof(T).GUID or looking up the attribute via reflection (if its a reflection only load of the assembly) should be fine. It's not the fastest, but you're likely also not under a constraint for the literal fastest resolution of these.

For runtime, I could certainly see it being appropriate to remove that cost, but I'd like to better understand the scenario if its this one.

I don't have an issue with exposing such a string, and I don't think it would actually cost anything to do so, but I would like to understand the underlying reason why a string is needed here.

[Rick Brewster]

This might still be useful, and should be fairly straightforward to add to the codegen, but it's not something I need right now. I'll add more comments if I find that I need this.