How .NET Native toolchain treat managed .winmd component libraries in detail?
I know that .NET Native merge all managed code from DLLs into one executable and remove unused code when compiling it into native.
But what algorithm is used for .winmd managed libraries? For example, background tasks (such as audio background task) in WinRT are hosted in winmd library and then these tasks are hosted within system-provided native process which dynamically invoke winmd provided classes. How is it compatible with .NET Native concept?
I'm worry that .NET Native might not convert managed .winmd code to native and environment will fallback to .NET runtime to execute code in managed winmd, so abandoning benefits of native compiled executable. Or how is it works?
Please, provide information on this not so clear matter. In MSDN documentation there is no detailed information on managed winmd component libraries and .NET Native toolchain.
I work at .NET native team and I'll be happy to help clarify.
.NET native will indeed convert managed WinMD assemblies into native code, and merge it together with the app DLL (as of today). In order for the background task process to locate the native code for those managed WinRT classes, we also fix up the app manifest to point to the app DLL that now has native code for them. The task background process would happily load the app DLL, and activate managed WinRT types implemented in native code hosted in app DLL, using WinRT activation protocol/ABI. No JITting is required.
As you've suspected, there are some interesting challenges with finding which WinRT classes are activated from native code. Today we conservatively treat all the public WinRT classes in managed WinMD as compilation roots in the .NET native compiler, and everything that is reachable from them. There are some implications in size, but that's the trade off with not having a JIT available.
Thanks, Yi Zhang