-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code Quality: SYSLIB1054 - Use CsWin32 instead of DllImportAttribute to generate p/invoke marshalling code at compile time. #15000
Comments
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. |
I like this idea. Feel free to work on it with @yaira2’s approval. |
Sounds good, it might be worth splitting this into multiple PRs to make it easier to test and review. |
Thanks for the initial try. |
Just checked about CsWin32, looks promising because of source generator usage like |
Don't know if this is expected behavior when migrating: |
I'm not sure, but this function in C language uses void*. #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 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. |
Now you can see Files.App.Helpers.Win32 Win32PInvoke class. We can replace them with CsWin32 piece by piece (starting from about 10 functions). |
Description
Related to https://learn.microsoft.com/en-us/dotnet/fundamentals/syslib-diagnostics/syslib1050-1069.
Concerned code
Example:
to
Gains
Requirements
Comments
No response
The text was updated successfully, but these errors were encountered: