terrafx.interop.windows
terrafx.interop.windows copied to clipboard
Add COM interface IID as public const string
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}"
.
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.
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. Attribute
s that take Guid
s 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.
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.
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.