At the Build conference today, Scott Guthrie announced the .NET Framework 4.6 RC and Visual Studio 2015 RC. He also announced important updates for .NET Windows 10 apps, ASP.NET 5 and .NET Core. You can download and try out the releases now:

.NET Core – for Device and Cloud

.NET Core is a new version of .NET for modern device and cloud workloads. It provides a single set of APIs for you to use for your apps. .NET has always offered low-level code portability as a fundamental tenet, and now has a uniform API that can be used in multiple app types. You don’t need to rely on other code sharing techniques to target multiple app platforms, such as portable libraries and shared projects.

Today, the .NET Core Framework can be used in ASP.NET 5, Windows 10 apps and .NET Core console apps. The .NET Core API started as the API for Windows 8 Store Apps. It has since grown, both in terms of APIs exposed and to also include other scenarios such as ASP.NET 5 apps. Now, when we add new APIs to .NET Core, they are available for multiple app types at once. This approach makes better use of our engineering time and provides you with a consistent API right away.

All of the .NET Core libraries are distributed as NuGet packages. You can acquire the packages easily within Visual Studio or with one of the NuGet clients directly.

Self-contained and Efficient

Another major benefit of .NET Core is that it can ship as part of your app. This means that your app is self-contained, with a set of fixed binaries, which includes the .NET Core Framework and runtime. This ensures that your app is unaffected by system updates or other apps that might be updating on the same machine. Your app can also be updated without affecting any other apps. This is especially important for Windows 10 Universal Apps — where you build and publish a single application that can run consistently on all devices (Tablet, Phone, Desktop, HoloLens, Xbox, IoT, etc). This approach also ensures that new features in .NET Core and C# language improvements are consistently available for you to pick and choose to use across all these environments.

Apps often rely on many .NET Core libraries, such that a lot of self-contained apps might seem like too much of a good thing. This is particularly important for constrained device environments. .NET Native solves this problem by optimizing apps to include only the code that a given app relies on. If you only rely on one type within an assembly, that’s the only type that will be retained in your final app. .NET Native has other optimizations that further slim down your overall app.

.NET Native is currently scoped to Windows 10 Universal apps, however, it is intended to fit in as a deployment option for .NET Core apps generally.

Cross-Platform

.NET Core supports Windows, OS X and Linux. You can write Universal apps on Windows 10 and ASP.NET 5 and Console apps on all of the three OSes. FreeBSD support is in progress, led by the .NET open source community. We expect that the community will create other OS ports. In fact, the OS X port has also been community led.

.NET Core supports x86, x64 and ARM CPUs in order to support device, cloud and console app scenarios. We expect that to see more chips come online, particularly given the LLILC LLVM integration project. LLILC will (in theory) make it possible to port .NET Core to all of the chips that LLVM supports.

Open Source

The .NET Core is open source on GitHub. You can look at the code and even make contributions. We have received many great contributions over the last number of months. Thanks!

The .NET Core Framework team are in the process of publishing all of their code on GitHub and are now over half-way done. You can check out their progress in the image below.

PartsUnlimited

The team built and released a demo of a .NET Core app, using ASP.NET 5. The demo is called PartsUnlimited and is open source on GitHub. It runs on Linux, OS X and Windows.

Parts Unlimited is an ecommerce app for a ficticious company, based on a website of the same name in The Phoenix Project. The website includes product listings by category, product details, shopping cart, order history, product recommendations, search, and more.

Both the demo and .NET Core are under development. The master branch of the repo supports .NET Core and ASP.NET 5 beta 4, and runs on Windows. The beta 5 branch supports .NET Core and ASP.NET 5 beta 5 and runs on Windows, OS X and Linux. You can try out both branches, although you may encounter a beta 5 build that doesn’t work as expected.

Key Features:

Works with Visual Studio 2015 RC

ASP.NET 5 support for Linux and Mono

Includes a Dockerfile and sample publishing profile to publish to a Docker container

.NET Execution Environment (DNX)

The .NET Execution Environment (DNX) is a new .NET SDK that provides a consistent development and execution environment across multiple platforms (Windows, OS X, Linux, …), multiple CPUs (x86, x64, …) and across different .NET flavors (.NET Framework, .NET Core and Mono). It enables you to build a single app that can work across that breadth of options and is also easy to build with either text editors or full IDEs.

DNX provides the following benefits:

Create single application that can work on multiple operating without cross compiling (Windows, Mac, Linux)

