PROPVARIANT (struct) usage fails with UseComSourceGenerators

[BernhardMarconato]

Actual behavior

COM interfaces that use PROPVARIANT or similar structs can not be used in a .NET JIT project, when CsWin32 is set to use CsWin32RunAsBuildTask and UseComSourceGenerators. A compiler error is raised:

unsafe void GetProperty(winmdroot.Foundation.PROPERTYKEY* key, out winmdroot.System.Com.StructuredStorage.PROPVARIANT ppropvar);

SYSLIB1051 Runtime marshalling must be disabled in this project by applying the 'System.Runtime.CompilerServices.DisableRuntimeMarshallingAttribute' to the assembly to enable marshalling this type. The generated source will not handle marshalling of parameter 'ppropvar'. For types that are not supported by source-generated COM, the resulting function pointer will rely on the underlying runtime to marshal the specified type.

Expected behavior

JIT (non-AOT) projects using CsWin32 with CsWin32RunAsBuildTask and UseComSourceGenerators can be used to generate COM interfaces using PROPVARIANT or similar structs without having to disable DisableRuntimeMarshallingAttribute for the entire assembly.

I understand this may be expected behavior right now, or due to limitations by .NET, but it would be nice if we didn't have to disable DisableRuntimeMarshallingAttribute for the entire assembly. Feel free to close the issue if this is not fixable.

Repro steps

1. NativeMethods.txt content:

IShellItem2

2. NativeMethods.json content (if present):

{
	"$schema": "https://aka.ms/CsWin32.schema.json",
	"comInterop": {"useComSourceGenerators": true}
}

3. Any of your own code that should be shared?
   none required

Context

• CsWin32 version: 0.3.217
• Target Framework: net8.0-windows10.0.26100.0
• CsWin32RunAsBuildTask = true

[jevansaks]

@jkoritzinsky this warning is from the GeneratedComInterface source generator. What's your recommendation for devs who want to use this mode of cswin32?

[jkoritzinsky]

I'd recommend one of the two following options:

1. If you're using the COM source generators, then you should be able to apply [DisableRuntimeMarshalling]. If you can't, then you might need to use that mode of CsWin32.
2. You could also project PROPVARIANT to object as long as the PROPVARIANT variants you support are the same as the built-in support (all primitives, IUnknown, IDispatch, strings, etc. No IRecord or SAFEARRAY support).
3. You could define your own custom marshaller to handle the cases you need, building on the ComVariantMarshaller type in the BCL.

The problem you're likely hitting is a bool, char, or otherwise non-blittable field somewhere in the PROPVARIANT defintion.

[jevansaks]

Oh is that what that error is trying to say? That this parameter is relying on runtime marshalling and we might not have intended that?

[jkoritzinsky]

The error is saying that we can't determine that the type is definitely blittable by the old blittable model (and will be at runtime), so you need to use [DisableRuntimeMarshalling] to switch to the new blittable model (where unmanaged == blittable). If you don't use it, then we assume that we can't marshal it and will generate code that falls back to the built-in marshalling model (mainly so you can copy the code and edit it if you don't want to use the generator to get it to work the rest of the way).

[jevansaks]

For now I'll document the recommendation that if you set UseComSourceGenerators=true then we require you to set DisableRuntimeMarshalling.

You can still use CsWin32RunAsBuildTask=true if you set UseComSourceGenerators=false and it will effectively behave as before but there are still advantages in that CsWin32 generated types are visible to other source generators.

[theoractice]

For now I'll document the recommendation that if you set UseComSourceGenerators=true then we require you to set DisableRuntimeMarshalling.

You can still use CsWin32RunAsBuildTask=true if you set UseComSourceGenerators=false and it will effectively behave as before but there are still advantages in that CsWin32 generated types are visible to other source generators.

I found that setting DisableRuntimeMarshalling can made DllImport functions fail to work when build with NativeAOT.
Things like

[DllImport("print.dll")]
private static extern int Print(IntPtr p, string text)

fails because string needs marshalling. Switching to LibraryImport works, but I have hundreds/thousands of DllImport to modify.
Any ideas? or am I doing something wrong?

[jevansaks]

I can look into the source generator mode supporting the scenario where DisableRuntimeMarshalling=false but the guidance from .NET is -- if you want to use Native AOT, you should disable runtime marshalling.