2

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.

Evgeny Ipatov
  • 101
  • 1
  • 5
  • 1
    It is just metadata, no different at all from .NET metadata in a .NET assembly. It describes the types exported from a module. Except that it also works for unmanaged code, you can write such a background task in C++ as well. In fact the format of a .winmd is *exactly* the same as the format of .NET metadata, you can use a .NET decompiler like ildasm.exe to look at it. Nothing particularly mystical about it, this "worry" is nonsensical. – Hans Passant Jul 04 '16 at 12:34
  • @HansPassant My question is how it works together with .NET Native toolchain. – Evgeny Ipatov Jul 04 '16 at 12:48

1 Answers1

2

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

yizhang82
  • 36
  • 2