-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CsWin32 is effectively unusable with trim/AOT #1273
Comments
This isn't true. In fact CsWin32 is already heavily used in WinForms which supports trimming. |
I don't see us setting CsWin32 to default to generating harder-to-use APIs to support a non-default and minority case of C# users. |
If by blittable mode you mean when
I'd love to get CsWin32 to a place you feel great about recommending its use. |
That's a tall order, because roslyn doesn't support chaining source generators. I have asked in the past for the source generator that supports those attributes to pack itself up as a library (as well as its own SU) so that CsWin32 can bundle it and chain it in internally. But so far that hasn't happened AFAIK. |
It is. Even with As of right now, like I said, we had to flat out tell people not to use CsWin32, which isn't great at all.
This is not what I asked for at all. I said the default should be to have
@jkoritzinsky mentioned several possible approaches that could be used to address this. |
Because your opening statement (indeed, the title of the issue) emphatically states something that we have evidence from multiple users and repos to contradict.
It sounded to me you also want the default to avoid the runtime marshaler (for non-COM scenarios), which would compromise the API -- for now. If we can get CsWin32 to a point where non-marshaled APIs are as good as the marshaled ones, then changing the default may make sense at that point.
Awesome. I look forward to hearing more. |
How so? I specifically said that this issue is about the fact that:
I don't know what evidence you have from other repos but both of these things are just objectively true. I also added that I'm not asking for the default mode to necessarily be changed, but to have at least some option to keep using managed interfaces (ie. not blittable mode), but in a way that's AOT safe. That is, using I would love to be able to use CsWin32. But the fact is right now we just had to tell everyone (in Windows) to not use it. |
One possible approach that would integrate cleanly with Alternatively, you could define your own model that would work.
I'm hoping to get something like this done soon-ish™️. We'll see if I'm able to. |
If so, then that's a bug. #1017 should have resolved that long ago and we have a test that proves it still works (at least for the test case). Can you please file an issue with the repro for this, @Sergio0694? |
There is a lot about ComWrappers that I don't understand. IIRC the policy we've adopted so far in CsWin32 is to avoid direct support for it, but generate code that is compatible with it. This is how winforms does it: cswin32 + their own COMWrappers glue code. |
WinForms not fully supporting AOT / Trimming has to do with reflection specific code, not COM. We fully use manual COM in .NET 9. That said we don't expose managed interfaces generated by CsWin32 in any way, so we don't have to deal with that end of things. Fyi, the key reflection specific code:
|
Overview
I suspect this is a known issue, but I figured it was about time to open a tracking issue. The generated code that CsWin32 produces is completely incompatible with trim/AOT. This keeps coming up all over the place as more apps and system components start experimenting with NativeAOT or start migrating to it. This applies not just to the default mode for CsWin32, but also to the blittable mode, as it still generates
[ComImport]
interfaces, as well as P/Invoke-s with unsupported features for eg. disabled runtime marshalling.The ask is to make the default mode (optionally opt-in, but not just for the blittable mode) to generate code that is trim/AOT-safe. That is, the generated code must be able to compile (when used) with 0 warnings with these two properties being set:
For this to happen, the following things must be true:
ComWrappers
[GeneratedComInterface]
on them[LibraryImport]
Until then, CsWin32 is a non-starter with NativeAOT, and we have to tell developers to not use it.
This is a constant source of frustration, because:
@jkoritzinsky mentioned it might be possible to update CsWin32 to be built on a shared backend with the COM generators, which is currently work in progress. If so (and if profitable), we should start a conversation/planning to make this happen.
/cc. @manodasanW @jevansaks @Jeremy-Price
The text was updated successfully, but these errors were encountered: