[Question] CoreRT future plans

[christianscheuer]

Dear CoreRT team,

Having followed this repo for now a couple of years and having developed a product depending on it, it's been quite a journey to follow the development in here. It's been very rewarding to be able to follow the progress of a compiler and runtime and I've been stoked to see that it was finally possible to do full AOT compilation of .NET. It's been a joy to watch the discussions and PRs come in one by one, slowly improving the product - thank you to the whole team for all their hard work on this!

Now for my question. During the past months I've started to notice hints about the future of CoreRT in a growing number of discussions around github and I've been surprised to see references to that CoreRT is still considered an experimental runtime and is often ruled out as a good solution for customers. Whereas initially over the first years following this, it felt like CoreRT was on a path to becoming part of the official "dotnet" CLI experience, but these recent discussions seem to indicate that the opposite is true. It strikes me that in the long discussion thread on single file deployment many of the use cases would benefit from CoreRT yet it seems like everybody is ruling it out for reasons I still don't fully understand (apart from the obvious dynamic plugin loading, but honestly there are many alternative ways to implement plugins in CoreRT, some of which we use in our product).

It seems to me that you have a stellar product here that would solve so many issues if it were on a path to official support, yet at some point along the way it was decided to not fully support it anyway. @jkotas you hinted in the discussion that the technology would likely end up in a (different) product some day, but even if that calmed my nerves slightly, it also sparked more questions, such as - can we continue to rely on this compiler for our product, or do we run the risk of it suddenly falling out of grace. I thought at one point that the decision to not officially support CoreRT was simply that it wasn't ready. But now that it feels increasingly more mature yet seems to be ruled out of official support plans, it strikes me that it might be a more strategic decision.

I know that this might be a tricky question to answer in a public forum, but please don't take it the wrong way. I'm just curious to try to understand if full AOT compilation (not CPAOT but CoreRT) is still being considered a strategic part of the .NET future.

I have noticed the efforts to unify the sources from the various runtimes which is another hint that long time development is intended. I understand that this repo serves many officially supported products, among those now .NET Native and CPAOT, which leads me to have greater trust in CoreRT going forward.

But I hope it makes sense that it would be nice at one point to gain a little clarity of what Microsoft's intentions are in the longer term in this space. In my ideal world, it would be decided to acknowledge how great of a product this already is and it would gain a permanent place on the .NET stage.

[rclarke2050]

@jkotas what do you mean by native AWS support?

AWS Lambda only supports LTS versions of .NET only, .NET Core 3.x is not yet at LTS stage, so you have to build a Lambda function as a Custom Runtime, to use .NET Core 3.0. its a bit of a pain aswell, because if you want to use .net core 3.0, you must compile on linux distrib and prepare the package zip there.

However, I believe it will be coming soon, read here: https://github.com/aws/aws-lambda-dotnet/issues/481

AWS Lambda .Net project https://github.com/aws/aws-lambda-dotnet

Lambda runs on KVM https://www.techrepublic.com/article/aws-firecracker-10-things-every-tech-pro-should-know/

[Jamlee]

R2R in .NET CORE 3.0 include all the managed il code, you can disassembly a R2R dll use ILSpy, it can make runing faster, but it can't protection code.

.NET CORE 3.0's single-file executable is just a zip file, when first time execute it, it will unzip it to a temp folder, except need more disk space to run, no practical meaning.

CoreRT = R2R remove IL code safely then merge it into a single file, it is the fastest and safest code, and need small disk space, it is the best.

agree fully !!

[Jamlee]

They are go ahead. https://github.com/spring-projects/spring-framework/issues/22968 https://www.graalvm.org/docs/reference-manual/native-image/

[forestbat]

@jkotas You (or CoreCLR , or Microsoft) need a little speed，graalvm is running after you.

[sgf]

CoreRT, should be At the right time to do some trade-offs in order to get the stages of development. Focus first to solve a particular platform - specific issues or major problems.

At this rate, even if in a few years now,I'm afraid there's no obvious progress.

