Microsoft releases a preview build of its mysterious 'Project N'

Microsoft releases a preview build of its mysterious 'Project N'

Summary: Microsoft's 'Project N,' now officially christened '.Net Native' -- a new compiler for building faster Windows Store apps -- is available now as a developer preview.


Microsoft has released a first developer preview build of .Net Native, the technology formerly known by its codename "Project N."


.Net Native allows Windows Store/Metro-Style apps to start up to 60 percent faster and use 15 percent to 20 percent less memory when compiled with .Net Native, according to Microsoft officials.

In short, NET Native compiles C# to native machine code that performs like C++.  

"Our compiler in the cloud compiles the app using .Net Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed," explained officials in an April 2 blog post.

Microsoft officials showed off a brief sneak peek of .Net Native late last fall during the Visual Studio 2013 launch.

"This preview release of .NET Native offers you the performance of C++ with the productivity of C#. .NET Native enables the best of both worlds!" said company officials.

The just-released developer preview enables building apps for Windows Store on ARM and x64 architectures from within Visual Studio. "Stay tuned for x86," the blog post notes. While the preview is for Windows store applications only, Microsoft plans to "evolve and improve native compilation for the range of .NET applications," the post said.

Microsoft itself has used .Net Native to develop some of the first-party Windows Store apps that it built, including Wordament and Fresh Paint, officials noted. 

There's a new Microsoft Channel 9 video detailing .Net Native. The developer preview of .Net Native can be downloaded from Microsoft's site.

Microsoft officials haven't said when to expect the final version of .Net Native to be available.


Topics: Software Development, Cloud, Microsoft, Windows 8


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 good

    It has been all stick and no carrot up to this point.... they took away namespaces in managed code with Windows tailored, and told us that the reason for that is "managed is bad", pointing to the Longhorn debacle as an example of why Microsoft had to go that way.

    But where was the incentive to do it, when other than better async support, the massive refactoring of your code to WinRT didn't get you anything?

    This is the shoe that ought to have dropped... and now has. Thank you Microsoft!
    • kind of

      however this still doesn't prevent them from doing it on a traditional .net app. clearly the winRT scenario was better for them as it is much smaller than full blown .NET, but the principles are the same:
      -sophisticated static analysis
      -type generation, heuristics, etc.
      -optimization done on the IL
      -native image.

      even if they only get 90% to 80% coverage, there is a huge incentive to provide them with the hints they allude to in addition to any changes (like not using 20d arrays) if in fact you get this boost. certainly sounds better than being limited to winstore apps, which lets face it, few actually care.
  • so useless!

    if you want native use C++, if you want cross platform use java...
    .nyet is neither and worst of all, it is proprietary!
    FOSS is so much better!
    LlNUX Geek
    • which is why

      and if you want productivity you use C# and why they just announced they are open sourcing the compiler and a lot more of the .net framework. FOSS is indeed better. .NET is free and open source and better :)
    • Why Thank You

      By using non-clever phrasings such as ".nyet," you very usefully identify your message as having effectively zero-content. Saves time.

      I'm not sure this would all fit together, but F#, which is a functional/OOP hybrid language built for the CLR has been donated by Microsoft to a foundation where it is open and non-proprietary. So, let's imagine that one is targeting a Windows device and then think about how Microsoft's affiliated byte-code-to-native compiler could help a FOSS developer take advantage of F# code's compactness, making for a more responsive application for the users. I'm looking for the loss in what otherwise seems to be a chain of win. And, hey doggies, the source and binary of the application — the thing the users actually use — could be FOSS! Mind. Blown.

      It's a tool. If it helps you serve your users and customers better, use it. If not, who cares that it's there? It struck me as stupid that Microsoft of the 00s would avoid protocols and tech because they didn't like the smell of the license. Now that they've turned a corner and headed down the road, the silly ones are the ones, such as you, who choose licensing over delivering a quality product.
    • Ermmmmm ...

      The CLR and C# specs were released back before the CLR and C# were even released and were subsequently standardized by the ISO and ECMA. This then sparked Sun to release Java to the standards bodies.

      Java and the JVM have stagnated in its various committees and working groups. Java is now way behind most modern languages and its performance and scalability is pretty terrible.

      C++ is enormously powerful, but has grown to be massively complex and dangerous and it is terrible from a developer productivity perspective.

      Natively compiling C# while maintaining many of C#'s niceties and safety mechanisms could easily propel C# to be a leading systems programming language that supports the determinism and predictability of C/C++ but without the latter's many dangers.

      Xamarin have already proven the value of natively compiling C# via LLVM, and its great to see Microsoft push forward on this front.
      • "Leading systems programming language" for the Windows Store?

        Sounds like an oxymoron to me.
        • You obviously do not use their tools ...

          so you have no idea what you are missing. I have and Linux needs take a few lessons from MS on IDE tools. They are hands down the best. Development time is way faster. But you stick with 1990 tools let us know how that works for you.
      • Java performance horrible? Lagging in features?

        Hmm, MS Research doesn't seem to agree with you - they rate Java as performing somewhat better on average than C#. (that is - they disagree with you unless you agree with them that C#'s performance is worse, you don't say).

        And Java now has lambdas, and delegates have always been a simple interface definition/anonymous inner class away, etc. etc.
        • Oh, forgot the link

          MS Research blog from Dec/2013 where the blogger bluntly states that Java performance is better than C#:

          From neonspark's posting below.
        • Actually we have been trying to turn

          off Java tools. And yes they are slow and have issues. But nice try BH
        • Java is probably the worst nightmare a computer can have !!!

          Seriously java was pretty modern and awesome 20 years ago but it totally failed to stay updated with current technologies. Java is slow and obsolete
    • LOL really

      Wow I sure have missed your silliness it's refershing to read just asinine comments. Good God please don't stop you are a breath of humorous air.
  • but still .net however.

    like java, it is garbage collected meaning some performance tradeoffs will be inevitable.
    • Even Objective C does some GC

      and it is regarded as being a medium to low level language, like C++.

      In fact, if the mechanism in native C# apps is similar to autorelease pools in Objective C, the new overhead would be negligible. Stuff would be cleaned up when it goes out of scope, not sit in a big runtime pool waiting for the optimizer to set aside cleanup time.
      • actually it is more complex than that

        watch their video, they kept the GC from the CLR so there will be no optimizations in this regard. and we all know the GC is a major drag making horrible use of the heap.