CsWin32 usage sample #7929
CsWin32 usage sample #7929
Conversation
This is a draft to drive the conversation around utilizing CsWin32 in WPF. In it I've converted SplashScreen to use CsWin32 and directly utilize WIC pointers. This is informed by WinForms transition and utilizes some of the code, notably ComScope and IID. There is more support code that WinForms uses that eases handling of COM situations, including providing ComWrapper based "CCWs" for managed classes. WinForms also contains other patterns for scoping handles, handling GC keep-alive scenarios, and managing agiile COM pointers and VARIANT interop. As CsWin32 types Win32 typedefs (such as HWND, and HRESULT) it can get very awkward to exchange these if you use CsWin32 directly in multiple assemblies in the assembly graph. As such I created a new shared assembly for the interop code. I added a batch file to simplify Visual Studio in the right context (copied from WinForms). Choices here were expedient and made with the goal of illustrating how to do this. I have not tested anything outside of ensuring compilation works.
ghost
assigned 
ghost
requested review from
|
cc: @dipeshmsft, @AArnott, @lonitra |
|
If the interop assembly can be built for x86, x64, and arm64 that avoids an AnyCpu issue with CsWin32 that we're working on. I don't really have a handle on how things are packaged/deployed so I don't know how easy that is to accomplish. The basic issue is that some Win32 APIs are not technically AnyCPU friendly. More specifically this has to do with some struct definitions. The fields in the struct lay out the same way on x86/x64, but packing would cause the structs to not be aligned correctly when contained in other structs. In internal usage this doesn't really come up- we've always been able to write PInvokes in WinForms for AnyCPU. There is an ask on CsWin32 to be able to make an "unsafe" ask for a given platform projection for these cases. None of this hits this initial PR. The notable place this comes up is in some of the shell APIs which define with a PACK=1. |
| <!-- | ||
| We don't care about CLS compliance since everything here is internal and we want to match native types. | ||
| --> | ||
| <NoWarn>$(NoWarn);CS3016</NoWarn> |
There was a problem hiding this comment.
💡 Applying [assembly: CLSCompliant(false)] will disable this warning and disable CLS compliance analysis which significantly improves compiler performance.
| <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.3.5-beta"> | ||
| <PrivateAssets>all</PrivateAssets> | ||
| <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> | ||
| </PackageReference> |
There was a problem hiding this comment.
| <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.3.5-beta"> | |
| <PrivateAssets>all</PrivateAssets> | |
| <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> | |
| </PackageReference> | |
| <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.3.5-beta" PrivateAssets="all" /> |
| /// <para> | ||
| /// Take care to NOT make copies of the struct to avoid accidental over-release. | ||
| /// </para> |
There was a problem hiding this comment.
💡 Roslyn's [NonCopyable] can be used for this
There was a problem hiding this comment.
Can you provide more information on where this attribute is defined and which analyzer package needs to be installed to leverage it?
There was a problem hiding this comment.
It's part of Roslyn.Diagnostics.Analyzers today:
https:/dotnet/roslyn-analyzers/blob/main/src/Roslyn.Diagnostics.Analyzers/Core/AbstractDoNotCopyValue.cs
It's fairly unforgiving. Any use of a non-copyable value which doesn't match a known non-copying value will produce a diagnostic. It also relies on IOperation, so I'm not sure if it handles all cases where a piece of syntax doesn't have IOperation support. In practice, it's worked well for us with minimal hassle.
There was a problem hiding this comment.
I'll look into it, thanks.
src/Microsoft.DotNet.Wpf/src/System.Windows.Primitives/Windows/Win32/Foundation/ComScope.cs
Show resolved
Hide resolved
src/Microsoft.DotNet.Wpf/src/System.Windows.Primitives/Windows/Win32/Foundation/ComScope.cs
Show resolved
Hide resolved
src/Microsoft.DotNet.Wpf/src/System.Windows.Primitives/Windows/Win32/Foundation/ComScope.cs
Show resolved
Hide resolved
src/Microsoft.DotNet.Wpf/src/System.Windows.Primitives/Windows/Win32/Foundation/ComScope.cs
Show resolved
Hide resolved
This is a draft to drive the conversation around utilizing CsWin32 in WPF. In it I've converted SplashScreen to use CsWin32 and directly utilize WIC pointers.
This is informed by WinForms transition and utilizes some of the code, notably ComScope and IID. There is more support code that WinForms uses that eases handling of COM situations, including providing ComWrapper based "CCWs" for managed classes.
WinForms also contains other patterns for scoping handles, handling GC keep-alive scenarios, and managing agiile COM pointers and VARIANT interop.
As CsWin32 types Win32 typedefs (such as HWND, and HRESULT) it can get very awkward to exchange these if you use CsWin32 directly in multiple assemblies in the assembly graph. As such I created a new shared assembly for the interop code.
I added a batch file to simplify Visual Studio in the right context (copied from WinForms).
Choices here were expedient and made with the goal of illustrating how to do this. I have not tested anything outside of ensuring compilation works.
Microsoft Reviewers: Open in CodeFlow