PInvoke project scope and factoring

[AArnott]

We've established some good patterns and code generation to support writing P/Invoke signatures. These could be applied to P/Invoke signatures for perhaps any native DLL, well beyond Win32. This project currently doesn't have an official stance on the scope of just which native DLLs should have p/invoke projects for them in this repo.

I think focusing on Windows .dll's in this repo makes sense. Adding arbitrary 3rd party DLLs with a relatively small audience would make this repo's (already large) solution larger, ship more nuget packages for a single change to one, etc. This leads me to believe we should probably limit the scope of this project before we accept non-Windows DLL projects.

But how can we help these out-of-scope-projects? My proposal:

1. We refactor this repo such that its code generation is in its own repo and publishes NuGet packages for consumption by other PInvoke repos.
2. We have a dedicated PInvoke.Windows repo.
3. Any projects that don't belong in PInvoke.Win32 (for obvious reasons) will go into other repos named after the product that they offer PInvokes into.
4. All repos will share a common build, versioning, and publishing infrastructure, but may publish to nuget.org on their own cadences.
5. We move these repos into a GitHub organization. Ideally named, "PInvoke" but that is already claimed by an inactive user. :(

So long as we have only/mainly Win32 projects in this repo, the urgency of this is low. But if folks begin to show interest in leverage this repo for non-Windows related projects, I think we should consider this proposal.

[jmelosegui]

We have a dedicated PInvoke.Windows repo.

Why not having a repo per Library (ie: PInvoke.Kernel32, PInvoke.AdvApi32, etc) containing all the projects needed to build the NuGet package for that library plus all other dependencies (ie: Windows.Core) as a git-submodules. This will allow us to load within VisualStudio only those project we want to work with, mostly less than 10 projects rather than 112 as we have to do today.

We move these repos into a GitHub organization. Ideally named, "PInvoke" but that is already claimed by an inactive user. :(

Base on GitHub Name Squatting Policy

Inactive accounts may be renamed or removed by GitHub staff at their discretion.

So maybe we can contact GitHub asking for help with this matter.

[AArnott]

plus all other dependencies (ie: Windows.Core) as a git-submodules

I use git submodules... very sparingly. They are very painful to work with. And they break up what could be an atomic PR into several when a change impacts more than one package.

This will allow us to load within VisualStudio only those project we want to work with, mostly less than 10 projects rather than 112 as we have to do today.

Yes, the number of projects is getting quite large. But this should be fixed soon... by other means. Out of scope of this issue. But we can chat about it on gitter if you want.

So maybe we can contact GitHub asking for help with this matter.

Interesting. If folks like this proposal in general, we can pursue this.

[AArnott]

I have sent GitHub an email asking for help in acquiring the "PInvoke" name for a new org. If they grant it, I plan to move this repo to pinvoke/pinvoke.win32 or something to that effect. I'm leaning toward keeping a 1 repo per platform/product structure, so we might have pinvoke.mac, pinvoke.linux, and maybe some app SDK specific ones like pinvoke.SomeAppWithNativeAPIs.

All these repos could share a common codegen system and perhaps contribution guidelines, etc.

[vbfox]

:+1:

[AArnott]

GitHub indicated that the pinvoke user in fact is not so dormant as it appears (private repos, evidently). But they've given me a chance to send a one-time message that they will relay for me to request that the user change their user name, but it will be up to them. We'll see what happens. I can totally understand if they don't want to.