Bringing the full power of the Windows based CLR and .NET Framework to the Windows Phone has been several years in the making. The .NET capabilities introduced with Windows Phone 8 builds upon many of the investments we’ve made across all platforms and years of incubation. This release truly highlights some of the enduring themes behind .NET – broadening platform support, increased programmer productivity and easily improving app performance. With so much to share, Pracheeti Nagarkar – the program manager driving the CoreCLR work for Windows Phone – provides highlights of what you get with .NET on Windows Phone 8. --Brandon
In this post, we will look at the improvements that have been made for Windows Phone apps in Windows Phone 8. These improvements deliver major benefits in startup time and app responsiveness to end-users.
.NET for Windows Phone 8 advances the platform
Today, we are happy to announce the availability of .NET for Windows Phone 8 and the Windows Phone SDK 8.0! We have made major updates to the .NET Framework runtime and code generation process that have resulted in startup time improvements as high as 50%. We have also included the new async programming model from .NET Framework 4.5 and the world-class garbage collector in the CoreCLR for better app responsiveness. Your customers will enjoy the big improvements that they see in your app running on Windows Phone 8.
Windows Phone 8 is built on a shared core with Windows 8. This stable, high-performance core has been used by hundreds of millions of end-users around the planet and is now the core of Windows Phone. CoreCLR is the core of the common language runtime (CLR) in the .NET Framework, which also delivers stability and high performance in .NET Framework apps to hundreds of millions of end-users around the planet. It made sense to include CoreCLR on top of the Windows Phone OS core to deliver this same promise for Windows Phone apps, so CoreCLR is now the core of Windows Phone apps.
For this release, we updated the Windows Phone OS and app platform to take advantage of multicore processing and to improve battery life. Most new devices are now multicore and come with the expectation that the OS and the apps will be faster because of that technology. Both Windows Phone 8 and CoreCLR take advantage of multiple cores and use modern software technologies and patterns. Users always appreciate any way that we can improve battery life. Our new approach to code generation removes a whole category of battery use for Windows Phone apps. Together, the new Windows Phone OS core and CoreCLR deliver lean and parallel experiences to end-users.
You can read the overview of the Windows Phone 8 release on the Windows Phone Developer blog. You can read more about the Windows Phone SDK 8.0 on the Visual Studio blog and Soma’s blog. Please visit the Windows Phone SDK 8.0 download page to install the tools, and read the article Getting Started with Windows Phone Development to start building a Windows Phone app if you haven’t built one before.
Apps get (much) faster with Windows Phone 8
We’ve made many changes to the .NET Framework libraries and runtime in Windows Phone 8, including the introduction of the new async model. We also made substantial changes to the .NET Framework engine and to our ARM compiler. As a result, we’ve observed major performance improvements both in the lab and with actual Windows Phone Store apps. On average hardware, we have seen apps start up twice as fast as on Windows Phone 7.1 devices. End-users will notice and really appreciate the speed of your apps. We hope your apps see similar gains.
Async
The most important recent advance in the .NET Framework is the new async programming model, introduced by C# 5, Visual Basic 11 in .NET 4.5. We’ve enabled the task-based async model on Windows Phone 8, with changes to both the CoreCLR and the .NET Framework libraries. This change is particularly relevant since Windows Phone 8 will run on multicore hardware. You can take advantage of these improvements by using the new async and await language keywords or by also using the popular Task Parallel Library. As a result, it is now much easier to provide a highly responsive UI experience for your users by leveraging both the async model and the multiple cores on end-user devices.
We added many new task-based async methods across the .NET Framework libraries to enable you to create asynchronous code without much effort. Much of the .NET Framework is now async, and we can expect that some new APIs will be async-only. You can create the responsive apps that your users want simply by moving to the new async APIs that we’ve added to the .NET Framework libraries. In addition, you can now use async APIs exposed in third-party libraries. Phone apps are a perfect candidate for the asynchronous programming model, so we encourage you to take advantage of these features to provide a much better user experience.
Most of the async methods in the .NET Framework are included in the Windows Phone SDK; however, a few of them are available via NuGet. We encourage you to download the additional async methods (specifically, System.Net APIs) via the Microsoft.Bcl.Async NuGet package to ensure that you have all of the .NET Framework async APIs available when you build Windows Phone 8 apps. More information is available here.
CoreCLR engine and garbage collector
Windows Phone 8 includes the CoreCLR engine instead of the .NET Compact Framework. The CoreCLR includes many of the same features and optimizations as the CLR in the .NET Framework 4.5. As a result, it is a lot faster and more efficient than the .NET Compact Framework. In particular, the CoreCLR includes our world-class auto-tuning garbage collector. These changes result in reduced startup time and higher responsiveness in your apps.
Much faster code with “Compiler in the Cloud”
For Windows Phone 8, we adopted a new code generation approach that is much better suited to the phone, both to deliver higher performance and to save battery life. Windows Phone 8 apps are compiled to high-quality ARM code before they are downloaded and deployed on end-user devices. They are compiled in the Windows Phone Store, with an optimizing compiler that does not have to satisfy the time and power constraints of a just-in-time (JIT) compiler. As a result, end-users will enjoy very fast app launch times on Windows Phone 8.
These changes are specific to Windows Phone 8, but they also improve launch times for Windows Phone 7.x apps. Both Windows Phone 7.x and 8 apps can be pre-compiled to high quality ARM code in the Windows Phone Store, before being downloaded and installed on Windows Phone 8 devices. You and your customers get the benefits of pre-compilation, without requiring you to make changes to your app. You can test out the pre-compiled binaries on your own Windows Phone 8 devices using Visual Studio 2012.
While these changes provide significant performance improvements for end-users, they also help battery life. In Windows Phone 7.x, app code was compiled every time the app was launched, and the CPU was used to compile that code, requiring battery power. With the new code generation approach in Windows Phone 8, apps are compiled in the Windows Phone Store with AC power generated from the Columbia River in Washington. That’s a better battery to use than yours! As you can see, we’ve removed an entire category of battery use on end-user devices.
Windows Phone 7.1 apps run on Windows Phone 8
Windows Phone 8 is designed to run existing Windows Phone apps unchanged. We’ve put in significant effort into maintaining application compatibility to ensure that your Windows Phone 7.1 app continues to run on the new Windows Phone 8 devices. It is recommended that you test your 7.1 app using the Windows Phone 8 device or emulator to ensure that you are getting a compatible experience.
In advance of new Windows Phone 8 devices coming to market, you may want to consider upgrading your existing Windows Phone 7.1 app to Windows Phone 8 to leverage new updates to the platform. The Windows Phone SDK 8.0 makes it easy to upgrade projects in Visual Studio 2012. Keep in mind that when you upgrade your existing Windows Phone 7.x app to Windows Phone 8, you may see changes in API behavior (serialization and isolated storage are the major categories in .NET to watch for) when the upgraded app is run on the Windows Phone 8 device or emulator. You can read more about compatibility on the Windows Phone app platform compatibility MSDN page.
Writing Windows Phone 8 apps
Windows Phone 8 provides major new improvements for developers. I have already talked about the adoption of C# 5 and Visual Basic 11, particularly around async, which you can use in Windows Phone 8 apps. Another major improvement is Windows Runtime interop. You can call Windows Runtime APIs in your code to get access to new native OS APIs and third-party native APIs.
I expect that many of you are building both Windows Phone 8 apps and Windows Store apps. In many cases, you will be building versions of those apps that differ only slightly between the Windows Phone and the various Windows 8 form factors. You should find that you can share a significant degree of your app logic between these platforms.
Windows Phone Runtime interop
Windows Phone 8 exposes a new type of native API through the Windows Phone Runtime, much like the Windows Runtime in Windows 8, if you are familiar with that new API technology. Many new APIs exposed in Windows Phone 8, like the Windows Phone Runtime Location API, are exposed by the Windows Phone Runtime. The CoreCLR engine has been updated to enable you to call Windows Phone Runtime APIs in your apps. In addition, native code developers can expose Windows Phone Runtime APIs, making their native code functionality available to .NET Framework developers. You will notice that you can call Windows Phone Runtime APIs just as naturally as you would call any managed APIs.
The Windows Phone Runtime enables you to call native APIs in both the Windows Phone SDK and as exposed by third parties. In Windows Phone 8, you cannot expose .NET Framework code via the Windows Phone Runtime.
Notice below that the Windows Phone XAML and Direct3D app project template is using this functionality. The Direct3DInterop class derives from IDrawingSurfaceManipulationHandler, which is defined in the Windows.Phone.Input.Interop namespace, which is a Windows Runtime namespace.
Additionally, you can call native code from within a managed app, as long as the native code is packaged and exposed to callers as a Windows Runtime type. We expect that several third-party native gaming engines will be leveraged this way. Note that we do not enable you to create Windows Runtime APIs using C# or Visual Basic in this release of Windows Phone.
Security model
We've simplified the way .NET Framework security works on Windows Phone 8. For those of you who've used .NET Framework Security Transparency Annotations in the past, you'll know that it takes a bit of work to correctly annotate assemblies, types, and methods. On Windows Phone 8, security is being enforced at the OS level and not by the managed runtime. This means that for apps authored for Windows Phone 8, you don't need to use security attributes in your code if you don't want to. For instance, you can call Windows Phone Runtime APIs without needing to annotate the method that's making this call as SecurityCritical. If, however, you have code that is shared between Windows Phone and other target .NET Framework platforms such as Desktop Windows or Silverlight, and you do use security annotations, the .NET security model will enforce those.
Debugging Windows Phone 8 apps
I talked earlier about the new code generation strategy. Your app is pre-compiled to high-quality ARM code in the Windows Phone 8 Store. You will want the opportunity to see and test the same experience that your customers will see. Using Visual Studio 2012, you can deploy your application to a Windows Phone 8 device by using the Start Without Debugging option (Ctrl+F5) in the Debug menu, as shown in the screen illustration below. When you select that option, application binaries will be pre-compiled to ARM code and deployed to your device. Your app is also pre-compiled and deployed when you choose the Start Performance Analysis option (Alt+F2) in the Debug menu. In both cases, you will see the same experience as your customers.
If you want pre-compiled binaries to be deployed to the device in debug mode (using the Start Debugging option (F5) under the Debug menu), choose Options and Settings in the Debug menu, and make sure that the Enable Just My Code check box is selected and the Suppress JIT optimization on module load (Managed only) check box is cleared.
Sharing code with Windows Store apps
We recognize that many of you have a C# XAML Windows Store app or plan to write one soon, and it may well be similar in form and function to the companion Windows Phone 8 app. To enable you to share code across the two apps, you can use a feature we announced a little while ago – Portable Class Libraries. Visual Studio 2012 Professional and Ultimate SKUs have built-in support for creating Portable Class Libraries. If you have not explored using Portable Class Libraries before, the Targeting Multiple Platforms with Portable Code blog post has a good overview. You can read more about how to architect your code and leverage Portable Class Libraries in the MSDN Magazine article titled Create a Continuous Client Using Portable Class Libraries.
In closing
Windows Phone 8 is an exciting new release for developers. We are happy about releasing the .NET Framework as a part of the SDK for Windows Phone 8. We’ve made significant improvements for start-up time performance and application responsiveness. As part of that, we’ve enabled you to use C# 5 and Visual Basic 11 features in your code, such as the async programming model. We’ve also enabled you to call Windows Phone Runtime APIs in the same natural way as managed APIs. We’ll be giving you a much more detailed look into many of these features in the coming months on this blog as well as at various sessions at the //Build Conference.
As always, we would like to hear from you. Please don’t hesitate to post a comment on the blog or at one of the forums that we monitor: Connect (report bugs), UserVoice (request features), and MSDN Forums (ask for help).
Follow us or talk to us on Twitter -- http://twitter.com/dotnet.