Support for AOT

[ffMathy]

Does Mediatr support AOT? Given AOT's focus in dotnet 7 (and now heavily in dotnet 8 preview 3), it would be awesome if Mediatr could support it.

Perhaps a source generator in the NuGet package that generates code which eliminates reflection use could be used?

Maybe even inspired by https://github.com/martinothamar/Mediator.

[jbogard]

Does Mediatr support AOT?

I have no idea

Perhaps a source generator in the NuGet package that generates code which eliminates reflection use could be used?

Perhaps, but it's not something any of my clients need, none of them need any kind of AOT. Coming from AutoMapper that uses expression tree compilation, that kind of code can get very complex very quickly and is a LOT of work to maintain. I wouldn't take that kind of thing on without direct need from someone paying for it.

[ffMathy]

Everyone who is using AWS Lambda, Azure Functions or any other serverless tech needs this.

It gets the request time down from around 2 seconds to around 150 milliseconds.

In fact, for Azure Functions, it looks like they are defaulting to AOT for new projects in dotnet 8. That essentially means that Mediatr will not be supported there.

Would you accept a pull request for this kind of functionality?

[jbogard]

I don't use MediatR in those scenarios, not for performance reasons but fit-for-purpose. I don't use MediatR in cases that are essentially already "single handler" frameworks (Functions, or things like NServiceBus/MassTransit).

I can't take big, complex PRs unless it's something that I have a direct need for because I have to maintain it so I will need to understand it thoroughly. I've had to learn this lesson the hard way over the years of doing OSS.

But, if those that pay the bills do see the need and want to sponsor it, I'm happy to take it on and even collaborate to do so.

[ffMathy]

Fair enough. Your reasoning makes a lot of sense. I am an OSS maintainer myself, and I totally understand that you'd need sponsors for this to be feasible for you. I can 100% relate.

As for the functions being "single handler", actually many functions are large. I know that defeats one of the purposes of serverless, but it still gets you things like scaling, almost instant deployment, etc. That's why I often see large functions in the wild, but where they are still abstracted nicely out into smaller chunks on a software-level.

[pbolduc]

I was searching for this today as well. I came across an attempt MediatR.DependencyInjection.SourceGenerator. This has not been updated for 3 years, is alpha qualify and has a number of limitations. Perhaps a 3rd party extension like this could provide basic functionality require for use cases listed above.

[jgarciadelanoceda]

I think there is another implementation that could bring MediatR the AOT stuff. Check this video of Nick Chapsas https://www.youtube.com/watch?v=aaFLtcf8cO4

[ffMathy]

I think there is another implementation that could bring MediatR the AOT stuff. Check this video of Nick Chapsas https://www.youtube.com/watch?v=aaFLtcf8cO4

I think that is the one I linked in the original issue, no? 😄

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 14 days with no activity.

[Dreamescaper]

I have a created a small Source Generator to register types automatically, and one of the use cases is to allow to register MediatR handlers without reflection assembly scanning. Maybe someone finds it useful :) https://github.com/Dreamescaper/ServiceScan.SourceGenerator?tab=readme-ov-file#add-mediatr-handlers