Limitations that we're not planning to address right now

[MichalStrehovsky]

• Runtime doesn't wrap non-exception throws into a System.Exception (IL allows throw new object())
• Limited support for multi-dim arrays with non-zero lower bounds (can be created in IL or with reflection)
• Type equivalence
• COM (COM interop support runtimelab#306)
• SAFEARRAY and VARIANT marshalling
• Runtime assembly loading (LoadFrom, LoadFromAssemblyPath)
• Collectible assemblies
• Reflection.Emit
• Reflection-invoking static constructors and finalizers
• Managed C++ and C++/CLI
• Varargs (accessible in C# through undocumented keywords only)
• Complex tail calls
• RuntimeHelpers.InitializeArray that cannot be intrinsically expanded
• JMP instruction
• Thorough checking of invalid inputs (might not throw an exception for certain invalid inputs)
• Stack walking from reflection call (reflection-invoking Type.GetType expecting to see the calling assembly of the reflection call)
• String literals don't have the same identity as strings retrieved through String.Intern
• Assembly.GetCallingAssembly from reflection call (reflection-invoked method calling GetCallingAssembly expecting to the reflection caller)
• Assembly.GetSatelliteAssembly
• Handling of exceptions thrown out of a module initializer
• Thread.Interrupt ([NativeAOT] Thread.Interrupt not implemented on Windows #118293)
• Named mutexes on Unix (Support inter-process named mutexes in managed Mutex implementation #48720)
• System.Runtime.InteropServices.ObjectiveC
• Constructing delegates outside verifiable delegate sequence
• Finalizers should not run for objects with unsuccessful class init (.cctor)

[tomrus88]

• COM and SAFEARRAY marshalling

Does it mean WinForms and WPF won't be supported? Because I think both of those require COM support.

[MichalStrehovsky]

We'll need to build tools that convert COM interop into something AOT friendlier before the AOT compiler ever sees it - similar to how CsWinRT does it for WinRT.

There's been a lot of discussions about this e.g. here dotnet/corert#4219.

[darkguy2008]

Sorry to bother, but what about Assembly.Load, Assembly.LoadFrom or AssemblyName.GetAssemblyName ? Since NativeAOT/CoreRT doesn't support Entity Framework, my idea was to put all the EF stuff in a secondary library and then call it with the Assembly functions or Reflection, but it seems it's not even possible. Such a deal-breaker.

However, investigating I found out that @tonerdo dotnet/corert#5011 (comment) did have some success getting Assembly.Load to work with some kind of experimental code/libs.

Is there any way to see this implemented in the short/mid term anytime soon? What can we do (or needs to be done) for this to work? Considering there was a successful test some time ago?

[jkotas]

That would require ability to load managed plugins. We do not have plans to do that as part of this project. There is a lot of discussion on the reasons behind that in dotnet/runtimelab#248.

[hez2010]

Is Assembly.GetEntryAssembly().Location the same? I hit this which returns a null instead of the entry assembly location.

[MichalStrehovsky]

No managed assembly exists after compilation. Native EXE != assembly. This is the same as when publishing single file in .NET 5.