A first hand look from the .NET engineering teams
At Build 2014 this week, we announced the next generation of .NET. The next generation will focus and deliver on two main themes: Core Innovation and cross-device apps. These themes are a direct result of your feedback, asking for new features in .NET and to make it easier to use .NET for all your apps.
At Build 2014, we are releasing:
The .NET team has been building new technologies that extend the core capabilities of .NET and fundamentally improve the user experience of your apps. At Build, we’ve announced .NET Native, Next generation JIT and SIMD. Those technologies focus on taking better advantage of hardware and specific CPU instructions that improve app performance.
We’ve made sure that .NET is a great technology for cross-device app development, in concert with the community and partners. This also includes improving portable class libraries and ensuring that our NuGet packages work well on Xamarin platforms.
Many of those .NET libraries are open source, including from Microsoft. We’re going to do more to work with open source developers. You will want to learn more in Soma’s blog post on the .NET Foundation, which is new organization that is intended to foster open development around the growing collection of open source technologies for .NET.
We’re sharing preview releases of multiple technologies that show you where the next generation of .NET is headed. Please download and try out these releases. We need your feedback before we release these technologies as fully supported .NET features.
Looking back, we released the .NET Framework 4.5.1 late last year. We are happy to let you know that .NET 4.5.1 is now on 350 million machines! Many of you have started taking advantage of the new features that we added in 4.5.1, and end-users are benefiting from the performance improvements.
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! See yesterday’s .NET Native announcement.
The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs. You can build code analysis tools with the same APIs that Microsoft is using to implement Visual Studio! To learn more see the C# Roslyn announcement post or the VB Roslyn announcement post.
You can use .NET to target mobile and cloud platforms. We’ve been working to make that experience even better, generally and in Visual Studio Update 2. The following examples show how .NET cross-device development keeps on improving.
RyuJIT made a big splash when it debuted last October. RyuJIT CTP1 offered 2X throughput relative to the existing 64-bit JIT compiler and set up our team with a platform that’s suitable for innovation and rapid development. A few weeks ago we released RyuJIT CTP2, giving you the performance and reliability you need to try out RyuJIT on your day-to-day workloads.
We’re happy to announce RyuJIT CTP3, showcasing the customer-facing innovations made possible with a modern JIT compiler. RyuJIT CTP3 is able to produce SIMD instructions (e.g., SSE2) when you compile with our SIMD library on NuGet. By using the SIMD libraries along with CTP3 of RyuJIT, .NET developers can now enjoy the performance boost offered by SIMD instructions available in modern processors, especially useful for numerical computing, gaming and image processing applications.
You can download the RyuJIT CTP3 installer. RyuJIT currently only works on 64-bit editions of Windows 8.1 or Windows Server 2012 R2. Because we want you to be able to test out RyuJIT easily the installer doesn’t affect NGen or the system registry. After installation, there are two ways to turn on RyuJIT. If you just want to enable RyuJIT for one application, set an environment variable: COMPLUS_AltJit=*. If you want to enable RyuJIT for your entire machine, set the registry key HKLM\SOFTWARE\Microsoft\.NETFramework\AltJit to the string "*". Both methods cause the 64-bit CLR to use RyuJIT instead of JIT64. And both are temporary settings—installing RyuJIT doesn’t make any permanent changes to your machine (aside from installing the RyuJIT files in a directory). The SIMD libraries are available through NuGet.
Send feedback and questions to firstname.lastname@example.org
Sharing code can be challenging. But don’t worry: with Visual Studio Update 2 we’ve made significant improvements to the way you can share code.
You now have two options for sharing:
We are going to continue to look for ways to make sharing code easier and would appreciate your feedback.
For more details on the new Universal Apps feature: stay tuned. There is an upcoming Visual Studio post that explains the ins & outs. In this post, we’ll cover the improvements we’ve made to portable class libraries.
First of all: we’re happy to announce that starting with Update 2, portable class libraries are now also made available in Visual Studio Express for Windows.
We’ve heard your feedback around API convergence loud and clear. As a result, the new Windows Store 8.1 and Windows Phone 8.1 platforms have started to converge a lot more. That means you will be able to use almost all of Windows Store 8.1 and Windows Phone, WinRT, and .NET APIs from portable class libraries. That’s right – portable class libraries can now consume all the WinRT APIs that both our Store platforms have in common.
.NET has a great set of APIs available, on the .NET desktop and other platforms. We’ve heard feedback that it is challenging to re-use existing .NET code in Windows Store apps, because it doesn’t include core APIs such as File. We are looking at making more APIs available that would make this easier. We would love to hear your feedback, specifically about the APIs you want added.
For the first time, you can now share UI via portable class libraries. This is possible because both Windows Store and Windows Phone use the same WinRT XAML stack. This includes being able to use the XAML designer in portable class libraries.
Today, the New Project Dialog is where you have to make the decision whether you want to target a single platform or multiple platforms. Depending on the answer, you either create a regular, platform specific class library or a portable class library. Needless to say that requirements can often change over time. Previously there was no way to adjust this decision later – you had to start over.
With Update 2 we’ve removed this friction for Windows Store and Windows Phone class libraries: class libraries for both platforms have the same experience for retargeting as portable class libraries. This means you can convert any store class library into a portable class library by just ticking another checkbox in the Change Targets dialog. The reverse is also true: any portable class library can be reduced to target just Windows Store or just Windows Phone.
This is super useful for reusing existing Windows Store 8.1 class libraries on Windows Phone 8.1. Given the amount of convergence, making them a portable class library will work in majority of cases without any changes.
In VS2013 RTM we introduced the Performance and Diagnostics hub with a bunch of tools that help you diagnose issues during your Windows Store app development. With VS2013 Update 2 we added two brand new tools: CPU Usage, and Memory Usage. We also made all the tools in the Performance Diagnostics hub applicable to Windows Phone 8.1 development.
We also enhanced the .NET memory dump analysis feature so you can now inspect values of objects from the dump file.
It’s also worth highlighting here the addition of the JSON Debugger Visualizer to Update 2.
With Visual Studio 2013 Update 2 RC, we’ve added support for .NET Mobile Services backend projects. You can now create a Mobile Service project (which uses the ASP. NET Web API framework) from Visual Studio, add scaffolds to it, debug it locally, publish it to Azure, and finally remote debug it. It’s all the Mobile Services goodness, but with the familiarity of .NET. To learn more about .NET Mobile Services in Visual Studio, check out Scott Gu’s blog post that covers Mobile Services .NET support from earlier today.
Project “Orleans” is an implementation of the Actor design pattern. This pattern is particularly well suited for gaming, Internet of Things, social networks, and other scenarios with complex and dynamic relationships. The Halo 4 team took advantage of Project “Orleans” to build some of their backend services.
We’d appreciate you downloading the preview, trying it out and telling us about your experience using this design pattern.
.NET 4.5.1 delivers a lot of value and has been widely deployed since its release in October. This week we’ve provided previews around our compilers and JIT and shipped updates to our developer experiences around class libraries and Azure. We’re excited to be delivering value at this cadence and can’t wait to see what you do with these new capabilities.
We’ve made a lot of preview bits available this week at //build and are looking forward to hearing back from you about them. The best places are UserVoice, Visual Studio Connect and the comment to this post. We’re also listening on Twitter and Facebook.
SIMD support! This deserves to be written in bold and capitals. I was starting to be afraid that JS would get SIMD support before .NET!
I love all the stuff you guys are coming up with. Keep it up!
Will any of these features find their way into vs 2012?
Great news, especially the improvements of PCLs in this update!
@Carlos: I'm afraid not. For libraries, we generally try hard to make them available to existing platforms -- within reason though. Due to the complexity that comes with tooling features, we generally do most of the VS work in a forward looking way. However, as you can see with VS Update 2, not all features require a new major version of VS.
@Martin: Thanks! :-)
OK, PCLs in Express is GREAT. I don't know why this so obvious feature took so long especially since you are trying to push people to develop for WP and Win8 and advertise portability and free tools.
On the other hand I hope you realize that you just announced a new set of portability tools for exactly the same platforms. Now we need a single VS Express to develop universal apps. Make sure you do this or I will continue to call you hypocrites every time you write a blog post or go on stage and announce that the tooling for WP and Win8 development is free.
"Now we need a single VS Express to develop universal apps."
It's called VS Express for Windows.
Windows Phone tooling is also present in VS Express for Windows. You don't need a paid version of VS.
Guys, the NET Native is WRONG THING !!! I fully agree with idea of unlocking more speed from .NET, but NET Native is wrong direction. NET is slow in multiple areas, because you limited options with all-or-nothing philosophy. NET Native is about creating more mess to NET world, than fixing obvious problems within NET itself. You must try to extend NET to reduce overhead and fix wrong paths, than providing convoluted and limited workarounds like NET Native. To be more concrete, you should consider few improvements to NET itself:
1. Give us ablility to generate app/library files with IL AND/OR NGEN-ed code. This solve problems with slow startup and code obfuscation. Within single files you can include ngen-ed code for diffrent CPU architectores.
2. Give us ability do disable runtime type checking, array bound checking and others. Best way to do it is to use attributes. Type safety is great when aplication is developed, but when code is flawless, then this feature is useless overhead. Of course, some scenarios requires type checking all the time, but these are minority.
3. Give us more control on GC and memory management. Most overhead come from checking references betwen objects, and we want to disable this checking on givent object (and his subobjects) to improve performance. Thisa can be done by method GC.SetCheckReferences (obj, bool). Additionaly give us option to remove particular object from memory on demand, by adding method GC.Remove (obj).
These improvements do not break any compatibility and can improve pervormance in multiple areas. On the other hand, NET Native only reduces startup time (in most significant way), which can easy achieved by traditional ngen-izing IL binaries at instalation time. This way NET Native is useless.
Latest lesson MS gained from DX11 vs Mantle, lead to simple equation: more control = more speed. Do it with .NET
.NET Native looks great but I want it for the desktop CLR as well. How does this play with ETW profilers where you need the native method to module mapping? It would be great if we could get native pdbs as well without the need to recreate them on every machine again which can take for big apps up to 15 minutes. If you ever consider it to release it on Windows 7 you must fix the ETW x64 stackwalking bug which stops the stackwalk on the first dynamically generated (JITed) frame.
SIMD Support is also a long awaited capability. I hope you have already AVX-512 CPUs in the labs so you can target any SIMD enabled CPU. In theory you could get faster than the Intel Compiler because Intel cpp compiles the same method to all CPU types where upon method entry the right method must be picked. The JIT compiler can do it right without the switch statement. Not sure how this plays together with .NET Native where you can either target only specific CPUs or you must emit also the code for all possible target CPUs.
1. If this feature would make it I would be the first to file a big bug report for it. When you combine all platforms in a single native binary you waste massive amounts of address space for x32 and ARM apps. It makes a huge difference if you have mapped 500 MB or 1 GB of dlls into your address space.
2. The JIT compiler eliminates already bounds checks if it can prove that you are not going out of the bounds. Since the JIT Compiler is redesigned it would be a good time to provide code samples where it does not eliminate bounds checks but it should. The unsafe keyword has been there since the beginning of .NET. Use it and bounds checking is off, or use Managed C++ if you need more control.
3. This is not how the GC works. There exists no separate list of references which were manually deleted. It must still scan all references to find the garbage of other objects which renders this feature useless. What should the GC do if you have deleted an object but you still have references to it which you have forgot? You would access random data opening a whole new class of security bugs in otherwise totally safe code.
1. None waste of adress space. NET only load compiled code, instead of JIT-ing
2. Maybe there are some optimization, but they are limited, because NET is unaware if your code is good or buggy.
3. I sugest that some references can be excluded by GC checking. But of course they must be checked when code need access to some object. There are two diffrent types of checking.
@TBRMDEV: It looks like you've left the same comment on this blog as you left on the .NET blog. There are a couple of responses to your suggestions there. Take a look at this page for our responses: blogs.msdn.com/.../announcing-net-native-preview.aspx
> How does this play with ETW profilers where you need the native method to module mapping?
ETW profilers have to perform a lookup to map the native method back to the module. To facilitate this lookup, methods within a .NET Native DLL have a special prefix in the form of "$<index>_". The index within this prefix can be used to lookup the original module from a map within the PDB.
PerfView, the Visual Studio debugger, and the TraceEvent library correct these module and method names, but other ETW based profiling tools do not. We plan to improve other Microsoft-built profiling tools in the future. We also plan to provide documentation on how third-party tools can perform this lookup too.
> It would be great if we could get native pdbs...
Applications built using the .NET Native Preview have complete PDBs created as part of the compilation process. I think we have what you're looking for, or perhaps I misunderstand the question.
> ...the ETW x64 stackwalking bug...
If we were to support .NET Native on Windows 7, the stackwalking bug shouldn't impact profilers since there is no JITted code.