Create applications that can run from source without a build step enabling development with just simple text editors (Sublime, Emacs, VIM, Visual Studio Code).

Enables debugging from source for referenced NuGet packages.

Straightforward acquisition of .NET runtimes (e.g. .NET Core).

Manage multiple .NET runtimes on a single machine both globally or app centric including security updates.

Supports ASP.NET 5 and .NET Core console app workloads.

DNX is a general .NET Core concept and facility. It’s the easiest way to acquire and use the new open source and cross-platform version of .NET. It started life in the ASP.NET 5 project and has gone through several renames over the past few months (was called ‘KRE’ before), but that’s purely historical.

Note: DNX is not the only SDK for .NET Core. .NET Native, for example, is another one.

DNX Tools and Concepts

There are several pieces to DNX:

DNX (distribution): A distribution (a NuGet package) of the components that are the implementation of the new environment.

The .NET Core DNX distribution includes CoreCLR and the base parts of CoreFX.

The .NET Framework and Mono DNX distribution only contain the DNX components.

DNVM: A tool for aquiring and managing DNX distributions. Not part of DNX itself, since it plays an admistrator role for DNX.

Using DNX

The team has been using DNX as the easy way to both acquire and use .NET Core for development and testing. It’s great to use, particularly for the scenario where you SSH into a terminal on Linux and want to quickly acquire a version of .NET and start using it within a minute.

In a typical workflow, you do the following (each of which is a simple command):

.NET Language Updates

C# 6 and VB 14

With the RC release of Visual Studio 2015 RC, both Visual Basic 14 and C# 6 are language complete. In this release we’ve made several improvements to the languages and IDE to reduce boilerplate and respond to top customer feedback. Some highlights include:

The Null-Conditional operator (?.): A streamlined syntax for conditionally accessing a member or invoking a method on a value if it’s non-null and returning null if the object is null instead of throwing a NullReferenceException.

The NameOf operator: A rename-safe way to refer to the name of a code element such as in PropertyChanged events and ArgumentExceptions.

Read-only Auto-Properties: A concise syntax for declaring properties which may only be assigned in their initializers or inside of a constructor.

We’ve also made several improvements to the debugging experience including support for using lambda and query expressions inside of the debugger windows and Edit and Continue support in and around lambda expressions, simple queries, as well as inside Async and iterator methods.

Lastly, this release includes the 1.0 release of the .NET Compiler Platform, formerly known as “Roslyn”. A rich set of code analysis APIs on which many of the new Visual Studio experience improvements like new refactorings and live code analyzers are built. Read more about the .NET Compiler Platform (“Roslyn”) on GitHub.

Visual F# 4.0

F# is a collaboration between the F# community and Microsoft. Visual F# 4.0 RC represents the work of 38 contributors, over 75% of whom have no Microsoft affiliation. It was built completely in the open by F# community developers, in partnership with the Visual F# team at Microsoft. The F# bits that ship with today’s RC build map to commit 76ae08d in the F# repo on GitHub.

F# 4.0 includes major new enhancements across the language, the runtime and the IDE experience. The following features are a small selection of what’s included:

More EnC – Lambda and Async Task support

Edit and Continue (EnC) is a great productivity feature that everyone (wants to) use every day. It enables you to edit your code while you are debugging it. This is useful for a lot of reasons, particularly if your code needs to interact with state that isn’t directly part of an API (e.g. processing JSON files) that can be most easily discovered at runtime.

You can now use EnC with lambdas, async methods, LINQ and a few other situations. Given today’s coding patterns, that’s a huge jump forward for EnC usability. You can check out the set of EnC improvements the team already released in Visual Studio CTP 6.

The following screenshot demonstrates the new support. There are two separate lines that were typed using this new support, one in an async method and the other in a lamda.

The following scenarios are now supported:

Async functions

Lambda expressions

LINQ queries

Iterator functions

EnC improvements are still in progress and we are working to support more scenarios (and providing more documentation). Please file any issues you come across on our GitHub.

Note: If you don’t understand why an edit fails, try checking the Error List. There are explanations for errors there that should help clarify issues. Please file an issue if you find these messages confusing or if they do not exist for your error.

WPF – Live Visual Tree

Visual Studio includes a new viewer and editor for the XAML Visual Tree – Live! – while debugging a WPF app. It enables you to navigate the visual tree as it exists at any point in the life cycle of your app. You can edit properties on the tree, for example button text, which are then displayed in the running app. You cannot change the composition of the tree.

