Skip to content

Use Marshal.GetLastPInvokeError instead of Marshal.GetLastWin32Error in NETCoreApp #51648

Description

@elinor-fung

.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.

Activity

  1. added this to the 6.0.0 milestone on Apr 21, 2021
  2. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Apr 21, 2021
  3. removed
    untriagedNew issue has not been triaged by the area owner
    on Apr 21, 2021
  4. KZedan commented on Apr 24, 2021

    @KZedan
    Contributor

    Hey, interested in contributing. How do I get this assigned to me? :D

  5. elinor-fung commented on Apr 26, 2021

    @elinor-fung
    MemberAuthor

    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

  6. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Apr 28, 2021
  7. KZedan commented on Apr 29, 2021

    @KZedan
    Contributor

    @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.

    Let me know if this covers it.

    Thanks!

  8. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Apr 29, 2021
  9. reopened this on Apr 29, 2021
  10. jkotas commented on Apr 29, 2021

    @jkotas
    Member

    #52003 converted some of the occurences. I believe that there are more than can be converted.

  11. KZedan commented on Apr 30, 2021

    @KZedan
    Contributor

    @jkotas I will take another look.

  12. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on May 3, 2021
  13. KZedan commented on May 4, 2021

    @KZedan
    Contributor

    @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.

    image
    image

  14. jkotas commented on May 4, 2021

    @jkotas
    Member

    Any ideas what might be causing this?

    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?

  15. KZedan commented on May 4, 2021

    @KZedan
    Contributor

    Have you looked at the places outside corelib?

    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?

  16. KZedan commented on May 4, 2021

    @KZedan
    Contributor

    Ah nevermind, I just found a bunch in externals.csproj

  17. jkotas commented on May 4, 2021

    @jkotas
    Member

    Any Marshal.GetLastWin32Error under src/libraries in this repo is a candidate, as long as it does not require ifdefs to update.

  18. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on May 9, 2021
  19. elinor-fung commented on May 9, 2021

    @elinor-fung
    MemberAuthor

    Thank you, @KZedan!

  20. KZedan commented on May 9, 2021

    @KZedan
    Contributor

    No problem!

  21. ghost locked as resolved and limited conversation to collaborators on Jun 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions