A Whirldwind Tour of ASP.NET 5

No notes for slide

https://weblogs.asp.net/scottgu/introducing-asp-net-5
https://channel9.msdn.com/Events/dotnetConf/2015/Introduction-to-ASPNET5

Work from home
Great projects
Microsoft Band
IOT
Xamarin

.NET Framework 4.6.NET Framework 4

There are also investments that are exclusively being made for the .NET Framework 4.6 such as the work we announced in the WPF Roadmap.
http://blogs.msdn.com/b/dotnet/archive/2014/11/12/the-roadmap-for-wpf.aspx

The .NET Framework 4.6 is the next version of the .NET Framework, a Highly compatible, in-place replacement for with .NET 4, 4.5, 4.5.1, and 4.5.2. Leading up to the Preview release, we had been using .NET Framework 4.5.3, however since the payload includes significant features and improvements, we bumped up the version to clearly communicate the magnitude of changes. Note that in the Preview release, you’ll still see instances of “4.5.3” in the .NET Framework and Visual Studio version information. We will be updating these in future releases.
There are many great features in the .NET Framework 4.6 Preview, which you can use today. These range from new WPF features to RyuJIT as well as productivity enhancements in Visual Studio.

WPF Improvements and Roadmap
Today, the WPF team announced the roadmap for the WPF platform. Their post defines the areas of investment in future releases of WPF and details the current progress of improvements made to the WPF platform in the .NET Framework 4.6 and Visual Studio 2015.
The team has made key improvements to WPF in this release:
Transparent child windows
Multi-image cursor files
Re-designed Blend experience
New set of Visual Diagnostics tools
Timeline tool in the Performance and Diagnostics hub
The team has also fixed a set of customer reported issues. The best place to ask WPF questions or engage with the team is in the comments of the WPF team post.

Windows Forms High DPI
Windows Forms High DPI support has been updated to include more controls.

Next Generation JIT Compiler -- RyuJIT
This release includes a new version of RyuJIT, the 64-bit JIT Compiler. It is enabled by default for 64-bit processes.

CLR Performance Improvements
The assembly loader now uses memory more efficiency by unloading IL assemblies after a corresponding NGEN image is loaded. This change is a major benefit for virtual memory for large 32-bit apps (such as Visual Studio) and also saves physical memory.

