Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Inside .NET Native

39 minutes, 34 seconds


Right click “Save as…”

What happens when .NET code is statically compiled to machine code (versus runtime compiled via JIT) by the VC++ back end compiler? You get highly optimized binaries that load and run faster than .NET code ever has before. Yes, my friends, .NET has gone native! :)

Today, the .NET team is releasing a preview of their new compiler technology, .NET Native. You can generate .NET native binaries for Windows Store apps only (in this preview). Tune in and meet a few key members of the .NET Native team, PM Mani Ramaswamy and Dev Lead Shawn Farkas. We go deep and Shawn spends quality time at the whiteboard. The team has done a lot of work to get where they are today and no part of .NET has gone untouched, from a new CLR to optimized BCL. This project is a natural extension of the MDIL work that was done for Windows Phone 8. It's all about highly optimized .NET for modern hardware - that the VC++ back end is turning IL into highly optimized machine code is a very, very good thing - for developers and, especially, users!

Note: Shawn and a fellow engineer will be on C9 Live at build on Day 3, so please watch this and prepare questions to ask them live, right here on C9 (details to follow).

Go native!


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • omarioomario

    How is it related to Ryujit, C# for systems programming and plain old NGEN?

  • Sam Covingtonsamcov Which pill did I take?

    When will this be available for server apps?

  • felix9felix9 the cat that walked by itself

    there there, this is what I am talking about :)

  • MoonStormMoonStorm

    All I need to know if this is going to lead to unified cross-platform development, as currently we're stuck with a single cross-platform .NET implementation that lacks any kind of competition, and as you may have guessed, I'm not talking about Microsoft's.

    Many of us have already moved away from C#, which is a shame considering the beauty of the language, just because Microsoft insists on having it on their OS environments only.

  • @10:30:

    "Is this code really used? Do we need to pull this code in? Not really, so we can keep that aside." 

    Do these new static analysis tools allow tree shaking (like Dart)? Could they be applied to vanilla .NET assemblies as well?


  • Answering my own question: yes (@17:25). Someday I'll learn patience. :\

  • This is awsome, love to see some numbers on other work loads, for server apps in perticular

  • @MoonStorm: Maybe it will compile native for Linux using Mono converted to Native.    Microsoft could offer this as a cloud service .  Compile your app native for Linux for x dollars.   They make money even if you use Linux so they have a business model for doing this work.   It would be stupid to support cross platforms unless money can be made so don't expect it for free.

  • Brent MorrisBrentMorris​RTP Living the Dream

    Stunning Amount of Details. Thanks for the POST. I will use the Beta, just for the Static Testing warnings. This mean that I can see new project "hit" any of the "Beta walls" as the project lifecycle gets rolling. Great work folks. :D

  • Brent MorrisBrentMorris​RTP Living the Dream

    Please tell the Xbox Music & Video Teams to STOP using Java Script and convert to Project N - Thank You.

  • @omario: First, there's a blog post on the .NET blog and an FAQ linked off of aka.ms/dotnetnative. I can't provide links because Channel 9 keeps marking my posts as spam.

    With regards to RyuJIT, the .NET CLR team is investing in both static and dynamic code execution strategies. Different scenarios demand different tools, or a blend of both.

    With regards to C# for systems programming, you can learn about that by Binging for "M#"

    With regards to NGen, .NET Native compiles completely down to native code that doesn't depend upon the CLR installed on the machine. NGen isn't always fully native and requires the CLR and .NET Framework to be present.

    --Andrew Pardoe [MSFT]

  • @samcov: Server apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.

    Check out the FAQ linked off of aka.ms/dotnetnative for more answers to common questions.

    --Andrew Pardoe [MSFT]



  • So would this enable you to run .NET code without the .NET framework?

    I'm mainly thinking about C# code being used by installers, where a dependency on the .NET framework is less than desirable.

  • @JohnLudlow: Currently .NET Native only works on Windows Store apps. Desktop apps--like your scenario--are important to us though. Thanks for the feedback!

  • @apardoe:Yeah I think the desktop is going to be around for a while. I missed that desktop wasn't currently supported, but I'm glad you're thinking about it.

    I gotta say, "the convenience of C# with the performance of C++" is one heck of a selling technique! :) 

  • HamedHamed

    Thank you! :-)
    This is awesome, the best news of Build for me. More important than the performance, which is great by the way, this seems like a start to (finally) port .Net across multiple platforms (Android/iOS in the future maybe?!) A questions though:

    How does this relate to Universal Apps? I mean why would anyone use that while apparently, in the future .Net Native is going to support both phone and store apps, and also desktop and server? This becomes much more universal, right?

  • Sander van RossenSander van Rossen

    Are there also optimizations when it comes to avoiding cache misses? That's the biggest performance killer after all..

  • MtVernonCannabisFarmsMtVernon​Cannabis​Farms

    40% is a gen of hardware , if the hardware guys can still pull it off.
    a gen of hardware is billions , both upsteam and out of users pockets

    stock options wouldn't seem out of the question

  • martinminemartinmine I eat C# for breakfast

    Imagine when this applies to any .NET code in general. Then the Java kids can't just say "Java bytecode runs about as fast as native code" when .NET code gets compiled to native code :D 

    This is amazing work! Imagine the performance increase and no more obfuscation of code, why hasn't anyone thought of this earlier?

  • bank kusbank kus

    Does the final native binary contain profiling hooks. I understand precompiling to the target architecture for faster startup. But are there profiling hooks to perform runtime profile based optimizations (*) or is it at this point no different than a C++ application compiled statically.

    (*) Class Hierarchy Analysis, method devirtualization, inline caches, lock elision, JIT is a lot more than just dynamically compiling from IR to native, a large part of JIT runtimes also dynamically optimize. Curious if any of that is available when using .NET NATIVE.

  • HerbHerb

    I have been leaning to GO as I wanted native with garbage collection for backend server work. Bring it to Linux and now you really got something.

  • kevinkevin

    one thing hasn't been mentioned here is the server side tech such as asp.net and wcf. I guess it's against the cloud strategy. oh well..

  • VaitheeVaithee

    This great work, particularly the fact that all optimizations are agnostic to app developers, hopefully does not add significant time to publishing process. Question I have is when is this goodness coming to cloud/azure and server/web apps ?

  • David AndersonDeadX07 Microsoft Partner (MSP)

    I have a question. Does this mean that Visual Studio team will be using this technology when compiling the IDE itself, so that the startup times and performance of Visual Studio can take advantage of these benefits?

  • TiffTiff

    @Andrew: Can you give us any idea of when .NET Native will support standard desktop applications?

  • @Sander van Rossen: As of today, the .NET Native Preview links in all library code and passes it to the C++ optimizer to perform global analysis and optimizations that will include locality optimizations as well.  

    @bank kus: The .NET Native Preview does support profiling through ETW tracing. While .NET Native Preview is static compilation,  we're also investing heavily in dynamic compilation technologies also via the RyuJIT compiler (http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx).

    @kevin, Vaithee, Tiff, DeadX07: While the .NET Native Preview today targets Windows Store apps, we're investing heavily in improving native compilation for all .NET applications.

    Check out the FAQ @ http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx for answers to many more questions.

    Mani Ramaswamy [MSFT]

  • bank kusbank kus

    >> We're investing heavily in dynamic compilation also via the RyuJIT compiler

    Can I press some further on that please? To be clear, the native binary has (will-have?) provisions to Dynamically Profile (via ETW?) and then patch call sites based on Dynamic Compilation? So I can expect a frequently executed call-stack say from within a loop to be inlined dynamically


  • @bank kus: Sorry if I wasn't clear.  My statement was that the .NET team was supporting both static and dynamic compilation technologies (with different products)

    Since .NET Native is static compilation, all code has to be compiled statically and generated at compile time. Based on runtime characteristics, one may be able to conditionally exercise the more optimal code path, but all code has to be generated before hand.

    Today, the.NET Native Preview will not patch call sites to answer your question.

  • TiffTiff

    @ramaswamy: Thanks for the response. I saw your video as well and I do get that you guys are working on something for traditional desktop applications as well BUT may not be able to disclose specifics at this point.

    I was asking about a timeline because I'm working on a commercial application and we're thinking about leaving C# in-favor of C++ - primarily because of performance and IL decompilation issues. If there is a chance that .NET Native for Desktop apps could be out within next 4-5 months...then we'll definitely stick with C#.

  • Jeremy MorganJeremyMorgan​DotCom Beta is greek for "still doesn't work"

    Is the performance gain only contained in the startup of the application? Will a statically compiled application run at the same speeds as a JIT app that has been compiled? 

    Not trying to discount the news in any way, but I'm just curious. It seems like this would improve things, and the biggest thing IMO is the elimination of need for the .Net Framework install. The idea of a completely self contained application is nice. I haven't released a desktop application for quite a while, but I remember the framework install/upgrade being a pain point for customers, as strange as that sounds. 

  • zenholdzenhold

    Totally diggin JeremyMorgan's Post!
    Is the speedup only at startup or also at runtime?
    Will we in the future be able to deploy .Net-Framework Libs just with our binaries so that there is no need for a pre-installed .Net-Framework?
    All that sounds so promising! C# &. Net building the Bigroad for the future Development : )

  • Daniel Earwickerdanielearwi​cker I used to be language agnostic, now I'm language atheist

    Just adding my voice to the clamour for Desktop support!

    Would love to see a way to statically link those parts of the .NET framework that I'm using into a native code EXE or DLL, allowing it to be used to write shell extensions, office extensions and other kinds of native components that have previously been hamstrung by heavyweight side-by-side runtime versioning issues.

  • ChrisChris

    Add me to the list of people that really wants to see this for desktop apps and not just Windows Store apps (which no one I know uses!)

  • MariusMarius

    Tell me if this is an ill-founded question, but, does .NET Native, when it supports normal desktop apps, mean that native C++, even C++11 and beyond, will finally be superseded? C++ is great, I love C++, but I also love the simplicity and ease of doing things in C# (thanks to the vast library of objects and types of .NET which C++ does not have).

    Put another way - does .Net Native enable a developer to do everything that a native C++ developer can do? Write OS kernels, for example?


  • RoiRoi

    Curious how this will impact SQL Server's support for .NET code. The world pretty successfully hid it's appreciation of SQL support for .NET code, but if the performance penalty visa-vie C++ could be mitigated, a lot of finance's arbitrarily complex calculations could be triggered only for updated or added rows, making for an easy to manage coherent data set without the need for massive and redundant bulk recalculations.

    BTW, has anyone at MSFT noticed that while Linux has massively better support for timers, the choice of database there is pretty much Larry Ellison and larry ellison (mysql)? Could somebody P-L-E-A-S-E port SQL Server to Linux???

  • S TenS Ten

    Of course Visual Basic 6 (VB6) has done this for years. It combines better productivity (by using the VB6 RAD) with the performance of C++ (by using the C++ compiler).

    Pre-compiling C#, rather than JIT compiling, will speed up loading time, though not necessarily performance. This is long overdue.
    Of course, the backend compiler for this is the C++ compiler – just like the VB6 programming language has used since 1998 !

  • I am working on project C# native compiler which uses LLVM to compile native code.

    have a look here for more details   http://csnative.codeplex.com

  • MiekMiek

    The big question is, can these so called "native apps" be reverse engineered to near source code just as regular .net MSIL executables can? If so, I don't see any benefit for us developers apart from a little speed increase on sluggish Windows tablets. Another microsoft initiative that was sprung onto the developer community without consultation. Like the other guy said, why haven't you already made native compilation available for thick desktop .Net applications? Poor planning and strategy from microsoft yet again.

  • issamissam

    Desktop apps please !

  • RyiosRyios

    Suddenly, I see a future where AAA games are built in c# for windows and compiled to native code!

    Also, will this allow us to have official support for Exporting public static functions like a traditional dynamic link library?

  • @Alexander77: As I know when any app starts up for the first time, the IL code gets converted to native code, and then the app runs as good as native apps. The start-up time is faster for native apps. Libraries can benefit by going native. Native libraries run in the shared process space and can be shared by multiple apps (unlike managed libraries which run in the private process space of the app).

  • Does anyone know if this would work for ARM based windows CE 5 devices? (i.e. not Windows Store)

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.