Update dependency Microsoft.Windows.CsWin32 to 0.3.253

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
Microsoft.Windows.CsWin32	0.3.228 -> 0.3.253

---

Release Notes

Microsoft/CsWin32 (Microsoft.Windows.CsWin32)

v0.3.253

Changes:

• #​1557: Improve intellisense experience with CsWin32RunAsBuildTask mode

This list of changes was auto generated.

v0.3.252

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.

v0.3.250

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.

v0.3.248

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.

v0.3.242

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.

v0.3.238

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.

v0.3.236

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

v0.3.235

What's Changed

• Handle CoCreateable classes in ComSourceGenerators mode by @​jevansaks in microsoft#1502
• Simplify decimal conversions by @​jevansaks in microsoft#1512
• Prevent SafeHandle from being re-generated in downstream assembly by @​jevansaks in microsoft#1514
• Fix ArithmeticOverflow in HANDLE types and other helpers when CheckForOverflowUnderflow is enabled by @​jevansaks in microsoft#1513

Full Changelog: microsoft/CsWin32@v0.3.228...v0.3.235

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[AArnott]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).