.NET Language Innovation
In this release, several new C# and Visual Basic language features help reduce boilerplate and clutter in everyday code, encourage a more declarative style of programming, and bring the two languages even closer together. The features listed below will be available to both languages in the final release. A few highlights are shared below. Checkout the C# and VBTeam blogs for all the details.
Methods, getter-only properties etc. can now have a single expression as their body, just like lambdas.
Nameof provides a refactoring-safe way of getting the name of e.g. a parameter, member or type as a string.
Auto-properties can have initializers and no longer require setters.
Index initializers Inside an object initializer you can now initialize a specific index of the new object. C# only.
Exception filters let you look at an exception and decide whether to catch it with a given catch block.
Using null-conditional operators you can get a built-in null check while accessing and invoking members and indexers.
Using clauses for static classes bring their static members directly into scope, so you can. call e.g WriteLine() or Sqrt() without prefixing with the class name.
Await now works in catch and finally blocks, obviating some very tricky workarounds.
String interpolation: String interpolation provides a concise way of describing string templates that insert expressions into format strings (C# only at Preview, both VB and C# at RTM).

2014 ASP.NET 5 announced; 2016 planned release date

When we originally shipped the .NET Framework in 2002 there was only a single framework. Shortly after, we released the .NET Compact Framework which was a subset of the .NET Framework that fit within the footprint of smaller devices, specifically the old Windows Mobile. The compact framework was a separate code base from the .NET Framework. It included the entire vertical: a runtime, a framework, and an application model on top.
Since then, we’ve repeated this sub-setting exercise many times: Silverlight, Windows Phone and most recently for Windows Store. This yields to fragmentation because the .NET Platform isn’t a single entity but a set of platforms, owned by different teams, and maintained independently.
Of course, there is nothing wrong with offering specialized features in order to cater to a particular need. But it becomes a problem if there is no systematic approach and specialization happens at every layer with little to no regards for corresponding layers in other verticals. The outcome is a set of platforms that only share APIs by the fact that they started off from a common code base. Over time this causes more divergence unless explicit (and expensive) measures are taken to converge APIs.
What is the problem with fragmentation? If you only target a single vertical then there really isn’t any problem. You’re provided with an API set that is optimized for your vertical. The problem arises as soon as you want to target the horizontal, that is multiple verticals. Now you have to reason about the availability of APIs and come up with a way to produce assets that work across the verticals you want to target.
Today it’s extremely common to have applications that span devices: there is virtually always a back end that runs on the web server, there is often an administrative front end that uses the Windows desktop, and a set of mobile applications that are exposed to the consumer, available for multiple devices. Thus, it’s critical to support developers in building components that can span all the .NET verticals.

.NET Core is essentially a fork of the NET Framework whose implementation is also optimized around factoring concerns. Even though the scenarios of .NET Native (touch based devices) and ASP.NET 5 (server side web development) are quite different, we were able to provide a unified Base Class Library (BCL).

The API surface area for the .NET Core BCL is identical for both .NET Native as well ASP.NET 5. At the bottom of the BCL we have a very thin layer that is specific to the .NET runtime. We’ve currently two implementations: one is specific to the .NET Native runtime and one that is specific to CoreCLR, which is used by ASP.NET 5. However, that layer doesn’t change very often. It contains types like String and Int32. The majority of the BCL are pure MSIL assemblies that can be shared as-is. In other words, the APIs don’t just look the same – they share the same implementation. For example, there is no reason to have different implementations for collections.

On top of the BCL, there are app-model specific APIs. For instance, the .NET Native side provides APIs that are specific to Windows client development, such as WinRT interop. ASP.NET 5 adds APIs such as MVC that are specific to server- side web development.
We think of .NET Core as not being specific to either .NET Native nor ASP.NET 5 – the BCL and the runtimes are general purpose and designed to be modular. As such, it forms the foundation for all future .NET verticals.

In contrast to the .NET Framework, the .NET Core platform will be delivered as a set of NuGet packages. We’ve settled on NuGet because that’s where the majority of the library ecosystem already is.
In order to continue our effort of being modular and well factored we don’t just provide the entire .NET Core platform as a single NuGet package. Instead, it’s a set of fine grained NuGet packages.

For the BCL layer, we’ll have a 1-to-1 relationship between assemblies and NuGet packages.
Moving forward, the NuGet package will have the same name as the assembly. For example, immutable collections will no longer be delivered in a NuGet package called Microsoft.Bcl.Immutable but instead be in a package calledSystem.Collections.Immutable.
In addition, we’ve decided to use semantic versioning for our assembly versioning. The version number of the NuGet package will align with the assembly version.
The alignment of naming and versioning between assemblies and packages help tremendously with discovery. There is no longer a mystery which NuGet packages contains System.Foo, Version=1.2.3.0 – it’s provided by the System.Foo package in version 1.2.3.
NuGet allows us to deliver .NET Core in an agile fashion. So if we provide an upgrade to any of the NuGet packages, you can simply upgrade the corresponding NuGet reference.
Delivering the framework itself on NuGet also removes the difference between expressing 1st party .NET dependencies and 3rd party dependencies – they are all NuGet dependencies. This enables a 3rd party package to express, for instance, that they need a higher version of the System.Collections library. Installing this 3rd party package can now prompt you to upgrade your reference to System.Collections. You don’t have to understand the dependency graph – you only need to consent making changes to it.
The NuGet based delivery also turns the .NET Core platform into an app-local framework. The modular design of .NET Core ensures that each application only needs to deploy what it needs. We’re also working on enabling smart sharing if multiple applications use the same framework bits. However, the goal is to ensure that each application is logically having its own framework so that upgrading doesn’t interfere with other applications running on the same machine.
Our decision to use NuGet as a delivery mechanism doesn’t change our commitment to compatibility. We continue to take compatibility extremely seriously and will not perform API or behavioral breaking changes once a package is marked as stable. However, the app-local deployment ensures that the rare case where a change that is considered additive breaks an application is isolated to development time only. In other words, for .NET Core these breaks can only occur after you upgraded a package reference. In that very moment, you have two options: addressing the compat glitch in your application or rolling back to the previous version of the NuGet package. But in contrast to the .NET Framework those breaks will not occur after you deployed the application to a customer or the production server.

Build and run cross-platform ASP.NET apps on Windows, Mac and Linux
Built on .NET Core, which supports true side-by-side app versioning
New tooling that simplifies modern Web development
Single aligned web stack for Web UI and Web APIs
Cloud-ready environment-based configuration
Integrated support for creating and using NuGet packages
Built-in support for dependency injection
Ability to host on IIS or self-host in your own process

A Whirldwind Tour of ASP.NET 5

Steven Smith

A Whirldwind Tour of ASP.NET 5