You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Use Marshal.GetLastPInvokeError instead of Marshal.GetLastWin32Error in NETCoreApp #51648
.NET 6 introduces Marshal.GetLastPInvokeError that has the same functionality as Marshal.GetLastWin32Error, but is named to be representative of what it does: #46843
Usage in NETCoreApp should be updated to use GetLastPInvokeError instead of GetLastWin32Error. Note that not all usage in libraries can be updated, since some libraries compile for down-level targets.
@elinor-fung I have linked the PR to this issue however there seem to be some failing builds in the CI but I have noticed the same issue happening in different PRs where the same build is failing. I am assuming this is a known issue with the builds? I have run the tests and build locally and they all succeeded.
As you mentioned there were invocations of the method that I had to revert back to Marshal.GetLastWin32Error as they were causing build errors.
@jkotas I've managed to get the remaining done that were referenced in system.private.corelib. There were some conflicts due to different framework versions of the package being used simultaneously. I followed the readme and added the ref for System.Runtime.Interop directly into the relative slns.
One thing that I am confused about currently is after making this change, the Interop.Crypt32.CryptProtectData call is now complaining about a compilation error as the string szDataDescr param is not nullable when it's being passed as null in ProtectedData.cs. This is in the System.Security.Cryptography.ProtectedData library. It seems that before it was being passed as such but this compilation error must have been suppressed somehow.
Any ideas what might be causing this?
I've attached the PR as a reference with the parameter being tweaked to become nullable but I am under the impression that it is not supposed to so.
I think it may be because of you have added $(NetCoreAppCurrent) target.
I am not sure that it is worth it to be adding ifdefs to files that are used in multiple places. I think it would be better to use the existing API without an ifdef.
Nope, I was under the impression that corelib had everything contained in its sln library-wise (that's what the readme said), sounds like that's not the case though, where else should I be looking?
Activity
KZedan commentedon Apr 24, 2021
Hey, interested in contributing. How do I get this assigned to me? :D
elinor-fung commentedon Apr 26, 2021
Hi @KZedan - I have assigned the issue to you. Thank you!
Please let us know if you have questions by commenting in this issue.
cc @AaronRobinsonMSFT @jkoritzinsky
KZedan commentedon Apr 29, 2021
@elinor-fung I have linked the PR to this issue however there seem to be some failing builds in the CI but I have noticed the same issue happening in different PRs where the same build is failing. I am assuming this is a known issue with the builds? I have run the tests and build locally and they all succeeded.
As you mentioned there were invocations of the method that I had to revert back to
Marshal.GetLastWin32Erroras they were causing build errors.Let me know if this covers it.
Thanks!
jkotas commentedon Apr 29, 2021
#52003 converted some of the occurences. I believe that there are more than can be converted.
KZedan commentedon Apr 30, 2021
@jkotas I will take another look.
KZedan commentedon May 4, 2021
@jkotas I've managed to get the remaining done that were referenced in system.private.corelib. There were some conflicts due to different framework versions of the package being used simultaneously. I followed the readme and added the ref for System.Runtime.Interop directly into the relative slns.
One thing that I am confused about currently is after making this change, the Interop.Crypt32.CryptProtectData call is now complaining about a compilation error as the string szDataDescr param is not nullable when it's being passed as null in ProtectedData.cs. This is in the System.Security.Cryptography.ProtectedData library. It seems that before it was being passed as such but this compilation error must have been suppressed somehow.
Any ideas what might be causing this?
I've attached the PR as a reference with the parameter being tweaked to become nullable but I am under the impression that it is not supposed to so.
jkotas commentedon May 4, 2021
I think it may be because of you have added $(NetCoreAppCurrent) target.
I am not sure that it is worth it to be adding ifdefs to files that are used in multiple places. I think it would be better to use the existing API without an ifdef.
Have you looked at the places outside corelib?
KZedan commentedon May 4, 2021
Nope, I was under the impression that corelib had everything contained in its sln library-wise (that's what the readme said), sounds like that's not the case though, where else should I be looking?
KZedan commentedon May 4, 2021
Ah nevermind, I just found a bunch in externals.csproj
jkotas commentedon May 4, 2021
Any
Marshal.GetLastWin32Errorunder src/libraries in this repo is a candidate, as long as it does not require ifdefs to update.elinor-fung commentedon May 9, 2021
Thank you, @KZedan!
KZedan commentedon May 9, 2021
No problem!