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
• Assembly.GetSatelliteAssembly
• Handling of exceptions thrown out of a module initializer
• Thread.Interrupt
• System.Runtime.InteropServices.ObjectiveC
• Constructing delegates outside verifiable delegate sequence

[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.

[hez2010]

similar to how CsWinRT does it for WinRT

Unfortunately, CsWinRT is not aot friendly at all. You may want to see the disaster: https://github.com/microsoft/CsWinRT/blob/c181cb45f2b92d663a736e966982c93516403f21/src/WinRT.Runtime/TypeExtensions.cs

[AustinWise]

The last one can be knocked off the list #77472 =)

[DeafMan1983]

Please support for Marshal.GetDelegateFunctionPointer<>() in NativeAot! I tested own GameLauncher with loading native libraries ( ported from Half-Life + Engine without client and server ) GameLauncher uses PublishSingleFile and PublishTrimmed and Engine ( native library ) uses PublishAot, StripSymbols. I am excited to release game written in C# because I want release games in 64Bit. If GameLauncher should use PublishAot, StripSymbols and native executable.

[jkotas]

Please support for Marshal.GetDelegateFunctionPointer<>()

Function pointers are more performant and AOT friendly replacement for Marshal.GetDelegateFunctionPointer. Can you use them instead? If you need help with how to switch to function pointers, please open a new issue or discussion on it.

[am11]

Sorry to bother, but what about Assembly.Load, Assembly.LoadFrom or AssemblyName.GetAssemblyName ?

Seems like GetAssemblyName works with .NET 8 and 9: AssemblyName.GetAssemblyName("/path/to/foo.dll")