[rclarke2050]

its funny really, because it feels like we're all going back to the days of compiling to the platform specifically..... I remember my days of Delphi v3-7. Nice small packaged tight effortless exe.....aaahhhhh

we've come full circle.....

[masonwheeler]

Yeah, the Delphi model worked really well. Still does, in fact. Java and .NET made us lose sight of that for a while, but it's being rediscovered nowadays, and Microsoft doesn't appear to realize that. With all of the public lamentation that Bill Gates and others have done recently about missing out on obvious trends, you'd think they'd be big on jumping on this one so as to not repeat the same mistake!

[hitchhiker]

As a passive observer: Microsoft seem to have proven recently (against all historic expectations) that they understand supporting the community is the way to surive. The community appears to support this, Microsoft should put their weight behind it.

Microsoft: That expectation of support is what makes us developers feel safe investing in your long term products, and what ultimately ensures your survival.

[s-m-k]

FYI https://twitter.com/coolcsh/status/1110392209814126597

I had to bite my tongue not to respond to that comment because it devalues the work lots of people from the community and from Microsoft put into .NET Native and CoreRT.

I've just added my own 2 cents about our successful release of production code built with CoreRT, if that helps! https://twitter.com/kroskiewicz/status/1200126309856350209

I agree with the previous commenters that the proper AOT support is actually a necessity if we ever want to consider real-time applications (such as games, audio processors, and so on) seriously. In such scenarios, higher overall performance is not as important as stable performance. On top of that, I doubt that JIT compilation is as favorable and gainful as it is thought to be in most cases. For example, I can't actually measure any performance difference in our game (regarding the average frame time), besides the "first-time execution spikes" in the JIT mode, which makes the choice of AOT quite obvious (the game just feels so much smoother and more robust when the frame-rate is stable). The only functionality that might actually take advantage of JIT would be, in our case, serialization. However, I'm more than happy to trade this perk only for the comfort of stable and rock-solid performance in the real-time part.

[mrhelmut]

Butting in to let you know that we've been using CoreRT on games too (pretty big ones) successfully.

Though with the release of .Net Core 3.1, we've been testing ReadyToRun images and the performances seem quite identical to CoreRT (while still supporting all features of the full runtime).

That's just from a performance and runtime features perspective.

CoreRT still has the advantage of producing a single binary, while .Net Core self contained apps are bloated with files/assemblies, even if using trimming (and .Net Core SingleFilePublish is quite unusable because it is in fact a self-extracting archive, and the first time you launch an app using it, the performances are terrible, especially when considering GBs of games).

All-in-all, pretty impressed by the recent directions of all the dotnet runtimes.

[s-m-k]

Funnily enough, I was unable to get rid of the occasional JIT spikes using ReadyToRun images (still a world of difference compared to CoreRT).

[charlesroddie]

I gather that Ready2Run = crossgen. Now there is a lot of work in dotnet/runtime on crossgen2. I wonder how that compares to crossgen or corert.

[Suchiman]

@charlesroddie crossgen2 is based on the CoreRT compiler technology, whose ReadyToRun portions have been deleted in CoreRT here as part of the move to CoreCLR

[gulshan]

What new features can we expect from CoreCLR after implementation of crossgen2 then?

[Suchiman]

AFAIK crossgen2 is the "third generation AOT" described in this talk

[rollsch]

Question. Would taking RyuJIT/NetNative that compiles app store images and working backwards to create a single executable be a quicker path to achieve the goals of CoreRT opposed to continuing down this path?

I don't have an indepth understanding of the actual differences between CoreRT and netnative, so perhaps this is actually what has been done so correct me if the question doesn't make sense. This also assumes RyuJIT/NetNative are open sourced?

Edit: It seems ReadyToRun may already be working to do what I suggested above? Can someone contrast ReadyToRun to CoreRT?

[Suchiman]

