Consider having fewer ways to represent GUID values

[kennykerr]

Language projection authors must deal with both Win32 and WinRT metadata. Not only does Win32 introduce GUID constants that are encoded as UTF16 string values, requiring string parsing and extra space for the fat UTF16 strings, but it uses a different GuidAttribute to the one that WinRT has used for years. I'm willing to live with the GUID string constants, as there are tradeoffs involved, but can we at least use a single form for GUID attributes?

WinRT interfaces use Windows.Foundation.Metadata.GuidAttribute while Win32/COM interfaces use System.Runtime.InteropServices.GuidAttribute. I don't mind so much that there are distinct attributes. The problem is that they encode the GUID values in different ways. The Win32 attribute uses a string representation while the WinRT attribute uses a sequence of integers. We can't change the WinRT attribute but can we at least use or introduce a GuidAttribute for Win32 that has the same constructor signature so that we can have fewer code paths for extracting GUID for interfaces?

[sotteson1]

To be fair, System.Runtime.InteropServices.GuidAttribute has been around a lot longer than Windows.Foundation.Metadata.GuidAttribute! The older one has always been used to attribute interfaces for COM interop in CLR languages. I wonder why WinRT didn't use the existing attribute.

[kennykerr]

Good question, I don't know. And while I'd be happy to standardize on that version, we can't change what WinRT uses but we can change what Win32 uses.

[AArnott]

I'll go along with whichever, although CsWin32 already parses the string one so sticking with status quo would be easier for me.

[timsneath]

I just ran into this today and had to rewrite my GUID code. Count me as a vote for consistency here.

As I hit more and more situations where Win32 metadata is a different "dialect" to WinRT metadata, I have to write special case code that is error-prone. I'm starting to think about whether I need a property on each typedef to explicitly annotate which dialect is being used...

[kennykerr]

Yes, it is quite tedious for those of us supporting both Win32 and WinRT. Glad I am no longer the only one. 😊

[sotteson1]

I've got a change coming that looks like this:

[Windows.Win32.Interop.Guid(821286010u, 25671, 4561, 142, 60, 0, 192, 79, 185, 56, 109)]
public interface IBlockingLock : IUnknown

I tried using Windows.Foundation.Metadata.GuidAttribute directly, but it derives from the .NETFramework version of Attribute, which then makes me pull in .NET 4 interop structs that clash with what I'm emitting. Hopefully using a new attribute with the WinRT constructor signature is ok.

[kennykerr]

Thanks that looks great!