Should we add a comment here that this is needed because the first argument is a REFGUID?

If I figured it out, so can anyone else. The signature of the native function isn't secret, after all. On the other hand, I would quite like it if all declarations of native functions had their full signature next to them.

The docs for LPStruct DO indicate that this should ONLY be used for REFGUID, but someone not familiar with that may not understand the connection between this type and GUID.

I have made a suggestion to use the in modifier instead.

To allow anyone not familiar with the subject to understand why the attribute is there, you'd have to include a treatise on calling conventions and how C weirdly came up with the idea of passing structs on the stack. Anything less than that just ends up as a string of the same words you are trying to explain.

Link to https://learn.microsoft.com/en-us/dotnet/standard/native-interop/best-practices#guids ? That is what you are referring to above, I believe. That sentence doesn't say "the only type in the whole world that LPStruct should ever be used with is Guid", but "of the various ways of declaring a Guid argument, LPStruct should be used only with the ref kind". (If I find the time, I'll try and improve the Guid section of that page. I find it very confusing.)

I have made a suggestion to use the in modifier instead.

Doesn't in just mean the argument is effectively const on the receiving end? I admit I have never used it, but it does not look to me like it also means to pass the thing as a pointer.

Doesn't in just mean the argument is effectively const on the receiving end? I admit I have never used it, but it does not look to me like it also means to pass the thing as a pointer.

Oh, I take that back.

I'll leave it to the experts to decide whether it's correct, though. My C# is far from good enough.