Last time I looked at pinvoke.net I wasn't impressed. Lots of incomplete or just plain wrong code (pointer sized parameters marshaled as 32 bit ints etc). Just take a look at the CreateProcessWithLogonW page for example.

The best thing you could do is to provide most common signatures with the framework or the SDK.

Failing that, improve the documentation. Add a few more samples using real win32 APIs. Add some docs describing most common errors and how to debug them. For example, very few people know that pageheap (gflags -p) is a very effective tool for troubleshooting marshaling problems. I've seen people spend weeks chasing mysterious NullReferenceExceptions with an empty stack trace. Usually these symptoms are caused by heap corruption due to bad pinvokes, and pageheap catches such problems instantly.

The best thing, I think, is exactly what we got: pinvoke.net. I mean, it tells me exactly how to call a given API. The fact that I don't have to worry about debugging at all is brilliant.

Of course, the problem with pinvoke.net is that it doesn't have every single API I could ever want to call, so I guess at some point, *someone* has to do some debugging...

I've added a few methods to pinvoke.net in my time and I guess the main point is that as long as the information is available there (and accurate) then you don't really need any more!!

It would have been nice with c/c++ parser (typically for header files) that could output suggestions for p/invoke signatures.

PInvoke.net is great, as is the VS.NET addin for it - but I don't necessarily trust what's on it. It's inconsistant, and some things are just plain wrong.

The most useful thing would be for Microsoft to add all API calls into the managed framework - but that's probably asking too much. It would be so nice if we didn't have to worry about calling into Win32 APIs.

If Microsoft published a full list of Win32 API signatures, including correct attributes and caveats in an easily accessible way. In fact, if Microsoft could spend some time verifying and updating PInvoke.net, that would improve the situation immensely.

It would be great if MS could provide full PInvoke source (not PIA) for user32, kernel32, gdi32, ole those are the most common and could be embedded or used as a learning tool for other PInvoke endeveurs. The source should include XmlDoc from Windows SDK so we don't have to go hunting it down.
A good tool called COM2dotNet from aurigma.com was very useful but seems to be discontinued. MS Should create something similar. it produced clean code from type libraries, better than axImport tool.