How do we make sense of any of this?

[Gavin-Williams]

Why for example, do I need to include 'IDC_ARROW' in my NativeMethods file? How am I, a mere mortal expected to know that I need to include that? And why didn't I need to include LRESULT, I just needed to include the using Windows.Win32.Foundation.

Why? Why do we have to do any of this? I can't tell just by looking at the documentation or even my other code that uses CsWin32 what I have to do to make any particular Win32 function or struct work. It's just constant guess work and experimentation.

Another example. I've included CreateWindowEx, but why aren't these arguments recognized... WS_EX_APPWINDOW, WS_EX_NOREDIRECTIONBITMAP, WS_OVERLAPPEDWINDOW.

Some constants need to be referenced in NativeMethods and others do not.

When will we get a better system that just works? Maybe use the reference + using system. Just make the Win32 libraries available as nuget packages? Get rid of the need for a NativeMethods.txt file please.

[AArnott]

Hi Gavin,

Those are good questions. And this is very different than typical .NET programming, I agree.
There are a few reasons this is different. The simplest one is that the Win32 API space is huge. The reference assembly would be 80MB per architecture that your application wants to support, and you'd have to ship that. There are a huge number of constants, which per C language style have no natural namespace or containing type, so if you want constants without asking for them, you'd get tens of thousands of them, flooding your completion lists, slowing down your compilation, etc.
There are other reasons...

Another concern you shared is that you do seem to get some things for free but not others. We'd like to make this as easy as possible, so when you ask for one API (e.g. CreateWindowEx) we generate that function as well as all types it references automatically so you don't have to request them each explicitly. This works well for structs and enums. But when a parameter is declared as int (as it is in the win32 headers) yet the win32 documentation says that it can take any of 10 different values (possibly bitwise-OR'd together), there's nothing in the header files, and therefore nothing in the win32metadata file that CsWin32 is based on, to know what those constants are, so it can't know to auto-generate them for you.
So generally speaking, when you deal with constants, you have to explicitly list what you want to have declared for you. Most other types will be auto-generated based on the interfaces or functions you request.

I know that may not totally satisfy you, but I hope it helps convey the problem space we're working with and why we've designed it this way. And most of all, I hope it helps you to predict when you can expect things to be automatically generated vs. manually requested so you can be more productive while using CsWin32.