Specialize generation of GetLastError about cswin32 HOT 12 CLOSED

@michael-hawker Where were you looking for the error? After adding GetLastError to NativeMethods.txt, the build log produces this for me:

1>C:\Users\andarno\source\repos\CsWin32Sandbox\CsWin32Sandbox\NativeMethods.txt(1,1,1,13): warning PInvoke003: This API will not be generated. Do not generate GetLastError. Call Marshal.GetLastWin32Error() instead. Learn more from htps://docs.microsoft.com/dotnet/api/system.runtime.interopservices.marshal.getlastwin32error

But you won't see it in the Error List. At least not before a build. This is due to dotnet/roslyn#49531.

from cswin32.

Ah, failing the build is the key difference then. It wouldn't explain why the method isn't there in the IDE until you actually try to build, which typically is not necessary after a change to NativeMethods.txt.
Thank you for the added insight. I think though that we'll wait for roslyn to fix dotnet/roslyn#49531 and for feedback from more folks before changing this policy.

from cswin32.

Alternatively, block generation, and fix all the docs to point to the proper method to use.

from cswin32.

Specializing the docs is both tricky (mostly because of the hyperlink around it that will keep changing how exactly it looks) and less effective, since we also link users to the web docs that still refer to GetLastError. So I'm going to suppress generation of the method and emit an error if users try to directly ask for it, that educates them on what to use instead.

from cswin32.

Closed by e4c28e6

from cswin32.

@AArnott didn't see this warning or error when we added GetLastError to the NativeMethods file? Where should it appear?

from cswin32.

@AArnott I don't think I looked in the output window as the project built. Should it be an error instead of a warning? As otherwise I wouldn't have thought to go in the output window to see this type of message. Or I would have expected a yellow VS warning squiggle on the line n the text file (if that's possible).

from cswin32.

The error list and squiggles are absent because of the roslyn bug I linked to. As to whether it's an error or warning, it's a warning for the same reason I suppose that unresolvable assembly or project references are warnings: your code may be perfectly fine to compile in spite of it. You'll see a compile error if you try to use an API that doesn't exist.

from cswin32.

@AArnott, I think the issue is, I'll try and use it like PInvoke.GetLastError, get an error and see that it doesn't exist, go check the generated output, see that it wasn't generated, then go to the text file for NativeMethods and see that I have it there and then scratch my head...

If it was an error in the generation step, then I'd immediately know that I've put something invalid in the NativeMethods file, and that error message would tell me to not use GetLastError but something else instead. That'd be discoverable and help me on my way immediately than trying to poke around VS for 10-20 minutes wondering what's going on and searching on the Internet missing the thing buried in the Output window.

from cswin32.

If it was an error in the generation step, then I'd immediately know that I've put something invalid in the NativeMethods file

How would you know that? Errors and warnings from the source generator appear in the same place (neither show up in the error list, but both appear in the build output).

from cswin32.

If the build fails, then I'm going to go look at the output window, so then I'd see an error from the generator telling me about GetLastError and what to do.

If I get a red squiggle in VS because something isn't found, I generally don't look in the Output window. I start looking at package references, and configurations, and a bunch of other things.

from cswin32.

If I get a red squiggle in VS because something isn't found, I generally don't look in the Output window.

This used to be true of me, but I started forming the habit of looking in the Output window for build output if the build fails and the error list is empty, after persistent (unrelated) issues with the error list in past VS versions.

from cswin32.