Handle CoCreateable classes in ComSourceGenerators mode

[jevansaks]

COM source generators do not handle co-classes, you have to manually call CoCreateInstance. Per my proposal in #1500, I am making CsWin32 generate a class that looks like this:

[Guid("00021401-0000-0000-C000-000000000046")]
internal partial class ShellLink
{
    [Obsolete("Use CreateInstance<T> method instead.")]
    public ShellLink() { throw new NotSupportedException("Use CreateInstance<T> method instead."); }

    public static T CreateInstance<T>() where T : class
    {
        PInvoke.CoCreateInstance<T>(typeof(ShellLink).GUID, null, CLSCTX.CLSCTX_SERVER, out T ret).ThrowOnFailure();
        return ret;
    }
}

So the consumer would write code like this instead:

// BEFORE - ComInterop:
var shellLink = new ShellLink();
var shellLinkW = (IShellLinkW)shellLink;

// AFTER - ComSourceGenerators:
var shellLinkW = ShellLink.CreateInstance<IShellLinkW>();

One downside is this means it's hard to write consuming code that uses co classes and flips between the two modes. The problem is, in ComImport mode, you can't have any methods on the class so we'd have to hide the factory method somewhere else which makes it less discoverable for the COM generators. In a future change we can use the "extension everything" .NET 10 feature to make this available in both modes.

I also generated a CreateInstance<T> for allowMarshaling=false mode because ... why not? The signature of the method returns HRESULT because it has to return a pointer out param. But this fixes #1422.

Fixes #1422, #1500.

[JeremyKuhne]

Have you considered just making the class a static class?

[Guid("00021401-0000-0000-C000-000000000046")]
internal partial static class ShellLink
{
    public static T CreateInstance<T>() where T : class
    {
        PInvoke.CoCreateInstance<T>(typeof(ShellLink).GUID, null, CLSCTX.CLSCTX_SERVER, out T ret).ThrowOnFailure();
        return ret;
    }
}

Also, does it need to generic?

One other thing to consider is putting these statics on the actual interfaces when you're constrained to your <DisableRuntimeMarshalling> scenario:

namespace Windows.Win32.UI.Shell;

public unsafe partial interface IShellLinkW
{
    public static Guid ClassGuid => new("00021401-0000-0000-C000-000000000046");

    public static IShellLinkW CreateInstance()
    {
        PInvoke.CoCreateInstance(ClassGuid, null, CLSCTX.CLSCTX_SERVER, out IShellLinkW ret).ThrowOnFailure();
        return ret;
    }
}

Having the helpers hanging off the interface might improve discovery. You could also include the static class as well to get people looking for it both ways?

[jevansaks]

Have you considered just making the class a static class?

I'm hoping to find a syntax that could work for both ComImport mode and not. ComImport has the constraint that class must be empty, so that does have me wondering if there should be a special static factory class somewhere else, where it could be static.

One other thing to consider is putting these statics on the actual interfaces when you're constrained to your scenario:

Unfortunately the declaration of coclass in win32metadata doesn't tell you anything other than the class name and GUID. What interfaces are associated with it is not described. So there's no way to know IShellLinkW would be the right interface.

Also with this approach you can ask for any interface on the thing, like: ShellLink.CreateInstance<IPersistFile>() would work too.

[JeremyKuhne]

Unfortunately the declaration of coclass in win32metadata doesn't tell you anything other than the class name and GUID. What interfaces are associated with it is not described. So there's no way to know IShellLinkW would be the right interface.

Bummer, might be a nice addition in the future.

[jevansaks]

Have you considered just making the class a static class?

Also, being a class with constructor that I can mark Obsolete will help folks find the new pattern when migrating from ComImport to GeneratedComInterface mode, so I think I'll stick with this pattern.

With .NET 10 I can do "extension everything" to make this a static extension method even on the ComImport type so folks can use same syntax before/after.

[AaronRobinsonMSFT]

    PInvoke.CoCreateInstance<T>(typeof(ShellLink).GUID, null, CLSCTX.CLSCTX_SERVER, out T ret).ThrowOnFailure();

This is a fine approach, but there is a slightly more AOT friendly manner.

[Guid("00021401-0000-0000-C000-000000000046")]
internal partial static class ShellLink
{
    private static ReadOnly<byte> CLSID_ShellLink = /* 00021401-0000-0000-C000-000000000046 as a byte array */;

    ...

    public static T CreateInstance<T>() where T : class
    {
        PInvoke.CoCreateInstance<T>(new Guid(CLSID_ShellLink), null, CLSCTX.CLSCTX_SERVER, out T ret).ThrowOnFailure();
        return ret;
    }
}

This is more pay-for-play. If a user does typeof(ShellLink).GUID, then metadata is kept via reflection, but if not then the additional metadata can be removed and the cost is only a simple read only byte array.

[jevansaks]

This is more pay-for-play.

If no one calls CreateInstance, won't the trimmer see it's uncalled and also remove the reference to typeof(ShellLink).GUID and thus realize it doesn't need to keep metadata? Or is the determination of what metadata to keep made before trimming?

[jevansaks]

But I'm ok with adding a static. Is there a reason the static should be ReadOnlySpan and then construct the GUID in the function versus the static is:

private static Guid CLSID_ShellLink => new Guid(0x00021401, 0x0000, 0x0000, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46);

?