Will this project support AOT in .Net 5?

[ismlsmile]

In .Net 5, CoreFX will be extended to support AOT. So I wonder if WinForms could support AOT in .Net 5? Thanks.

[Symbai]

@ismlsmile Do you have any source about this? I am curios to read what exactly is planned because as far as I know AOT is only "something that the .NET Core team takes a look at it" and one of them replied in a blog comment a month ago they already have a working winforms prototype. But I couldn't find any information that it is definitely planned for .NET 5.

[merriemcgaw]

@OliaG can you follow up on whether there are any plans in this space, and if we'll be able to leverage what the rest of .NET Core is doing?

[OliaG]

@ismlsmile, thanks for the feedback. The team is still working on a plan for AOT, so it's too early to say which parts will support AOT for .NET 5, but eventually we'd like WinForms to support it too.

[wjk]

Just a quick update on the current state of this issue:

I have tried running the NativeAOT compiler over a simple Windows Forms application. When I run the resulting AOT’d binary, it displays a fully working form with button. I click the button… and get an unhandled exception. NativeAOT does not currently support ComImportAttribute, which WinForms uses extensively to provide accessibility support. If I manipulate a custom control that I wrote from scratch (without accessibility support), everything works perfectly.

Unfortunately, properly implementing ComImportAttribute support in NativeAOT is a very difficult proposition. Moving WinForms to a CsWin32-like solution using machine-generated unsafe code would probably be easier (and still be compatible with the regular runtime-JIT CLR), but changing to that technique would be extremely disruptive. Also, the requisite tooling doesn’t quite exist yet (cf microsoft/CsWin32#86).

[RussKie]

/cc: @AaronRobinsonMSFT @AArnott FYI

[AArnott]

@wjk For my own enlightenment, what is it about ComImportAttribute that makes any difference at runtime at all? Is it the type equivalence when it is embedded?

[AaronRobinsonMSFT]

@AArnott It isn't really anything specific with ComImportAttribute, it is what it implies - COM. COM isn't AOT friendly because of all the dynamic code gen at runtime - marshalling stubs et al. It is even more complicated when IDispatch is involved because that is basically reflection for COM and not feasible in AOT in practice. The key issue is around removing all code gen at run time.

The C#/WinRT tooling does a fairly decent job of that but even it uses expression trees in some cases. The concrete problem is the plug-in model. If any COM type can be loaded then it isn't known what interfaces it may expose or how so it is hard to know what to generate ahead of time. If the full transitive closure of types is known then it can be done with immense effort - see .NET Native and the UWP ecosystem.

[kant2002]

I think there is a good chance that currently NativeAOT can run you WinForms application. There some work happens to improve situation, and make Winforms works as is.

[RussKie]

I think we can close this question with an answer - no, .NET 5.0 is done, and won't support NativeAOT.
With all the awesome work that @kant2002 is currently doing .NET 6.0 is likely to provide (at least limited) support for NativeAOT.

However this is not an official promise, the team is aware of the desire to have this capability available, but we have multiple competing priorities, and some things have higher priorities than others.