Code Quality: Replace Vanara with CsWin32

[gumbarros]

Description

We're working on utilizing Native Aot in the application, however, runtime marshaler is one of the blocker against this. Vanara uses loads of runtime marshaler via DllImport and ComImport and we're working on replacing it with CsWin32, ultimately removing its reference completely.

Concerned code

• Vanara references
• DllImport we explicitly use within the codebase

Gains

• AoT compliant codebase
• Less 3rd party references

Requirements

• Replace DllImport with CsWin32

Comments

CsWin32 requires you to add interfaces, functions, constants, enums, snd etc in NativeMethods.txt placed in Files.App.CsWin32. #define'd constants also need to be written in that text file and use like "PInvoke.CMF_DEFAULT" (They don't get placed in a particular namespace).
For more info, download ILSpy and win32metadata.winmd in order to see the full projections.

[gumbarros]

https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke-source-generation

Another reference explaining the benefits. I think this is an important issue.

[0x5bfa]

I like this idea. Feel free to work on it with @yaira2’s approval.

[yaira2]

Sounds good, it might be worth splitting this into multiple PRs to make it easier to test and review.

[0x5bfa]

Thanks for the initial try.
Do you know CsWin32?
If you know, you can replace them with API generated by CsWin32.
Using DllImport or LibraryImport is deprecation in Files app because we plan to use CsWin32 instead of those code and Vanara.

[gumbarros]

Just checked about CsWin32, looks promising because of source generator usage like LibraryImportAttribute. Will make a try tonight at NativeFindStorageItemHelper.cs

[gumbarros]

Don't know if this is expected behavior when migrating:
microsoft/CsWin32#1167

[0x5bfa]

I'm not sure, but this function in C language uses void*.
I assume that whether adding in or out and even ref is defined in win32metadata or CsWin32 repo.

#include <fileapifromapp.h>

WINSTORAGEAPI HANDLE FindFirstFileExFromAppW(
  LPCWSTR            lpFileName,
  FINDEX_INFO_LEVELS fInfoLevelId,
  LPVOID             lpFindFileData, // HERE
  FINDEX_SEARCH_OPS  fSearchOp,
  LPVOID             lpSearchFilter,
  DWORD              dwAdditionalFlags
) noexcept;

---

You can use Marshal.PtrToStructure:

using System.Runtime.InteropServices;

Marshal.PtrToStructure((nint)lpFindFileData, typeof(WIN32_FIND_DATA));

---

And you don't need to migrate all of inside of NativeFindStorageItemHelper because it would make us unreviewable so why not migrate step by step.
Also, if you're struggling with some issues you can skip, or you can pick functions up from Win32PInvoke that I made in my PR #15075 after merged because I gathered methods into single file and I think it's a good play ground as well for you.