.NET Runtime VS runtimelab

StopTheHostException should be made public to be dealt with gracefully #60600 - GitHub

I ended up filing an issue on GitHub. They then filed a new issue which is still open today.

How .NET Framework (or latest .NET) implemented a certain function / feature, how it varies different design / implementation decisions in reality, etc. (remember 1. the latest .NET is open-source under MIT license. 2. .NET Framework 4.8 Reference Source is not; it is under a thing called MS-RSL. But still you can look at it)

Most of the article basically describes a workaround that Microsoft themselves needed to implement because .NET Core and .NET Framework don’t support in-process side-by-side hosting: https://github.com/dotnet/runtime/issues/53729

runtime/src/libraries/System.Security.Cryptography.Cng/src/System/Security/Cryptography at main · dotnet/runtime (github.com)

There are much better APIs now on types such as Aes, HMAC and IncrementalHash, with support for one-shot operations and Span interop. Your best friends are the API docs, .NET API browser, and just looking at issues and PRs in the runtime repo such as this, this or this 🙂

which could be due to NTLM incompatibility: https://github.com/dotnet/runtime/issues/887

https://github.com/dotnet/runtime/issues/49397 and https://github.com/dotnet/runtime/issues/63331 go into more detail about the APIs that are being added, with just Shuffle left to implement.

Don't forget the experimental native AOT compiler - https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

Good choice of words. Indeed, one nonetheless can compile their app to native code without IL at all, for example, via NativeAOT

You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2].

The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code.

[1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/...

[2]: https://github.com/dotnet/runtime/issues/61231

Can you share any resources how to build such a DLL? I found this document, but it sounds like it would produce an EXE rather than a DLL: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/compiling.md

Here

> “.Net has almost the same performance as Golang and Rust, but only after 1k iterations(after JIT).”

Additions like async/await and nullable reference types make it easier to write bug-free code, which for a lot of folks is a better trade off than “speaking to the hardware directly”.

.NET also runs natively on a bunch of platforms now, including ARM.

I’d call all of that continuous improvement. Perhaps even reinvention?

[1] https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...

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

[3] https://www.techempower.com/benchmarks/#section=test&runid=5...

For example, ordinary IoC containers depend on reflection emit. Such an approach will not work on platforms where AOT compilation is supported. They will throw an error in runtime. The AOT compilation is supported in Xamarin, Unity and Native AOT So, if you want to use AOT compilation to improve startup performance and ioc container then the source generation is a single option.

Some of the work is being done here as well parallel to CoreCLR repo. https://github.com/dotnet/runtimelab/tree/feature/NativeAOT