Reconsider taking HandeRef as input parameters when the parameter must be a handle of some sort.

Currently in CsWin32 no overloads taking in HandleRefs are generated.

The use cases:

• HandleRef is not only used by user applications (for referencing HWND handles to (most commonly) gui controls to pass them into p/invoke methods to the operating system apis).
• They are also used in the runtime itself (they are used a lot in the dotnet organization on github).
• user made libraries may also choose to use HandeRef for p/invokes to handles they do not own themselves to keep the GC from destroying them in mid call to the p/invoke.

This is where my code uses it: https://github.com/Elskom/Els_kom_new/search?q=HandleRef&type=code (it seems to not show every usage of it for some reason in my NativeMethods.cs file.)

Got 616 results for it as well too https://github.com/search?q=org%3Adotnet+HandleRef&type=code, a lot of commits, and issues regarding it as well.

More results could be in the code bases within all of the repositories in the dotnet organization on github, one way to find out for sure how many results come up is to clone them all, and then within Visual Studio search for HandleRef in every last repository cloned from there to get the absolute number of usages in the code within that organization.

I also encourage an in general look to see how many other people might also use HandleRef as well too.

As seen above, HandleRef while documented as deprecated in .NET 2.0, is still widely used everywhere even within the runtime itself with valid use cases that make it impossible to use say SafeHandle, expecially when you own the object that made the handle but not the handle itself and as such using HandleRef-or GC.KeepAlive(objectmadeinthiscode); are the only options to force the GC to not finalize the object (with said handle), before the native operating system calls finish with it and possibly cause undefined behavior on user's applications (and possibly the runtime itself as well).

This is why one or the other should be done, either tell the user to tell the GC to keep that object alive. or use a HandeRef that would need to be generated by CsWin32.

Another option for this, is to have it not generate HandleRef overloads by default but have the user opt-in for them if they specifically ask for said overload to be generated within the configuration for specific members only (opt-in per p/invoke function name) within the text file that controls the source generator.

There was more discussion about this in #125.

Start by reading the discussion in issue #125 and this issue's examples of HandleRef usage in CsWin32 consumers and the dotnet organization. Determine whether generated HandleRef overloads, GC.KeepAlive guidance, or opt-in configuration is the intended direction; done requires a decided scope and documented behavior.