Changes:

• #1593: Fix IDispatch property returns with built-in COM
• #1591: Update README.md & add sample snippets
• #1589: Add [Optional] on optional params

This list of changes was auto generated.

Changes:

• #1545: Generate struct wrapper around function pointer to make a native delegate typedef
• #1578: Update win32metadata to latest (68.0.4-preview)

This list of changes was auto generated.

Changes:

• #1575: Fix bug when multiple Span-params share a CountParamIndex and one param is null
• #1567: Fix mis-handling of parameters that are arrays of HANDLE
• #1565: Switch CsWin32RunAsBuildTask to EmitSingleFile by default (for VS incremental scenario)
• #1562: Move to .NET 10 SDK, add test coverage for net10 TFM

This list of changes was auto generated.

Changes:

• #1557: Improve intellisense experience with CsWin32RunAsBuildTask mode

This list of changes was auto generated.

Changes:

• #1550: Support $(ProjectName).NativeMethods.txt pattern for single-file-app projects
• #1555: Downgrade dependencies so the source analyzer works with .NET 8 SDK again

This list of changes was auto generated.

Changes:

• #1554: Translate VARIANT to ComVariant when using COM source generators
• #1548: Add common Win32 message parameter extraction macros

This list of changes was auto generated.

Changes:

• #1544: Improve optional out interface arguments (e.g. IWbemServices.GetObject) and other minor tweaks
• #1547: Add test for cross-winmd IInspectable derivation and fix a tiny bug
• #1541: Don't emit friendly overload of Span param for flexible array structs
• #1536: Handle struct returns for COM interface methods across all marshalling modes
• #1534: Preserve pointer return types
• #1533: Fix out ** pointer parameters

This list of changes was auto generated.

Changes:

• #1524: Add an option to FriendlyOverloads to request previous pointer overloads
• #1526: Generate real IDispatch when requested
• #1522: [Retained] parameters need to project as pointer
• #1521: Add implicit IntPtr casts to void* typedefs

This list of changes was auto generated.

Changes:

• #1520: Don't make void* params Span in friendly methods
• #1517: CsWin32Generator should allow newer language versions

This list of changes was auto generated.

NOTE: This changes the signature of methods with optional parameters. This change is also documented at https://microsoft.github.io/CsWin32/docs/getting-started.html:

Optional out/ref parameters

Some parameters in win32 are [optional, out] or [optional, in, out]. C# does not have an idiomatic way to represent this concept, so for any method that has such parameters, CsWin32 will generate two versions: one with all ref or out parameters included, and one with all such parameters omitted. For example:

// Omitting the optional parameter:
IsTextUnicode(buffer);

// Passing ref for optional parameter:
IS_TEXT_UNICODE_RESULT result = default;
IsTextUnicode(buffer, ref result);

Working with Span-typed and MemorySize-d parameters

In the Win32 APIs there are many functions where one parameter is a buffer (void* or byte*) and another parameter is the size of that buffer. When generating for a target framework that supports Spans, there will be overloads of these functions that take a Span<byte> which represents both of these parameters, since a Span refers to a chunk of memory and a length. For example, an API like IsTextUnicode has a void* parameter whose length is described by the iSize parameter in the native signature. The CsWin32 projection of this method will be:

BOOL IsTextUnicode(ReadOnlySpan<byte> lpv, ref IS_TEXT_UNICODE_RESULT lpiResult)

Instead of passing the buffer and length separately, in this projection you pass just one parameter. Span is a flexible type with many things that can be converted to it safely. You will also see Span parameters for things that may look like a struct but are variable sized. For example, InitializeAcl looks like it returns an ACL struct but the parameter is annotated with a [MemorySize] attribute in the metadata, indicating it is variable-sized based on another parameter. Thus, the cswin32 projection of this method will project this parameter as a Span<byte> since the size of the parameter is variable:

// The cswin32 signature:
static BOOL InitializeAcl(Span<byte> pAcl, ACE_REVISION dwAclRevision) { ... }

And you would call this by creating a buffer to receive the ACL. Then, after the call you can reinterpret the buffer as an ACL:

// Make a buffer
Span<byte> buffer = new byte[CalculateAclSize(...)];
InitializeAcl(buffer, ACE_REVISION.ACL_REVISION);

// The beginning of the buffer is an ACL, so cast it to a ref:
ref ACL acl = ref MemoryMarshal.AsRef<ACL>(buffer);

// Or treat it as a Span:
Span<ACL> aclSpan = MemoryMarshal.Cast<byte, ACL>(buffer);

CsWin32 will also generate a struct-typed parameter for convenience but this overload will pass sizeof(T) for the length parameter to the underlying Win32 API, so this only makes sense in some overloads such as SHGetFileInfo where the parameter has an annotation indicating it's variable-sized, but the size is only ever sizeof(SHFILEINFOW):

// Span<byte> overload:
static nuint SHGetFileInfo(string pszPath, FILE_FLAGS_AND_ATTRIBUTES dwFileAttributes, Span<byte> psfi, SHGFI_FLAGS uFlags)
// ref SHGETFILEINFOW overload:
static nuint SHGetFileInfo(string pszPath, FILE_FLAGS_AND_ATTRIBUTES dwFileAttributes, ref SHFILEINFOW psfi, SHGFI_FLAGS uFlags)

Changes:

• #1511: Improve projection of MemorySize-d and optional ref/out parameters