You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, even when setting "disableMarshalling": true in the JSON file, CsWin32 will generate a lot of "helper" stuff by default (eg. friendlier wrappers for P/Invoke-s and generated COM types with managed signatures, vtable types, interface types, etc.). It would be nice to have an option to just have CsWin32 generate the 1:1 bindings for the specified APIs, and literally nothing else. In many cases, these additional wrappers are just not needed at all, because people would just be building their own abstractions on top of them anyway, and keeping them around just increases the IL size unnecessarily. It would be nice to just be able to tell CsWin32
"Literally just get me 1:1 bindings for these APIs as if I was using the C++ header directly"
Describe the solution you'd like
We could have a new "disableManagedHelpers" (or, some other name) boolean flag in the JSON, set to false by default. When set, CsWin32 would stop generating everything that's not directly required by the requested APIs. That is, it would skip:
All P/Invoke wrappers
All helper methods over COM types
All vtable types
All interface types for COM structs
Ie. you'd only get raw P/Invoke methods, and raw 1:1 blittable bindings for COM types.
Note: this flag would only cause CsWin32 to skip generating some stuff it's currently generating, so it should be fairly low cost to implement. Just add the new flag and pass it through, and add some checks to skip generating those optional APIs.
Describe alternatives you've considered
Just doing nothing, which would keep the current situation as is.
Additional thoughts
Related to this, but maybe a separate proposal — it would be nice if this also made CsWin32 stop generating all helper wrappers such as HRESULT, HWND, BOOL etc. as well. Instead, the real underlying value should be used, and CsWin32 could just generate a few global using type aliases for them. This would also match C++, as they're just defines there.
It's an interesting idea. I'm not opposed to it, but I can't say when it will bubble up to the top of the priority list either, as we have correctness issues or scenario blocking enhancements to make that may come first. But if you're interested in sending a PR, let me know and we can review the design proposal more closely before you start work.
You didn't mention enums. Would you prefer no enums and only emit individual enum values as constants on an individually required basis? That would lose the type information as no global using trick is a substitute for an enum's grouping of constants.
Overview
Currently, even when setting
"disableMarshalling": true
in the JSON file, CsWin32 will generate a lot of "helper" stuff by default (eg. friendlier wrappers for P/Invoke-s and generated COM types with managed signatures, vtable types, interface types, etc.). It would be nice to have an option to just have CsWin32 generate the 1:1 bindings for the specified APIs, and literally nothing else. In many cases, these additional wrappers are just not needed at all, because people would just be building their own abstractions on top of them anyway, and keeping them around just increases the IL size unnecessarily. It would be nice to just be able to tell CsWin32Describe the solution you'd like
We could have a new
"disableManagedHelpers"
(or, some other name) boolean flag in the JSON, set tofalse
by default. When set, CsWin32 would stop generating everything that's not directly required by the requested APIs. That is, it would skip:Ie. you'd only get raw P/Invoke methods, and raw 1:1 blittable bindings for COM types.
Describe alternatives you've considered
Just doing nothing, which would keep the current situation as is.
Additional thoughts
Related to this, but maybe a separate proposal — it would be nice if this also made CsWin32 stop generating all helper wrappers such as
HRESULT
,HWND
,BOOL
etc. as well. Instead, the real underlying value should be used, and CsWin32 could just generate a fewglobal using
type aliases for them. This would also match C++, as they're just defines there.As in, something like:
The text was updated successfully, but these errors were encountered: