native-interop | Native Interoperability | Wrapper library

Never mind, I got it worked out.

For anyone who might care, my F# code worked with just a couple of changes:

1. I changed UnmanagedType.LPStr to UnmanagedType.ByValTStr
2. In the extern function declaration, I decorated HomeQuery[] queries with [] (i.e. []HomeQuery[] queries).

That's all.

Regarding the .NET standard, I may be wrong but I think this is not applicable here because the COM interop stuff are at a higher level than the one .NET standard is targeting; we can only talk about either .NET Core or .NET Framework for COM interop.

If you want to generate a type library, you have few options.

By far, the easiest method is just to use .NET Framework. The fact that you are wanting to create a type library negates the advantages of .NET Core already because several COM, especially the "Automation" features are Windows-only. Using framework will be fine at least until .NET Core 5 comes out.

That said, if you have a business reason for using .NET Core but still need COM support, including the type library, then based on this GitHub comment, you should be able to compile your own IDL. Note that requires you to install C++ build tools because the MIDL compiler is not really a standalone thing that you can get without the rest of the C++ build tools.

It is strongly suggested to have had read the documentation on how .NET Core handles COM activation.

Assuming having the C++ build tools is not a barrier for you, the steps would be the following:

1) Create a .idl file that defines all your COM interfaces in the IDL format. That requires some translation between the .NET interface and the COM interface. Here's a partial example of how you'd need to translate between your C# interface and COM interface as defined in IDL:

Windows uses UTF-16 LE character encoding internally¹. When you call the ANSI version of a Windows API, the system will convert the input to UTF-16 (using the calling thread's current code page), call into the Unicode version, and convert the output back to ANSI encoding. This is both needlessly costly as well as lossy: not every Unicode string can be represented using ANSI encoding. The conversion also imposes arbitrary size limitations on input and output buffers (CreateFileA limits the file name length to 260 ANSI code units).

With this in mind you will want to make sure to always call the Unicode version of the Windows API. This provides maximum performance on all supported versions of Windows, as well as guards against loss of information when converting from Unicode to ANSI. Whether you use CharSet.Auto and MarshalAs(UnmanagedType.LPTStr) or CharSet.Unicode and MarshalAs(UnmanagedType.LPWStr) amounts to the same², and is a matter of personal preference. Microsoft recommends being explicit, i.e. explicitly name the Unicode version (CreateFileW) and specify Unicode encoding as well as wide character string types (the 3rd option in your question).

¹ With the exception of Windows 95/98/ME, collectively referred to as Win9x. None of them are officially supported.

² CharSet.Auto "chooses between ANSI and Unicode formats at run time, based on the target platform", so it isn't identical to CharSet.Unicdoe in theory. However, all supported platforms use Unicode encoding in practice.

if you using 1.9.854 or above,

you can now use string in :require

PInvoke is for C methods only but since the Objective C runtime is based on C methods, we can use them. Xamarin would provide all the necessary setup and convenience method but this is possible. Note that this example uses unsafe code and thus needs the following property set in the csproj file: