-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Start using CsWin32 #7392
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
Start using CsWin32 #7392
Conversation
Using the CsWin32 PInvoke library Converted these threads: -DuplicateHandle -GetCurrentProcess -GetCurrentThread -GetCurrentThreadId Fixed the VB files to allow the new Windows.Win32 namespace Fixed the information messages in Application.ThreadContext
|
cc: @AArnott |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
|
|
||
| <ItemGroup> | ||
| <PackageReference Include="Microsoft.Win32.SystemEvents" Version="$(MicrosoftWin32SystemEventsPackageVersion)" /> | ||
| <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.2.1-beta"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't specify versions explicitly in proj files, the versions need to be specified in eng/versions.props (writing from memory on a phone)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll change that.
|
Could you please elaborate why CsWin32 was chosen? Thank you |
@RussKie this is a prototype effort to examine the viability of using CsWin32. It isn't "chosen" yet. As a general goal, we want to be using the Win32 metadata for our interop. CsWin32 is the only usable existing projection. We're working in conjunction with the .NET interop team and @AArnott to identify issues and opportunities based on this exploration. |
|
Awesome. Is there an associated issue to keep track of progress and associated issues? Happy to help where I can. I have made a NativeMethods.txt list of all User32 PInvokes. With a list that long, I think the NativeMethods.txt needs to be split up. I have based my effort off of the example given by @AArnott in #4751. |
|
Thank you @elachlan for your interest. IIUIC this is an internal experiement run by @fernandanavamoya, and we don't have a definite commitment to this conversion just yet. That said, if you already have made some progress in this area as well and are willing to share it or wish to come along for the ride, we won't say no. With your help we may be able to take the experiement further and/or decide sooner whether the codebase will benefit from this conversion. Though a compulsary disclaimer that this work may get abandoned, if something doesn't pan out or proves to be too difficult. I'll let @fernandanavamoya and @JeremyKuhne to chime in, but you can open a PR targeting feature/win32 branch we can take it from there. |
@elachlan Yes, I imagine that would be a long list. If you really wanted that, you could just do |
|
@AArnott yes, I should have said "all User32 PInvokes used in winforms". |
Using the CsWin32 PInvoke library Converted these threads: -DuplicateHandle -GetCurrentProcess -GetCurrentThread -GetCurrentThreadId Fixed the VB files to allow the new Windows.Win32 namespace Fixed the information messages in Application.ThreadContext
Using the CsWin32 PInvoke library Converted these threads: -DuplicateHandle -GetCurrentProcess -GetCurrentThread -GetCurrentThreadId Fixed the VB files to allow the new Windows.Win32 namespace Fixed the information messages in Application.ThreadContext
Using the CsWin32 PInvoke library
Converted these threads:
-DuplicateHandle
-GetCurrentProcess
-GetCurrentThread
-GetCurrentThreadId
Fixed the VB files to allow the new Windows.Win32 namespace
Fixed the information messages in Application.ThreadContext
Microsoft Reviewers: Open in CodeFlow