A first hand look from the .NET engineering teams
Today at TechEd North America, we announced the latest set of innovations that are part of the next generation of .NET. The biggest of those is ASP.NET vNext, which is an updated version of ASP.NET that been optimized for cloud Web development. We’ve continued to improve the core .NET technologies that we shared at Build last month, specifically the .NET Native ahead-of-time compiler and the .NET Next Generation JIT (“RyuJIT”). Both have new releases you can try out. We also have a set of smaller announcements to share.
At Build last month, we announced the .NET Foundation. We are currently talking to over 25 community-based .NET projects and organizations about joining the foundation. The interest in the foundation has exceeded our expectations and is off to a great start.
We also announced the .NET Compiler Platform ("Roslyn") at Build. It includes new C# and VB compilers and a preview of new language features being considered for C# 6. The project is open source on codeplex and has accepted its first pull requests from the community.
The final release of Visual Studio 2013 Update 2 is now available. Update 2 brings dozens of significant new features to Visual Studio developers, including tools for Windows Phone 8.1 and universal Windows apps.
While we’re looking forward, it’s also good to look at one of the current strengths of .NET. There are currently 1.8 billion active installs of .NET. That’s a very large number by any measure and a great base of desktop and server machines on which to run your apps.
Here’s a quick rundown of the .NET announcements that we shared at TechEd.
TechEd is the first time we’re talking about .NET vNext, as the next major release of the .NET Framework. At Build and TechEd, we’ve shared many of the features and components that you can expect in the next release. You will be able to compile C# 6 and VB with the Roslyn compilers, host ASP.NET vNext apps on the server or cloud, compile your Windows Store apps with the .NET Native ahead of time compiler, and enjoy faster desktop and server apps with the Next Generation JIT.
We’ve optimized .NET for the mobile-first and cloud-first development options that have become more common today. Device and cloud apps come with significant user expectations around performance, and also run in more specialized hardware/virtual environments. For Windows Store apps, we built the .NET native ahead of time compiler. For cloud apps, we’ve developed a cloud optimized mode.
.NET vNext will have a cloud optimized mode that enables you to deploy your apps with a copy of the .NET Framework libraries they need. Since the runtime and framework libraries are deployed on an app-basis, each app can run different versions of .NET vNext side-by-side and upgrade separately, all on the same machine. These libraries have been slimmed down significantly to reduce the footprint of the framework, and will be distributed via NuGet. Also, libraries such as WPF and Windows Forms have been removed from this mode.
We're developing this with cross-platform in mind, including an active collaboration with Xamarin to ensure that cloud-optimized .NET applications can run on Mac or Linux on top of the Mono runtime. The great productivity of .NET and ASP.NET can be available to teams working in mixed development environments.
ASP.NET vNext is our big announcement at TechEd. We’ve updated many aspects of ASP.NET to make ASP.NET apps easier to build and perform significantly better. We’ve considered sites and services that get infrequent traffic and those that get bombarded by visitors all day long. We’ve also opened up new scenarios that were just not possible with ASP.NET before.
We’ve designed ASP.NET with a key set of design principles in mind:
ASP.NET vNext includes updated versions of MVC, Web API, Web Pages, SignalR and EF. The key improvement with these frameworks is that MVC, Web API and Web Pages have been merged into a single programming model. For example, there’s now unified controller and routing concepts between all three. You can now have a single controller that returns both MVC views and formatted Web API responses, on the same HTTP verb.
ASP.NET vNext apps are cloud ready by design. Services such as session state and caching adjust their behavior depending on whether the app is running in the cloud or in a traditional hosting environment, while providing a consistent API. We use dependency injection behind the scenes to provide your app with the correct implementation for these services. Using this approach, it is really easy to move your app from on-premises to the cloud, since our code changes, not yours.
You will be able to make changes to your web applications and see the results after a browser refresh, with no separate build step needed. This significant productivity enhancement is based on improvements to load times in the underlying CLR, as well as use of the new .NET Compiler Platform ("Roslyn").
You can see the ASP.NET vNext in action in the images below. The first image shows an ASP.NET vNext Hello World app hosted from the command-line and drive from browser. Any edits in Visual Studio will be compiled and executed when the browser is next refreshed. This app is using .NET vNext cloud optimized mode.
You can also use Visual Studio with a more traditional Visual Studio F5 workflow that automatically starts the webserver and launches the browser. This is the same app as shown in the image above.
In the image below, the app has been re-configured to run on the full .NET vNext framework, instead of the cloud optimized mode. That’s just a setting on the project. The app now has access to all of the APIs in the .NET Framework. The browser refresh feature is available in this configuration, too.
The table below outlines the ASP.NET vNext scenarios we’ve built and where they are available.
ASP.NET vNext Feature
On .NET vNext
On .NET vNext (Cloud Optimized)
Consistent Tracing / Debugging
Faster Development (browser refresh)
Full Side by Side (runtime and framework deployed with application)
Faster startup, Lower memory / Higher throughput (best of class)
Uses a smaller set of framework libraries
Enabled on Mono, on Mac and Linux
ASP.NET vNext will be open source and will be contributed to the .NET Foundation. This shouldn’t come as a big surprise since the ASP.NET Web stack is already open source. All of ASP.NET vNext will be delivered via NuGet, will be open source and will take contributions. Read ASP.NET vNext: the future of .NET on the Server to learn more.
Our announcement at TechEd is the first stop for .NET vNext and ASP.NET vNext. We’ll share much more in the months to come before we release the final versions. We’re looking forward to shipping pre-release versions in order to get your feedback.
We recently announced the .NET Framework 4.5.2. It including significant improvements in ASP.NET and Windows Forms and other areas of the product. You can start incorporating 4.5.2 features into your apps now.
We released several key improvements to ASP.NET Web Forms. These include support for ASP.NET Identity 2.0, Entity DataSource control for Entity Framework 6 and Roslyn support.
We have also added new features and scenarios to both .NET Native and the Next Generation JIT. .NET Native now support x86, in addition to ARM and x64 apps. The Next Generation JIT now supports Windows 7 and later for x64 apps. Both of these technologies are a critical part of our .NET vNext roadmap. Expect to hear more about both of them in the coming months.
We’ve been working for several years to make it easier to write code for multiple platforms, both as apps and libraries. We started by enabling our PCL reference assemblies for Xamarin, who quickly moved forward with that change. More recently, we’ve been working closely with Xamarin to make our .NET NuGet packages work better with Xamarin tools, to make it easier to build .NET apps for iOS and Android. There’s still work to do, but the experience has gotten much better and will continue to improve.
At TechEd, we announced a new portability analysis tool, called ApiPort. It provides you with two main pieces of data: the platforms that you can easily/reasonably target with your code, and the dependencies that are preventing you from targeting additional platforms.
The command line tool generates an Excel report that provides you with two views of its portability analysis. It provides a high-level color-coded view for a given set of platforms. It also provides a very detailed list of all the types and members used within your code, and whether they are supported, per platform. Given that the report is in Excel, it is very easy to filter the list, build pivot tables and do whatever else you want to perform further analysis.
The image below shows a small sample of the high-level portability analysis view. Only one assembly is shown, but there can be multiple. Check out this sample portability analysis to get a first-hand view.
The tool has another function, too. All of the dependency data (not the assemblies) are uploaded to an Azure service that the .NET team maintains. The data that the tool uploads is the list of assemblies and APIs that your code relies on. We do not record where the data came from or by whom. We do not upload any of your actual code or binaries. We want to know which functionality we need to bring to each platform to make it easier to target all platforms.
If you are finding it difficult to target a particular platform, please “vote” for the APIs you want added to a particular platform by running the tool on your app and libraries. It’s really easy to run the tool on a whole directory.
This first release of tool is missing a few features that we are in the process of adding. The Xamarin/Mono platforms are currently missing from the tool. It also doesn’t yet take into consideration NuGet packages that make .NET Framework APIs available on other platforms, counting them as missing APIs.
You’ve probably heard that Microsoft is both a “services first” and “devices first” company. At the nexus of those statements are client libraries that make it easy to target Microsoft services from apps. While Client libraries for Microsoft services are not new, we are more recently working to provide support for more platforms. We’ve started with Office 365 services, and intend to add more services over time.
We have also provided an integrated experience for adding these libraries to your apps within Visual Studio. Services require app registration, permission selection and a platform-specific user authentication experience. You also need to add the right client libraries to your app. The Visual Studio experience takes care of all of that for you, as part of the Connected Services Manager, displayed below.
You can learn how to start using this experience from the Office Developer blog. We are using StackOverflow as the community forum for this project, under the Office365APIs tag. Please tell us what you think about the client libraries and the new Visual Studio integration. Do note that these libraries, and the Office services they are targeting, are in Preview and don’t yet support production apps.
On the .NET team, we’re excited to be sharing the Next Generation of .NET. As you can see from this post and the one we published at Build, we are lining up a significant set of technologies, features and scenarios that will be part of .NET vNext, our next major release of the .NET Framework. In this post, we focused on ASP.NET vNext, our next generation Web and services platform.
For .NET vNext, we’ve been talking about major features and asking for feedback before we even announced the larger release. We’ve been actively engaging with experts and enthusiasts in our preview and pre-release programs to validate our ideas and product directions. It’s turned out to be a great approach. The feedback has been incredible. Thanks to everyone that has participated in our CTPs, developer previews, pre-releases and any other program we ran to collect feedback. We’ve also received great feedback in blog comments. It’s all been very helpful. Do expect multiple additional preview releases over the coming months, particularly for ASP.NET vNext. It’s going to be a fun time.
You can see how these technology investments come together into a single .NET Framework release, in the following slide that we showed at TechEd. Open Source is also an important part of our plans, as you can see with our ASP.NET vNext contribution plans with the .NET Foundation. The future looks very bright for .NET.
@CraigAJohnson: .NET Native is currently only for Windows Store apps. This question and many others is answered at the FAQ found at msdn.microsoft.com/.../dn642499.aspx.
I’m disappointed that classic Windows Desktop development is not mentioned at all. The last years are just about WinStore and Cloud development.
Does developing applications for the Windows Desktop have no future anymore? Are all client technologies dead (e.g. WPF)?
I am really starting to love you Microsoft :)
Great news for *nix!
Are announcements now merely to insult the intelligence of developers?
Where is the *actual substance*?. Why should anyone care about this? What does it do ? All I see is marketing buzzwords "Cloud Optimized" "Device Optimized" "Small Footprint" Um.. that tells me nothing. "Cross Platform enabled" - That means nothing unless you're going to ship tools for Linux/OSX. A website is rendered by a browser which can run on any OS. How is it a feature of your product?
"Low latency developer experience" is meaningless. And.. err SCREENSHOTS? Why the heck do we need screenshots? They don't convey anything new whatsoever.
Stilgar, I find your mention of Web Forms disturbing.
Web Forms is something that should not have ever happened.
Looking forward to what you show regarding webforms... I do believe there is a place for a rich UI stack on the client that integrates seamlessly with some form of backend projection ... UI that seamlessly connects keeping its state all the way to the backend using todays patterns..
Im waiting to be impressed tomorros :)
@Jenda - like it or not, the bulk of ASP.NET application written in the past 12 years are implemented in WebForms, and they are actively improved and maintained - so even if for new applications many people started to migrate to ASP.NET MVC, a lot of people are still using WebForms.
The same applies to WinForms, even if it's slowly replaced by WPF (that also has an uncertain future, now that Silverlight has been abruptly abandoned by Microsoft).
To me, all this new love for open source means zip unless Microsoft flips the switch and stops suing - OK OK, threatening to sue - everyone and their router, claiming linux users owe it anything.
Microsoft cheerful open source advocates (*cough* Hanselman, *cough*) where the F is your voice?
Sorry to pop your colorful balloon on your happy occasion.
@Jenda first of all you are wrong. But instead of explaining why you are wrong I will go ahead and point to another thing.
I hereby claim that till the end of time Web Forms will always have greater deployment than MVC measured by the amount of HTML the projects written in the two technologies are able to generate (i.e. if you open every page on every project once Web Forms projects will always produce more HTML). This will always be the case because there is currently greater investment in real world Web Forms projects than MVC projects and future projects won't generate HTML on the server which makes both frameworks irrelevant for anything but legacy apps. Therefore Web Forms will ALWAYS be more important than MVC. And no WebAPI does NOT count as MVC.
"There are currently 1.8 billion active installs of .NET. That’s a very large number by any measure and a great base of desktop and server machines on which to run your apps."
Will be interesting to see if any investment will be made in desktop maybe future posts will talk about that.
"Also, libraries such as WPF and Windows Forms have been removed from this mode."
It is mentioned that desktop is removed from cloud mode (which makes sense). Will be interesting to see if that will be the default way the new version of .Net is send out (hope not).