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 (https://github.com/dotnet/runtimelab/issues/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
• [x] 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 https://github.com/dotnet/corert/issues/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 https://github.com/dotnet/corert/issues/5011#issuecomment-408715555 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 https://github.com/dotnet/runtimelab/issues/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")