dotnet VS corert

Not https://github.com/CommunityToolkit/dotnet

Here's some: - MVVM Toolkit - PolySharp - ComputeSharp

Started programming by writing some apps for Windows Phone later UWP during university. A few years ago I started collaborating a lot on GitHub to some Microsoft projects, like the Windows Community Toolkit. There I created a lot of new APIs and libraries, like all the new animation APIs and pipeline brush APIs, etc. I then also proposed adding some general .NET APIs to it, and that's how the MVVM Toolkit was born, along with other libraries which are now moved to the .NET Community Toolkit. Fast forward until about late 2020, and they pinged me saying the new Microsoft Store (which hadn't been announced yet back then) was using several of those new APIs I had written, so we started collaborating more so that I could add more functionality they needed. After that shipped, at some point there was a new opening to which I applied, and here I am in the Microsoft Store team and also leading the .NET Community Toolkit 🙂

This is tracked by https://github.com/CommunityToolkit/dotnet/issues/409. The issue is likely that AppCenter image using an older version of Visual Studio (and Roslyn). The MVVM Toolkit needs at least Roslyn 4.0 (ie. Visual Studio 2022) in order to work. Unfortunately this is not something we can change from the MVVM Toolkit, you have to open a support request for AppCenter to ask for a newer Roslyn version, or see if there is a way for you to enable that in your pipeline 🥲

The toolkit's:

https://github.com/CommunityToolkit/dotnet/issues/224 - one ask and fix.

Yeah, the fact properties use fields with annotations right now isn't ideal, it's just the best we could do until C# gets partial properties. I do plan on adding support for that though as soon as C# gets that feature. You can follow the progress here 🙂

For comparison, CommunityToolkit.Diagnostics has a guard library.

There is some stuff in CommunityToolkit to lower allocations of frequently converted Spans, StringPool comes to mind.

Most likely this: https://github.com/CommunityToolkit/dotnet/blob/main/src/CommunityToolkit.Mvvm/DependencyInjection/Ioc.cs

An explanation of the problem: https://github.com/dotnet/corert/blob/master/Documentation/u...

Memory was not really designed for having lots of instances of it and doing intensive computations/searches on the instances. The reason for it is that Memory.Span property is actually quite expensive to call. Memory is a union type for storing strings, arrays, and even handles to native memory. Every time you construct it , slice it, or retrieve it's span, lost of machinery related to this union has to run. For example see the source for the Memory.Span property: https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/shared/System/Memory.cs#L285.

For earlier versions, try https://github.com/dotnet/corert

Yeah I know it's slower on its own, but I was sure it was handled as a faster intrinsic by the runtime. Went to double check and realized I was actually mixing things up with what CoreRT did (see here) but I guess it doesn't apply to CoreCLR. Would be surprised if there weren't any specific optimizations for this with .NET 6+ though, or at the very least with NativeAOT (given they've been porting some bits over from CoreRT and .NET Native too). Will need to go gather more info on this, as it's pretty interesting 🙂

> AOT compilation? I'll believe it when they'll release it, until then, it's all speculation

Devil's in the details, but there -is- AOT compilation[0]. While it hasn't been released as an official product, it has been used for a few projects including a commercial game [1]. And yes, they're looking into the next steps to make it a 'released' thing.[2]

[0] - https://github.com/dotnet/corert/

[1] - https://github.com/dotnet/corert/issues/8233#issuecomment-65...

[2] - https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

That is a well known issue, also what prevented F# to be properly used in .NET Native.

https://github.com/dotnet/corert/issues/5780#issuecomment-40...

CoreRT