GeezerVison is showing github.com — User Story: Source generators are added to common libraries to improve performance · Issue #43545 · dotnet/runtime
User Story: Source generators are added to common libraries to improve performance #43545DescriptionSource Generators are a new technology that was added to Roslyn in the .NET 5 timeframe, but we have not yet utilized them by creating generators to assist with runtime and framework features. We will work to define customer scenarios in more detail here with customer development.
Code that uses runtime reflection and reflection.emit causes issues for Trimming and Native AOT. Source generators can be used to generate alternative code at build time that is static so can be used in conjunction with Trimming and AOT. Work on trimming ASP.NET apps has revealed where there are current limitations that can be solved by source generators. Reacted by Thomas Ibel, Juan Hoyos, Jan Kotas, D3-LucaPiombino, Yair Halberstadt, Reilly Wood, Sven Boemer, expcat, Yupei Liu, Gulshan and 7 more ActivityYairHalberstadt commented on Oct 19, 2020
Trimming / Blazor / Native & Mono AOT – source generators can be used to convert code that does reflection.emit at runtime to source generators which will create code at build time rather than runtime. The generated code can then be analyzed by the illinker or native AOT enabling those scenarios.
Dependency Injection – is an important part of ASP.NET startup that could be replaceable with code generation at build time.
I have a project which does DI entirely at compile time via source generators: https://github.com/YairHalberstadt/stronginject
It's ideal for use cases which want to avoid any reflection, so great for trimming, blazor, and AOT. It's not a drop in replacement for Asp.Net DI, but maybe might serve as some inspiration.
There's plenty of other open source projects using source generators for things like serialization, and other reflection usages. I think it would be awesome if Microsoft could help with spreading the word about these projects, and possibly contributing, rather than creating competing alternatives!
Thanks for all the good work! Reacted by David Fowler, MuiBienCarlota and Yan Reacted by David Fowler and Yan changed the title [-]User Story: Source generators continue to assist with runtime and framework features[/-] [+]User Story: Improve framework trimming using source generators[/+] on Oct 20, 2020danmoseley commented on Oct 22, 2020 Any community feedback on @samsp-msft prioritization above? changed the title [-]User Story: Improve framework trimming using source generators[/-] [+]User Story: Source generators are added to common libraries to enable apps using them to be trimmed. [/+] on Oct 22, 2020richlander commented on Oct 28, 2020 I'd like to see the BCL and ASP.NET options prioritized separately. I don't think its useful to stack rank those together. danmoseley commented on Nov 2, 2020 @samsp-msft We should break these into separate user stories, probably one per source ge erator -- as they need to be costed, prioritized, owned separately. Can we do that?. samsp-msft commented on Nov 2, 2020 does it need a user story per generator (will become a bit heavy when it rolls up to the larger epic)? I would suggest converting the list in this to checkbox links off to individual task items, each of which can be costed / prioritized? danmoseley commented on Nov 16, 2020 System.Runtime.Serialization contains both DCS and also BinaryFormatter. I assume you mean DCS.
@eerhardt I assume DCS work is still required after your #42824 eerhardt commented on Nov 16, 2020 changed the title [-]User Story: Source generators are added to common libraries to enable apps using them to be trimmed. [/-] [+]User Story: Source generators are added to common libraries to improve performance[/+] on Nov 24, 2020danmoseley commented on Nov 29, 2020 @samsp-msft @marek-safar this story no longer has any children. Should it be closed? Or we should link XmlSerializer and DCS - anything else?
Note the name of this user story needs to be improved -- what is "performance"? runtime perf? size? startup? it should be one thing.
@jaredpar thoughts about the use of ref-emit in Microsoft.CSharp - it's AOT unfriendly and apparently Mono has a working version today. cc @marek-safar jkotas commented on Nov 29, 2020
use of ref-emit in Microsoft.CSharp
It is used on COM interop specific code path. It is not a problem for Mono because Mono does not support COM interop (and we do not even support Mono in dotnet/runtime repo on Windows currently).
I do not think there is anything to do. The legacy COM interop is AOT unfriendly in many different ways. danmoseley commented on Nov 29, 2020 marek-safar commented on Nov 30, 2020
this story no longer has any children. Should it be closed?
I'd close it, and if we have XmlSerializer and DCS user story add them to relevant epic they are addressing problems for danmoseley commented on Dec 4, 2020
I'd close it, and if we have XmlSerializer and DCS user story add them to relevant epic they are addressing problems for
@HongGit OK to close? do you want to create stories for source generators for XmlSerializer and/or DCS? I suggest to do that even if they won't happen in .NET 6, as that will record the decision and discussion can continue there. ghost locked as resolved and limited conversation to collaborators on Jan 8, 2021 mairaw commented on Jan 15, 2021 Is this really completed or was it cut? samsp-msft commented on Jan 15, 2021 The work from this was refactored into other work items, and so was no longer relevant as the planning node.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|