1. 8
  1.  

  2. 3

    I’ve read this twice, but still a little unsure exactly what’s happening. They mention uploading MSIL to be compiled on their servers for the store, but then they talk about selecting a CPU and native code. I’m guessing they’re referring to separate operations? You still compile regularly for the Store, but if you wanted to test performance to get a feel for native, you can do it locally?

    Are they expecting independent software developers to ship native dotnet code? That seems like a big step backwards from where they are in terms of platform “agility”.

    1. 4

      I found the original article thoroughly confusing as well. This comment on Hacker News, however, explained away most of my confusion: https://news.ycombinator.com/item?id=7520624.

      From what I could gather on a very high level, it’s about caching the native code on Microsoft’s servers, which in turn gets delivered to the user’s device when the app is installed avoiding the JIT compilation overhead. You still upload the MSIL, while “the cloud” takes care of compiling it to native code for every possible target.

      One more interesting tidbit can be found in the FAQ (emphasis mine):

      .NET Native is not just about performance, but also about productivity and a consistent device experience. .NET Native allows you to write code using managed languages and upload MSIL packages as always. However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine.