A first hand look from the .NET engineering teams
This post was written by Subramanian Ramaswamy and Andrew Pardoe, Senior Program Managers on the .NET Native team.
We’re thrilled to announce the first release of .NET Native. Windows Store apps start up to 60% faster with .NET Native and have a much smaller memory footprint. Our first release is a Developer Preview that allows you to develop and test apps with this new compiler. 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!
Download the .NET Native developer preview today and tell us what you think. This developer preview currently enables building apps for Windows Store on ARM and x64 architectures (stay tuned for x86.) .NET Native will soon enable a consistent and converged experience across devices. Today's preview supports Windows Store applications. We will continue to evolve and improve native compilation for the range of .NET applications.
.NET Native continues to provide a first-class .NET developer experience in Visual Studio. You still get a great edit/compile/debug environment with productivity enhancers like Edit and Continue and code refactoring. You continue to upload MSIL app packages to the Windows Store. 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.
.NET Native optimizes Store apps for device scenarios in all stages of compilation. We optimized the .NET Native runtime (a refactored and optimized CLR) to make apps start faster and consume less memory. The .NET Native compiler uses the world-class Microsoft VC++ optimizer back-end to make your app run faster. .NET Native libraries are refactored and optimized for Store apps. And .NET Native has the capability to link in library code your app uses into the app, allowing the optimizer to work globally across your app’s code and library code. In the end, your app is optimized for your user’s device, whatever platform, architecture, OS or form factor it might be running. The end result –apps just get faster!
Some of the most popular Windows Store apps on Surface devices are already running on .NET Native. This includes applications such as Wordament and Fresh Paint, which are seeing multi-second startup wins.
Tune into the //BUILD conference for more details. Also, check out the Going Deep Channel 9 Video on .NET Native.
The .NET Native developer preview installs on top of Visual Studio 2013 Update 2 RC.
After your project is loaded, you can enable the .NET Native compiler. Make sure you’ve configured your app to compile for a specific architecture, x64 or ARM. .NET Native compiles to native code, so you need to target a real machine type instead of Any CPU. There are a few ways to do this—in the Solution Property Pages:
Or in the handy dropdowns at the top of the editor window:
Once you’ve selected a supported machine type you’re ready to enable your project for .NET Native compilation. Right-click on the project name and you’ll see the “Enable for .NET Native” option has appeared. (OK, it was always there, but if you selected it without selecting x64 or ARM you’d get an error.)
Selecting this actually causes a few things to happen. First, it creates a new file for your project called “default.rd.xml”. This file contains runtime directives that help the .NET Native compiler understand what metadata and type information needs to be preserved in order for your app to run correctly, so things like reflection mostly just work, even though you are statically compiling everything!
Second, selecting “Enable for .NET Native” builds your app. Visual Studio will also run a static analysis tool on your app to give a quick read on whether you are using any feature that’s not yet in the preview release. This will generate a “.NET Native Code Generation Compatibility Report” that will pop up with information about your app. Also, you can always rerun the static analysis from your project’s context menu.
If your app is like most Store apps, you’ll see this in the Compatibility Report, meaning you’re ready to test your app thoroughly with .NET Native.
If your app uses many complicated patterns or yet to be implemented features (e.g., WCF), you might instead get some workarounds and guidance. We’ll dive into each and every topic but for now if you run into any issues, please send us feedback, either in the .NET Native forum or by emailing us directly at dotnetnative@microsoft.com.
We look forward to hearing from you! Get the new VS Update, download the .NET Native Tools, start making your apps faster and tell us what you think!
Update: A number of the questions that have been asked in the comments are addressed in the .NET Native FAQ.
Will this support a WPF desktop application?
@Sean: The .NET Native Preview released today only targets Store apps but we're working on improving native compilation for all .NET apps. We've already answered this question, and a lot of others, by the way, at the Microsoft .NET Native FAQ: msdn.microsoft.com/.../dn642499.aspx.
Would this require a certain version of the .NET framwork on the target machine?
@John: Also answered in the FAQ :)
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
This is great! And makes a lot sense in the server side, for critical mission applications, where performance matters a lot.
Yes, this could really help our desktop WPF app! Will I be able to compiler a C++/CLI DLL with .NET Native and then link that with my native C++ .exe?
Let's hope the team moves on from WinStore silliness to Desktop asap.
Fantastic! Question: once this is baked, what reason would I have to NOT use it for a store app? What about other apps (once supported)? Why would I want the .NET framework to ever be required on the target machine?
Are there any plans for Azure support?
When a .NET application is compiled for native, are there also some kind of PDB symbols generated as well? I am concerned about supporting such an application after deployment. In the event of a bug / hang / crash, dumps will need to be taken. There must be a reasonable way of mapping the native code back to the original source in .NET. Could you please elaborate a bit on how you plan to support this scenario?
@jps: The .NET Native Preview currently allows development only in C#.
@Kent: There's no reason to not use it for a Store app. Start evaluating it, now! :) This preview only supports the Windows Store profile and the .NET Framework supports a wider set of APIs. Keep in mind that not all scenarios are suited for static compilation, thus, we are also investing heavily in our dynamic compilation story simultaneously (checkout RyuJIT @ blogs.msdn.com/.../ryujit-ctp2-getting-ready-for-prime-time.aspx).
@Jamy: Currently this preview only supports Windows Store apps. However, as we mentioned earlier, we are continuing to evolve and improve native compilation for the wide range of .NET applications.
@Ben: The .NET Native compiler goes to great lengths to make the mapping back to source code possible while debugging, even with native code! The symbol information is passed through at every stage of compilation to make this possible. And yes, the compiler does generate a PDB that allows you to debug crash dumps.
@Subramanian "The symbol information is passed through at every stage of compilation to make this possible. And yes, the compiler does generate a PDB that allows you to debug crash dumps. "
Awesome. Thanks. Was wondering that as well.
I can't find this in the Eclipse IDE?
Will .NET native be able to support dynamically loading assemblies? We have this even in our Windows Store app.
Would be very nice to have this in WPF applications so we can use it in the real world.