@rolandh RyuJIT is the JIT used in CoreCLR and .NET 4.6+? and it's open source. CoreRT is a runtime for AOT scenario's that's used for .NET Native and... CoreRT 😉 . .NET Native has it's own ILC (IL Compiler) based on UTC (the closed source MSVC++ codegen engine). CoreRT (on its own as in this repository) primarily uses RyuJIT as codegen engine to produce AOT binaries. ReadyToRun is the successor to NGEN, it's (currently) an AOT approach with JIT fallback while CoreRT is "full" AOT without JIT fallback.

[MichalStrehovsky]

@rolandh I think a lot of your questions are also explained in more detail in this article (relation to .NET Native, and contrast of ReadyToRun/NGEN to CoreRT).

[sgf]

no much time, .net 5.0 is coming 😂 ,CoreRT need more speed. maybe Microsoft need Arrange several Masters(some Compiler Expert) to join CoreRT‘s team.

Otherwise, the progress of CoreRT may not be able to keep up with the release of .net 5.0.

[mrhelmut]

I have to come back on my initial comment about using .Net Core Ready2Run images for games VS CoreRT.

We A/B tested in production 4 scenarios, and it completely confirms @s-m-k experience:

• Mono 5 (no AOT): no stuttering
• .Net 4.5.2-4.8: no stuttering
• CoreRT: no stuttering
• .Net Core 3.1 (with Ready2Run): very frequent visible stuttering

That makes .Net Core a very bad choice when it comes to games. Also noting that we have a 0 garbage policy so this is really about the JIT kicking in and not about GC at all.

P.S.: performance issues of .Net Core 3.1 may be related to TieredCompilation. We are going to run tests over the next few days with this disabled to see if it makes a difference.

[s-m-k]

