Microsoft details its strategy for compiling Windows Phone apps in the cloud

Microsoft details its strategy for compiling Windows Phone apps in the cloud

Summary: Microsoft has taken the wraps off its cloud-compilation architecture for Windows Phone. Here's how it works.


One of the new development concepts introduced with Windows Phone 8 is compiling applications in the cloud. But what does this mean, exactly? 


Among the hundred-plus developer sessions that Microsoft execs presented at the company's Build 2012 conference (and which are now viewable for free by anyone, not just conference-goers) was one touching on Microsoft's cloud-compilation strategy.

The Softies first mentioned intentions to provide compilation in the cloud in June 2012 -- when Microsoft first opened up about some of the features coming in Windows Phone 8. Details were scarce, other than the fact that Microsoft, and not individual developers, was expected to be the one doing the compiling of apps once they were submitted for approval. Up until last week, Microsoft officials declined to say anything further about how cloud-compilation would work for Windows Phone.

(One thing we did know is that cloud compilation is/was part of Microsoft's strategy to insure that existing Windows Phone 7.x apps work well on Windows Phone 8.)

There's now more publicly available information. In addition to the aforementioned Build session, a new Microsoft Channel 9 "Going Deep" episode digs even further into cloud compilation, which Microsoft is advertising as enabling "really fast startup of Windows Phone 8 .Net apps."

The way this works behind the scenes isn't via NGEN (Native Image Generator) reimagined. (Ugh. Did I really just use the "R" word?)

NGEN is a tool for improving performance of managed applications byusing native images stored in cache rather than a just-in-time compiler. Instead, according to the Going Deep presentation, Machine Dependent Intermediate Language (MDIL) is at the core of Microsoft's compiler-in-the-cloud solution. Microsoft officials are claiming that the linking step on devices that convert MDIL assembly to a native image takes one-fifth of the time as traditional NGEN on device.

"Thus, we get some of the benefits of both pre-compilation (since we are executing off the native image where all instructions are assembly instructions) and JIT-compilation (no heavy compilation on the device during framework updates)," the Channel 9 session abstract says.

Here's how Microsoft is describing the process to Windows Phone developers:

"When you build your app in Visual Studio, the code is not compiled into a native image, but into a machine-independent Common Intermediate Language (CIL) binary file. (CIL was formerly known as Microsoft Intermediate Language, or MSIL.) This CIL file is what you submit to the Store when you’re ready to sell your app. At that time, the binary file is converted from CIL to optimized Machine Dependent Intermediate Language, or MDIL. Finally, when the user downloads your app to a device, the MDIL file is linked to produce a native image. These steps are repeated in your development environment whenever you deploy your app to a Windows Phone 8 device.

"The functionality of your app is not affected by the conversion to native code. However, the native image typically starts and runs faster."

If you want to know more about MDIL, you might want to check out Microsoft's patent application for the technology. The inventor is listed as Peter Sollich (who appears in the Going Deep talk about cloud compilation). (Thanks to Charon at for digging up the patent.)

I'm curious if Microsoft will make use of this cloud-compilation on the back end on the Windows 8/Windows RT side of the house. If I hear more on that, I will add any comments to this post.

Meanwhile, any Windows Phone app developers out there noticed any performance differences or other tidbits as a result of this new cloud-compilation capability?

Topics: Smartphones, Cloud, Microsoft, Patents, Software Development, Windows


Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • This is actually pretty brilliant...

    I can't really say much more, but talk about catering to and helping developers.
    • just proprietary crap

      unlike M$ binaries, java has device independent bytecode that is so much better on the phones. That patent is as usefull as a patent on the warp engine, nobody cares about it!
      LlNUX Geek
      • Java sucks

        Is that what gives Android the trademark "sluggish delay" with every touch?

        Proprietary? Take your pick, M$ or Ora¢le.
        • huh???

          you must be a M$ shill or apple brainwashed sheep to claim this lie!
          The Linux Geek
          • Or anyone that has had to use Java.

            Simply horrid language.
          • Android's trademark sluggish delay

            Can confirm it's no lie. 6 months ago I got an ASUS Transformer Prime, and the sluggishness of this thing was terrible, made an iPad 3 feel telepathic in comparison (went down to a local store to test the iPads to see if they were better). Passed on the tablet to someone else, didn't get anything to replace it yet. Maybe I'll try out a Windows tablet, but next time I won't buy until I try.
      • Sadly ...

        ... your ignorance destroys your argument.

        Had you actually read the article, you would know that .NET uses the standard CIL machine independent 'bytecode' (

        All this new cloud compilation service does is recompile CIL code into machine specific, optimized machine code so that apps start and run as fast as possible.

        But hey, don't let facts distract you from your own ignorance and bigotry.
      • foolish java lovers

        So funny how the guy who calls himself a linux geek is also loves java and blindly shoots down all alternatives. These fools are everywhere... they choose whatever seems most attractive to them based on their own self image without calmly and logically trying to make rational decisions.
  • Wither JavaScript?

    The maddening thing is that there is no JavaScript support on the phone, while Microsoft still seems to be pushing JavaScript (WinJS) on WinRT (Windows Store Apps). It makes no sense.
    • JS belongs to hall of SHAME

      Never before has a language this poorly designed misled so many developers and wasted their precious time.
  • So now the IDE has less responsibility

    Can we have a leaner Visual Studio running on Microsoft Surface or other RT tablets?
    That will be awesome for developers
    • +1

      Ram U
    • Up in the air

      No doubt. You have cloud based word processing -- why not save the source & run the builds up there too?
      • Is'nt that called TFS Services?

        Pop over to you get source control, work tracking, agile planning and Build Services.

        You can easily see continuous build and deployment being extended to Windows Phone, much like you do with Azure deployments.

        And it's free for teams with up to 5 members...
  • Native compilation

    Can I get that for VS on my computer? I'd like to compile my .NET projects natively for better performance... been wishing for that since the beginning of .NET...
    • Re: Native compilation

      What they've done won't make the .NET apps run faster, it just improves startup time. The NGEN tool does something similar. .NET apps do get compiled to native at runtime, if you hit a break point in your source, then in visual studio go Debug Menu->Windows->Assembly you can see the native assembly code. Raw number crunching in .NET isn't too bad, but WPF is a pig. I've even seen recommendations from Microsoft in forums saying that if you want fast screen render speed in WPF, render to an ImageSource using GDI+.
  • What A Stupid Way Of Doing Things

    That means the package that the user downloads is NOT the same as the one the developer submitted. Which in turn means that the developer CANNOT code-sign the final package--they can only rely on Microsoft's assurances of authenticity instead. This is very unsatisfactory.

    Compare Android, where the developer-submitted APK file is distributed unchanged, and you have the developer's signature on it to guarantee that. A much more secure way of doing things.
    • I think it safe to say ...

      ... that code verified and compiled by Microsoft is AG LEAST as trustworthy as the code written by the developer. In some cases, by identifying dangerous or untrustworthy source CIL, users will be protected from malicious/unsafe/unreliable code.
      • Re: code verified and compiled by Microsoft is AG LEAST as trustworthy

        So why bother letting third-party developers write the code then? Let Microsoft do it all.

        Do you want third-party apps, or don't you?