You can also select visual components in the running app. These selections will update the Live Visual Tree in Visual Studio, enabling you to focus in on the parts of your app that might need investigation or updates.

The Live Visual Tree is also connected to the XAML source editing experience. As you select XAML nodes in the Live Visual Tree, the selected textual XAML in the IDE changes to match. You always know which text matches, making it easy to find the line of XAML to look at or change.

The following screenshot demonstrates the Live Visual Tree and an app that has a button selected with the new feature.

Xamarin Starter now Included in Visual Studio

Xamarin is a great way to start building iOS and Android apps in C# or F# within Visual Studio. Xamarin Starter Edition is now included as a free optional feature within Visual Studio 2015. Many .NET developers are using Xamarin to increase the reach of their apps and development effort to iOS and Android. According to a recent blog post, Xamarin has been downloaded by 1 Million unique developers. That’s a lot.

There are several additional application templates that are available for you to use after installing Xamarin Starter edition, for iOS (displayed below) and Android.

You can use Xamarin Starter editon as long as you want, build apps, test on devices and publish to app stores. You can start a Xamarin Business trial to try out the richer experience. You can always return to Xamarin Starter Edition after that.

ASP.NET 5 Project

The team has a lot of focus on the ASP.NET 5 project. There are some important new updates in the RC described below and in the webdev blog. At this point, most of the attention is on fit-and-finish, performance and reliability. We’ve talked to many customers that want to start deploying it on both Windows and Linux. There is also a lot of interest in OS X, particularly with the recently announced Visual Studio Code. It’s our goal to make this incredible new ASP.NET scenario available to you as soon as we can.

Updated New Project Dialog

The addition of ASP.NET 5 as new separate version of ASP.NET motivated the team to re-work the ASP.NET New ASP.NET Project dialog in Visual Studio. ASP.NET 4.6 and ASP.NET 5 are clearly divided, making it easy to choose which type of app you want to build. The ASP.NET 5 section has fewer choices since more of the scenarios are integrated now. For examoke, you can opt to make your Web API a Mobile service at any time.

Missing NuGet Packages – No Longer

The transition from the monolithic .NET Framework to distributing .NET Core as NuGet packages has a lot of advantages, but has come with some challenges, including package discovery. You can now resolve NuGet package references in a similar way as you can resolve missing namespace references for types.

In the example below, the XDocument type (just the text XDocument) is resolved to its type definition with a simple “CTRL .". The using statement is added to the file and the System.Xml.XmlDocument NuGet package.

We wanted to make it easy to copy some code from StackOverflow, for example, and resolve type and package references quickly and easily. Please tell us if we’ve achieved that goal.

Async Model Binding for Web Forms

In the .NET Framework 4.5, Model Binding support was added to Web Forms. In the .NET Framework 4.6, we are adding support for Async Model Binding which allow you write Asynchronous Model Binding actions. The following code snippet shows a Web Forms page using Async Model Binding actions.

HTTP/2 Support (Windows 10)

HTTP/2 support has been added to ASP.NET in the .NET Framework 4.6. New features were required in Windows, in IIS and in ASP.NET to enable HTTP/2 given that networking functionality exists at multiple layers. You must be running on Windows 10 to use HTTP/2 with ASP.NET. HTTP/2 has not yet been added to ASP.NET 5.

HTTP/2 is a new version of the HTTP protocol that provides much better connection utilization (fewer round-trips between client and server), resulting in lower latency web page loading for users. Web pages (as opposed to services) benefit the most from HTTP/2, since the protocol optimizes for multiple artifacts being requested as part of a single experience.

The browser and the webserver (IIS on Windows) do all the work. You don’t have to do any heavy-lifting for your users. Most of the major browsers support HTTP/2, so it’s likely that your users will benefit from HTTP/2 support if your server supports it. Give it a try with the RC update.

Support for Token Binding Protocol

Microsoft and Google have been collaborating on a new approach to authentication, called the Token Binding Protocol. The premise is that authentication tokens (in your browser cache) can be stolen and used by criminals to access otherwise secure resources (e.g. your bank account) without the requirement of your password or any other priviliged knowledge. The new protocol aims to mitigate this problem.

The Token Binding Protocol will be implemented in Windows 10, as a browser feature. ASP.NET apps will participate in the protocol, such that authentication tokens are validated to be legitimate. The client and the server implementations establish the end-to-end protection specified by the protocol.

.NET Framework 4.6