@mrhelmut I think I've managed to tame .NET Core 3.1 (even without R2R). By turning TieredCompilation off I've attained quite stable realtime performance (remember to remove bin and obj before you recompile or else you won't notice any changes).

According to the docs (https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0) turning that feature off does indeed make sense in our case:

The main benefit of TC is to enable (re-)jitting methods with a lower-quality-but-faster tier or a higher-quality-but-slower tier. This helps increase performance of an application as it goes through various stages of execution, from startup through steady-state. This contrasts with the non-TC approach, where every method is compiled a single way (the same as the high-quality tier), which is biased to steady-state over startup performance.

So, if I understand it correctly, by turning it off you sacrifice the short startup time for consistent run-time performance, exactly what we're after. It's still not as perfect as CoreRT (without it you get longer startup time, larger binaries if you use R2R, messy file structure, plus some mild spikes might still sneak in, at least on Debug), but acceptable if you want to e.g. support Windows x86.

[mrhelmut]

The tiered compilation documentation is super misleading.

If disabling it makes Tier1 (the optimized/longer to compile) code the default, then it should have visible stuttering when it JIT.

I guess the real benefit would be to force the runtime to use only Tier0 JIT (and maybe use Tier1 on R2R only), which I have no idea what are the correct parameters value to set between TieredCompilation and TieredCompilationQuickJIT to achieve this.

If you get smoother performances with TC off and the JIT is defaulting to Tier1, that seems strange to me.

[s-m-k]

If disabling it makes Tier1 (the optimized/longer to compile) code the default, then it should have visible stuttering when it JIT.

But, as far as I'm concerned, it also does most of the work during startup, so there's little point in re-running the JIT afterwards. Hence the "steady-state bias" part.

[Suchiman]

Only using Tier 0 is equivalent to the debug optimization level, you can force that with COMPLUS_JITMinOpts=1 (minopts = minimum optimizations). Also see https://github.com/dotnet/docs/issues/15143#issuecomment-550045952

[mrhelmut]

Okay! So tiered compilation makes the JIT to run more frequently and way after startup (because it has a lot of things to promote from Tier0 to Tier1), while disabling TC makes the JIT to kick in mostly at startup, hence the smoother performance despite it still having to compile some Tier1 code after (at the cost of startup time).

Thanks Suchiman, I'm going to investigate this as well.

EDIT: and so R2R seems to be Tier0, which makes it pretty useless in a non-TC scenario, right? As far as I understand it, R2R is useless in a TC-off scenario, or possibly harmful because it opens up to Tier0 code to be promoted. So the smoothest scenario would be to have both R2R and TC turned off?

[mrhelmut]

Confirmed: disabling TC and R2R makes games run as smooth as on other runtimes. I can't really test JITMinOpts because things are already perfectly smooth on our projects without it.

[Kein]

The dependencies:

<add key="dotnet-core" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />

from https://github.com/dotnet/corert/tree/master/samples/HelloWorld are no longer available/accessible. What are my options?

[charlesroddie]

@Kein This thread's title is "[Question] CoreRT future plans".

[Kein]

And? The project is no longer maintained thus why this thread exist. I'm asking here, hoping to find someone who encountered same issue and has any tips or workaround since this page has most traffic. There is no point to create a junk issue submission.

[charlesroddie]

Can you post as a separate issue and delete those comments and then I'll delete mine to clean up the thread for everyone else.

[masonwheeler]

@Kein Most recent commit was around 5 hours before you posted that. It's a bit odd to call such a project "no longer maintained."

[Kein]

@masonwheeler Read the OP then

[wooowchik]

How much years do we need to bring this awesome piece of tech in the mainstream???? Did microsoft has just failed by investing a lot of money on Monodevelop instead of CoreRt? 😜

[knuxbbs]

How much years do we need to bring this awesome piece of tech in the mainstream???? Did microsoft has just failed by investing a lot of money on Monodevelop instead of CoreRt?

There is no investment in Monodevelop, only in Visual Studio for Mac.

[sgf]

I believe this project is not unachievable, it just needs more resources. At the beginning, this should be a goal to go all out. But now, it is still just an experimental project, which is really disappointing.

[sunliusi]

This tech may bring.net back to the top, and it is necessary to invest more.

This is more useful than grammar sugar.

[trampster]

I wonder if mono is the reason for holding back CoreRT, CoreRT has the potential to be better then mono on blazor, iOS and Android. With smaller deployments and much better performance and faster startup. And that would kill Mono, it would have no other use case anymore. And Microsoft has invested a lot of money into Mono.

[GTANAdam]

CoreRT is lacking so much attention from Microsoft and it's one of the biggest reasons why many developers (including myself) are moving away from .NET, apparently CoreRT is either useless or too much to ask for.

[filipnavara]

I wonder if mono is the reason for holding back CoreRT, CoreRT has the potential to be better then mono on blazor, iOS and Android. With smaller deployments and much better performance and faster startup. And that would kill Mono, it would have no other use case anymore. And Microsoft has invested a lot of money into Mono.

That's blindly ignoring the reasons why Mono is currently the only option on some platforms. Let's ignore for a moment the fact that Mono is shipping in products while CoreRT is currently community maintained project (where the community overlaps with the core CoreCLR developers). Let's also ignore the question of support and politics and focus on the technical details:

• Mono supports Full AOT mode with sharable value-type generics. This is something that is important for F# and couple of commonly used libraries. Now I am not arguing that people should use these features but it's part of the "it just works" story for platforms like iOS where the code works; albeit with bad performance. .NET Native supported them and the work was done in the closed-source part of the compiler backend. CoreRT uses RyuJIT as the backend where this is not supported at the moment. There were some discussions about introducing the support in RyuJIT but it's a lot of work that only benefits very specific scenarios.
• Mono can use LLVM as code generating backend. This is important for multiple reasons. Firstly, it makes porting to other platforms easier. Mono currently runs to some extent on PowerPC and IBM/z machines. Secondly, platforms like watchOS require the code to be compiled into LLVM bitcode instead of machine code. CoreRT cannot do that with the RyuJIT backend. It does have some support for using LLVM as a backend as part of the effort to support WebAssembly but that's one of the less mature parts of CoreRT.
• Mono has interpreter that can be used on some platforms to supplement JIT for dynamic code. CoreRT has a skeleton for the interpreter but it implements only few instructions and it's not in any way usable in its current form.
• Mono has rich embedding API that is currently used by many products (Xamarin.[Mac/iOS/Android], Visual Studio for Mac, Unity, etc.). This may or may not be an advantage but ditching Mono would require all those integrations to be rewritten.

Mono also managed to be quicker to bootstrap the support for the WebAssembly platform. It started with the interpreter and gradually evolved to get AOT support with the LLVM backend and mixed mode as a combination of both. Apparently the size restrictions don't favor WebAssembly AOT at the moment and it's not obvious whether CoreRT would do substantially better job here. The code generator would be powered by the same LLVM backend and the issue is not the size of the runtime itself (where CoreRT would win hands down).

CoreRT is technically amazing in many ways but in other ways it's years behind Mono for different uses cases. With .NET 5 there is renewed focus on AOT compilation across the board. Mono is only one piece of that puzzle. The other one is to reduce the number of places where dynamic code is used or required. Roslyn is finally going to ship source generators and there's interest in using them as a way to reduce dynamic code in serializers (and many other use cases) while offering better performance for everyone. These other pieces of puzzle are the things that make CoreRT more compelling option in the future and indirectly benefit it, if at some point someone wants to make it a product or give it official support.

[jeswin]

@filipnavara Those are all great points. But the universe of people who will benefit from super-fast native performance is way bigger than those wanting support for PowerPC/IBMz, or those who need an interpreter, sharable value-type generics etc. I've used Mono for more than 15 years and .Net for nearly 20; and neither .Net nor Java will ever get to true native-code class performance.

People would love an alternative to manual memory management or having to learn Rust. Hence the increasing support for CoreRT. The ability to increase the density of apps on servers will benefit the environment as well.

Add: CoreRT works quite well already. The thing holding back many people is the lack of a firm commitment from Microsoft.

[davidfowl]

We think this is an important scenario but I'm not sure everyone (myself included) understands the scope of what's "good enough" in terms of the following:

• Is it OK to throw away reflection (and managed metadata)? Is that just an option or is it required to get into the range of binary size people want?
• Are people building applications targeting CoreRT specifically and understand the various tradeoffs? Or do they expect all of the .NET libraries to work like normal and still have small output.
• Another way of putting the above point is, do all of the frameworks that we ship have to work with CoreRT? ASP.NET, Winforms, EFCore, WPF, etc.
• What about 3rd party NuGet dependencies? Serializers, Unit testing libraries, Mocking libraries, DI libraries. Things that people have grown accustomed to working on .NET for the last 20 years.
• Are people running in environments where JIT isn't possible (iOS like, no writable pages?)?

One thing everyone does agree on is the fact that the tooling is immature in this area:

• It's hard to relate how code impacts binary size. We see this today for our own libraries. Very few engineers understand code/binary size tradeoffs.
• It's hard to understand what code will break as a result of linking when more aggressive modes are turned on.

Those tooling problems make it hard to build a reliable ecosystem around AOT compilation in .NET. Not knowing when something breaks pushing this into the niche corner of the ecosystem where advanced users will put in the effort to get really small binaries but the average user wouldn't have a chance. The same goes for library authors. People who want CoreRT scenarios to work will file issues on library authors asking them to change their code (to avoid bad patterns) but it's no good if library authors cannot maintain those changes with confidence (what's to say a later version won't break things again).

Beyond that, we struggle to set specific goals around binary size, startup speed and working set.

• How small is small enough? What type of application is the ideal one to target for the smallest application we would reasonably target? Or do we just pick a size based on arbitrary options/dials we offer.
• How fast does startup need to be and what scenario should we optimize for? Command line tools and Desktop UI applications shine for this, is that a reasonable thing to aim for?
• Small working set can be accomplished in various ways (like tweaking the GC). I see mention of Rust here, are people hoping for a no GC mode with CoreRT? This one I don't quite understand.

PS: CoreCLR is an AOT + JIT hybrid. If it was all JIT it would be horribly slow.

The good news is that we do work every release that benefit CoreRT like scenarios. Making more scenarios work with the linker will accrue to some of the questions above (like Blazor for e.g). As @filipnavara mentioned, source generators in roslyn will unleash new ways for developers to generate compile time code vs generating runtime code.

All that to said, I would love to talk to some people on this thread who have already adopted CoreRT to get a better idea on some of those questions.

cc @samsp-msft

[lukemcdo]

Everything I've seen so far points to no plans to bring .NET Native to .NET 5.0. CoreRT would be an exciting release option for a solution that uses .NET 6.0 (or whenever it lands) with WinUI 3.x to achieve similar performance on similar code bases.

App size decreases on Android and iOS would be pleasant, but startup time decreases would be more exciting and not all of that is held up by Mono AOT.

If CoreRT mostly existed as a more cross-platform .NET Native but with cross-platform capabilities, I'd be thrilled. Any additional reflection capability should be opt-in at build time.

To talk about what frameworks should be supported: I'd expect gRPC, WinUI, and Xamarin bindings. Web servers traditionally don't worry about startup time to the same degree that desktop apps do, but microservices might. I think guaranteeing Kestrel works from CoreRT would be a good compromise, and then see what people come up with.

[trampster]

@davidfowl My use case for CoreRT is an embedded arm environment, I care about size and startup time. The cpp programs we make currently use are about 2 mb.

We currently use cpp and python, the python programs are small but to slow to start, the cpp programs are small and fast to start but take to long to program and have awful memory errors.

I think users of corert should have the option of having reflection or not having reflection, along with tooling that warns them at compile time if there code uses reflection and they have it turned off.

[jkotas]

I have a document with a technical roadmap for .NET runtime form factors in the works for a while. It takes time to get all stakeholders agree with something this, incorporate their feedback, etc. I hope to be able to make it public soon.

One of the key observations in the doc is that the .NET libraries are designed for the globally-installed general-purpose .NET runtime that is the dominant form factor today. The moment one goes to other places - whether it is optimizing for size, single file, native (full) AOT, or constrained environments like WebAssembly - things break in unpredictable way.

As @filipnavara and @davidfowl pointed out, the work we are doing for .NET 5 is a start of the journey to address this, and that’s not an accident.

[charlesroddie]

@davidfowl Is it OK to throw away reflection (and managed metadata)? Is that just an option or is it required to get into the range of binary size people want?

Yes. But it's not just OK, it's great.

Small binary size, performance, and compatibility with JIT-constrained environments are all important.

But the other great feature that disabling reflection would bring is safety. Reflection makes static analysis hard, and makes code hard to reason about: this applies to linkers but also to humans. It circumvents the type system and runtime reflection prevents the usual static analysis that keeps code safe from bugs. We see more reflection bugs than NRE bugs actually. Just like nullable reference types, reflection-free modes will decrease the cost of producing reliable software.

Another way of putting the above point is, do all of the frameworks that we ship have to work with CoreRT? ASP.NET, Winforms, EFCore, WPF, etc.

Not CoreRT per se, but we would like all targets (ASP.Net, Winforms, WPF, Android, iOS, UWP, MacOS) to work with AOT and linkers, and to work in the same way. Without runtime errors, and at least without runtime errors that are platform-dependent (which we get now because AOT in UWP, iOS, Android all work differently).

Release mode = AOT is the right approach for all targets IMO. As part of the development process reflection is useful, but not at runtime when you don't want the loss of safety, performance overhead, and incompatibility (https://docs.oracle.com/javase/tutorial/reflect/).

What about 3rd party NuGet dependencies?

These should be automatically analyzed and added as a "requires reflection" label. That will carve out a safe part of .Net and encourage people to use that part. E.g. through attributes which would allow linker compatibility analysis.

[filipnavara]

You don't understand why people want to go AOT, they want speed, fast startup, low mem footprint

I do understand that and I am in the same boat here.

What you fail to understand is that the current implementation of CoreRT is too restrictive and lacks some of the features that I would need to get there.

I cannot use it on WinForms application because we require some COM interactions that are not implemented; even small things like clipboard and drag and drop are COM-based. Now there's some distant hope for me because CoreCLR started shifting some of the implementation of COM CCW/RCW to managed code which would benefit any effort to implement it on CoreRT.

I cannot use it with Xamarin.Mac because it doesn't have the same embedding API.

Some of these features could be implemented but it's non-trivial amount of work, and these are just two use cases where CoreRT already has the necessary code generation backend and the app has trivial amount of dynamic code.

They don't want to ship a JIT and an interpreter that's gonna slow things down..

You live in your ideal world. Again, if you can avoid it, good for you. There are platforms where you cannot easily avoid it today (iOS and some WebAssembly scenarios). You would seriously restrict what the platform can offer if you don't have it as an option. That may be fine in some scenarios but it will also hurt developer productivity because features like Hot Reload cannot be implemented without it.

Those are all great points. But the universe of people who will benefit from super-fast native performance is way bigger than those wanting support for PowerPC/IBMz, or those who need an interpreter, sharable value-type generics etc. I've used Mono for more than 15 years and .Net for nearly 20; and neither .Net nor Java will ever get to true native-code class performance.

My point was that there is an overlap in what scenarios Mono and CoreRT cater to. However, each of them has some specific niche outside of this overlap that it not covered by the other technology.

Super fast native performance, quick startup and small code size are just few pieces of the puzzle. They're great but ultimately worthless for ordinary developers without the other 20% of the puzzle pieces. This is what the excellent summary by @davidfowl above points out. What do people expect to work? Is it expected to work out of the box or is it expected to work with some tweaking?

(Side note: The recent investment in Mono LLVM AOT shifts the balance on the performance scale somewhat. It significantly reduced the performance gap compared to the regular Mono JIT.)

[davidfowl]

But the other great feature that disabling reflection would bring is safety. Reflection makes static analysis hard, and makes code hard to reason about: this applies to linkers but also to humans. It circumvents the type system and runtime reflection prevents the usual static analysis that keeps code safe from bugs. We see more reflection bugs than NRE bugs actually. Just like nullable reference types, reflection-free modes will decrease the cost of producing reliable software.

You mention the downsides but none of the upsides. For example, something as simple as unit test discovery can done easily with reflection. Plugin systems like CMSs, frameworks that allow dispatch based on the shape based on a target method. It’s really an amazing feature that can be used to do great and horrible things 😄.

Not CoreRT per se, but we would like all targets (ASP.Net, Winforms, WPF, Android, iOS, UWP, MacOS) to work with AOT and linkers, and to work in the same way. Without runtime errors, and at least without runtime errors that are platform-dependent (which we get now because AOT in UWP, iOS, Android all work differently).

That’s great feedback because it’s my hunch as well and this is ALOT of work. Not to mention the whole “we’re going to change how your application works in release mode”. It’s easy to break of you’re not running tests against the trimmed binary unless we beef up the tooling to a very high level of confidence.

The level of investment to get those targets all working well is a multi-year effort as we need to bring the ecosystem along for the ride . We even need to learn how to build frameworks that work well with AOT to produce a “small” output binary (in some cases it completely changes the programming model!)

We’ve started thinking about all of these things but there hasn’t been a large scale make everything AOT friendly, we’ve been focused on specific workloads (like blazor wasm).

[queequac]

Hopefully nobody is ditching .NET Native for UWP before AOT with .NET Core 5 improves. (By the way, I do also prefer native code generation over code obfuscation. Kind of nice side-effect.)

[filipnavara]

Hopefully nobody is ditching .NET Native for UWP before AOT with .NET Core 5 improves.

.NET Native is already dead for some time. It was mentioned on last year's Build iirc.

[queequac]

.NET Native is already dead for some time. It was mentioned on last year's Build iirc.

I know. But to be honest, there seems still to be no good successor when targeting UWP. So let me keep hoping that .NET Native still works for a while.