Missing generation of RasEnumConnections

[mconnew]

Actual behavior

I have added rasapi32.* as the only line to NativeMethods.txt. I have multiple RAS related methods generated into my project and am able to at least call RasEnumEntries, but RasEnumConnections[A|W] is missing.

Expected behavior

To be able to call and use RasEnumConnections

Repro steps

1. NativeMethods.txt content:

   rasapi32.*

2. NativeMethods.json content (if present): Not applicable as not using a json config file

3. Any of your own code that should be shared?

Context

• CsWin32 version: [e.g. 0.3.2-beta]
• Win32Metadata version (if explicitly set by project): default
• Target Framework: [e.g. netstandard2.0] net6.0
• LangVersion (if explicitly set by project): [e.g. 9] default

[AArnott]

When I try it, the RasEnumConnections method is generated. Note that the A/W suffix is not reproduced by default, as described in the README. You can use Go To All and type API names to try to find them in the generated code. You can also expand Solution Explorer's analyzer node to find all the generated files:

I hope this helps.

[mconnew]

@AArnott, I did my due diligence before opening an issue, it's definitely not there. I'm attaching the generated Windows.Win32.PInvoke.RASAPI32.dll.g.cs for you to see that it's missing. Also a screenshot of the editor method drop down in VS and you can see it's missing.

Windows.Win32.PInvoke.RASAPI32.dll.g.zip

Is there any logging that can be enabled for the code generation as something is causing this method to be missing?

[AArnott]

Are you targeting AnyCPU? If you ask for RasEnumConnections directly and build in an AnyCPU project, you'll see a PInvoke005 warning telling you why it cannot be generated. Its definition (possibly transitively through the types it references) varies by CPU architecture, so you have to commit to one or more architectures to get this API generated.

[mconnew]

I hadn't specified the CPU architecture. I confirmed specifying the CPU arch does cause the API to be generated. I thought all the Win32 API's just worked with the same definition (using IntPtr for bitness differences), today I learnt something new.

Can I suggest when targeting an entire library to output a warning for each individual API which can't be output in a CPU agnostic way? The discoverability of the root cause here is almost non-existent and requires domain context to diagnose. At least mention it in the docs/samples.

[mconnew]

Having you considered in those situations where the 32bit and 64bit api's are different, the possibility of having an entry method which switches based on the os bitness you're running on and calls another API based on that? There's already wrapper methods created which take a ref or out parameter and wrap that in a fixed block to call the actual native api using pointers.

[AArnott]

Yes, I agree we should improve discoverability in the wildcard case, which seems to be where the problem lies. If we use a warning, it should probably be a dedicated warning code just for wildcards so that folks can suppress it without suppressing the one from explicit API requests.

And yes, we have several ideas for improving multi-arch declaration support. We have several active issues on the subject.