Today’s release is .NET Framework 4.6 RC. It’s the first “Go Live” release for the 4.6 release. Please install it and start trying it out. You can read about the .NET Framework Preview release, which we shipped in November.

RyuJIT

RyuJIT is the next generation Just-In-Time (JIT) compiler for .NET. It uses a high-performance JIT architecture, focussed on high throughput JIT compilation. It is much faster than the existing JIT64 64-bit JIT that has been used for the last 10 years (introduced in .NET 2.0 release).

The project was initially targeted to improve high-scale 64-bit cloud workloads, although it has much broader applicabilty. We also do expect to add 32-bit support in a later release.

RyuJIT is on by default for 64-bit processes running on top of the .NET Framework 4.6. Your app will run in a 64-bit process if it is compiled as 64-bit or AnyCPU, and run on a 64-bit operating system. RyuJIT is similarly integrated into .NET Core, as the 64-bit JIT.

We’ve used a transparent process over the last two years with RyuJIT. You’ve been able to read many blog posts on RyuJIT, try out several RyuJIT CTPs and (suprise!) you can now even read and contribute to the RyuJIT source code. Thanks to everyone who helped improve RyuJIT along the way to RC. It’s very close to going into use and improving the performance of many production workloads.

Garbage Collector Update

The Garbage Collector has a new mode that attempts to avoid garbage collection while certain memory-related conditions are met. This new mode is important for workloads that require uninterupted computation (at least as it relates to GC CPU use).

The new mode enables you to specify a certain amount of memory be available as a pre-requisite to enter a No GC Region. While in the region the GC will not collect. It will start collecting if a collection is explicitly requested (e.g. GC.Collect) or if the initially specified memory size is exhausted.

The new mode exposes multiple points of configuration, including allowing you to specify the memory available for the small and large object heaps separately, for use within the No GC Region.

This update is the first step towards broader support for the Windows CNG API and for more modern cryptography algorithms generally. Note that team is still in the middle of building this new support, so expect the API to change for RTM.

Compatibility Switches

AppContext is a new compatibility feature that enables library writers to provide a uniform opt-out mechanism for new functionality for their users. It established a loosley-coupled contract between components in order to communicate an opt-out request. This capability is typically important when a change is made to existing functionality. Conversely, there is already an implicit opt-in for new functionality.

With AppContext, libraries define and expose compatibility switches, while code that depends on them can set those switches, to affect the library behavior. By default libraries provide the new functionality and only alter it (e.g. provide the old behavior) if the switch is set.

An application (or a library) can declare the value (always boolean) of a switch that a dependent library defines. The switch is always implicity false. Setting the switch to true enables the switch. Explicity setting the switch to false provides the new behavior.

1

AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException”,true)

The library must check if a consumer has declared the value of the switch and then appropraitely act on it.

It’s beneficial to use a consistent format for switches, since they are a formal contract exposed by libraries. The following are two obvious formats.

Switch.namespace.switchname

Switch.library.switchname

This same infrastructure is used by the .NET Framework internally, to enable developers to opt out of updates to existing functionality.

Entity Framework

The Entity Framework has two separate EF versions that they are working on. EF 6.x is the mature version that everyone is using. They also have the EF 7.x version, which is the next major release and is still under active development and in preview. You can learn more by reading today’s announcement post from the EF team.

Entity Framework 6.1.3

EF6.1.3 is the latest stable version of Entity Framework and is the recommended version for production applications. EF6.1.3 is a patch release containing fixes for high priority issues that were reported on EF6.1.2. Visual Studio 2015 RC includes the RTM version of Entity Framework 6.1.3 runtime and tooling.

The EF runtime will be installed if you create a new model using the Entity Framework Tools in a project that does not already have the EF runtime installed.

The runtime is pre-installed in new ASP.NET projects, depending on the project template you select. The EF6.1.3 Tools for Visual Studio 2015 are included to make sure you get the latest bug fixes and improvements.

Entity Framework 7 Beta 4

EF7 introduces some significant changes and improvements over EF6.x and therefore the pre-release phase of EF7 is much longer than other recent releases. We’ve made significant progress since our last pre-release, but if you decide to try out EF7 then please bear in mind that this preview is designed to give you an idea of what the experience will be like and there are still a number of limitations and missing features that will be addressed before RTM.

EF7 can be used in the .NET Framework, .NET Core (including ASP.NET 5) and Mono apps.

Here is a rough guide to what currently works in Beta 4. Most of these features are a work-in-progress and still have limitations.