Announcing the .NET Framework 4.7.1

Preeti Krishna

October 17th, 2017

Today, we are announcing the release of the .NET Framework 4.7.1. It’s included in the Windows 10 Fall Creators Update. .NET Framework 4.7.1 is also available on Windows 7+ and Windows Server 2008 R2+. We’ve added support for targeting the .NET Framework 4.7.1 in Visual Studio 2017 15.5.

The .NET Framework 4.7.1 includes improvements in several areas:

Accessibility improvements in narration, high contrast and focus control areas

.NET Framework support for .NET Standard 2.0 and compiler features

More secure SHA-2 support in ASP.NET and System.Messaging

Configuration builders

ASP.NET Execution step feature

ASP.NET HttpCookie parsing

Enhancements in Visual Tree for WPF applications

Performance and reliability improvements

You can download the .NET Framework 4.7.1

For building applications targeting .NET 4.7.1 download the Developer Pack. You can see the complete list of improvements in the .NET Framework 4.7.1 release notes. .NET Framework 4.7.1 reference sources are available on the GitHub .NET Reference source read-only repository. .NET Framework 4.7.1 will be available on Windows Update in the near future. Docker images will be made available for this release and we will update this post when available.

Supported Windows Versions

The .NET Framework 4.7.1 is supported on the following Windows versions:

Windows 10 Fall Creators Update (included in-box)

Windows 10 Creators Update

Windows 10 Anniversary Update

Windows 8.1

Windows 7 SP1

The .NET Framework 4.7.1 is supported on the following Windows Server versions:

Windows Server 2016 Version 1709 (included in-box)

Windows Server 2016

Windows Server 2012 R2

Windows Server 2012

Windows Server 2008 R2 SP1

BCL – .NET Standard 2.0 Support

.NET Framework 4.7.1 has built-in support for .NET Standard 2.0. .NET Framework 4.7.1 adds about 200 missing APIs that were part of .NET Standard 2.0 but not actually implemented by .NET Framework 4.6.1, 4.6.2 or 4.7. You can refer to details on .NET Standard on .NET Standard Microsoft docs.

Applications that target .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries. This situation occurred because the .NET Standard 2.0 spec was finalized after .NET Framework 4.6.1 was released. .NET Framework 4.7.1 is the first .NET Framework release after .NET Standard 2.0, enabling us to provide comprehensive .NET Standard 2.0 support.

Experience in .NET Framework 4.6.1 through 4.7

If you use Visual Studio 2017 15.3 or higher, the .NET Standard 2.0 support files are automatically copied to the application’s output folder.

If you use Visual Studio 2015 and use NuGet 3.6, we will prompt you to install a support package which will handle copying the support files to the output directory.

Experience in .NET Framework 4.7.1

These support files no longer have to be deployed with the application – they are built right into the .NET Framework itself.

This also removes the need for binding redirects when using .NET Standard libraries on .NET Framework because the CLR automatically unifies version numbers of assemblies that are part of the platform.

Runtime – GC Performance Improvements

.NET Framework 4.7.1 brings in changes in Garbage Collection (GC) to improve the allocation performance, especially for Large Object Heap (LOH) allocations. This is due to an architectural change to split the heap’s allocation lock into 2, for Small Object Heap (SOH) and LOH. Applications that make a lot of LOH allocations, should see a reduction in allocation lock contention, and see better performance. These improvements allow LOH allocations while Background GC (BGC) is sweeping SOH. Usually the LOH allocator waits for the whole duration of the BGC sweep process before it can satisfy requests to allocate memory. This can hinder performance. You can observe this problem in PerfView’s GCStats where there is an ‘LOH allocation pause (due to background GC) > 200 msec Events’ table. The pause reason is ‘Waiting for BGC to thread free lists’. This feature should help mitigate this problem.

ASP.NET Forms Authentication Credentials

ASP.NET has always allowed developers to store user credentials with hashed passwords in configuration files. Previously, the available hash algorithms for this feature were MD5 or SHA-1. Now new secure SHA-2 hash options like SHA-256, SHA-384 and SHA-512 are added in .NET Framework 4.7.1. SHA-1 is still the default to preserve compatibility.

Refer to the following sample to leverage this new feature.

SHA-2 support for Message.HashAlgorithm

In previous versions, if application code specified a System.Messaging HashAlgorithm value, it was limited to MD5 and SHA-1. With .NET Framework 4.7.1, there is support for HashAlgorithm values for SHA-256, SHA-384, and SHA-512 added to System.Messaging Message.HashAlgorithm. The actual usage of these values is in MSMQ as MSMQ makes the “default” decision and these values are simply passed down to MSMQ. System.Messaging does not do any hashing with these values. Following snippet illustrates how you can enable hashing on a queue and create a message with these new values.

Configuration builders

Configuration builders allow developers to inject and build configuration for applications at runtime, allowing configuration data to be pulled from sources beyond the traditional .config file. In previous versions of the .NET Framework, configuration has been static. Applications only draw configuration data from a limited chain of .config files. With Configuration Builders, applications can apply a custom-defined set of builders to any section of config. These builders are free to modify the configuration data contained in the given config section, or build it entirely from scratch – possibly drawing new data from new sources that are not static files. To use the Configuration Builders feature, developers simply need to declare builders in config, then apply them to configuration sections with the ConfigBuilders tag. To implement custom Configuration Builder, developers can inherit from the System.Configuration.ConfigurationBuilder base class.

Here are some code samples that will enable you to declare, use and apply configuration builders.

ASP.NET Execution Step Feature

ASP.NET processes requests in its predefined pipeline which includes 23 events . ASP.NET executes each event handler as an execution step. With this new ExecutionStepInvoker feature, developers will be able to run this execution step inside their code.

Today ASP.NET can’t flow the execution context due to switching between native threads and managed threads. ASP.NET selectively flows only the HttpContext which may not be sufficient for ambient context scenarios. With this feature we enable modules to restore ambient data. The ExecutionStepInvoker is intended for libraries that care about the execution flow of the application (tracing, profiling, diagnostics, transactions, etc.).

We have added a new API to enable this: HttpApplication.OnExecuteRequestStep(Action<HttpContextBase, Action> callback)

Check the following sample to leverage this new feature.

ASP.NET HttpCookie parsing It can be challenging parsing HttpCookie Set-Cookie/Cookie headers to read and write cookie properties from HTTP Headers. Now, we have provided support for a new API that allows for a standardized way to create an HttpCookie object from a string and accurately capture properties of the cookie like expiration date, path, the secure indicator. Furthermore, it assigns cookie value(s) appropriately. This new ASP.NET API for parsing HttpCookie from Set-Cookie/Cookie headers reads as follows: static bool HttpCookie.TryParse(string s, out HttpCookie result) The following sample illustrates the usage of this new API. Compiler – ValueTuple is Serializable The System.ValueTuple types in .NET Framework 4.7.1 are now marked as Serializable, which allows binary serialization as shown in the example below. Since the syntax for C# 7.0 and VB 15.5 tuple types, for example, (int, string) relies on System.ValueTuple, this should make migrating from System.Tuple to using the new tuple syntax easier. Compiler – Support for ReadOnlyReferences .NET Framework 4.7.1 adds initial support for the ReadOnlyReferences C# 7.2 language feature, which is coming in a future Visual Studio 2017 Update. .NET Framework 4.7.1 introduces the IsReadOnlyAttribute for ReadOnlyReferences feature. This attribute will be used by the compiler to mark members that have readonly-ref return types or parameters. If the compiler is running against an older .NET Framework version, it will generate this attribute and embed it’s definition in the compiled assembly. The following example illustrates C# 7.2 code that can make use of this attribute. Compiler – Support for Runtime Feature Detection This new API provides a way to detect whether a particular runtime supports a certain feature or not. At compile time the API provides a way to do that statically through reflection. Whenever the compiler needs to check for runtime support, it would look for the corresponding well-known enum member, for instance, System.Runtime.CompilerServices.RuntimeCapabilities.SupportsDefaultImplementation. If the member exists, then the feature check is successful or the feature is supported. The value for that enum member is ignored. At runtime the check for feature support is done by calling a static method. This is enabled by the addition of the framework type RuntimeFeature. Tools can query it by calling the static method bool IsSupported(string) to check whether the feature is supported or not, by passing in the string name for a given feature. For example, RuntimeFeature.IsSupported(“FixedGenericAttributes”). Following example illustrates C# 7.2 code that can make use of this attribute. Runtime – Support for Portable PDBs This feature adds support for Portable PDBs in the .NET Framework. Libraries that generate code at runtime, like C# Scripting, would benefit from being able to detect whether the runtime supports Portable PDBs or not. This is because they could emit Portable PDBs instead of Windows PDBs. Emitting Portable PDBs has performance benefits; it is faster and has much smaller memory footprint. In absence of this new API the library would need to resort to hard-coding build numbers of the mscorlib or conservatively assume that .NET Framework doesn’t support Portable PDBs. In addition RuntimeFeature.IsSupported method would be changed to return true if ‘PortablePdb’ is passed to it. Following sample illustrates how this can be passed. Accessibility improvements

.NET Framework 4.7.1 brings in a lot of accessibility improvements across different libraries to align with the broad Microsoft product accessibility goals.

Enabling the Accessibility Improvements

In order for the application to benefit from these changes, it needs to run on the .NET Framework 4.7.1 or later and configured in one of the following ways:

It is recompiled to target the .NET Framework 4.7.1. OR

It opts out of the legacy accessibility behaviors by adding the following AppContext Switch to the <runtime> section of the app config file and setting it to false, as the following example shows.

Applications that target the .NET Framework 4.7.1 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to “true”. Detailed information on all the Accessibility changes are provided in the .NET Framework 4.7.1 Application Compatibility documentation.

Windows Forms Accessibility improvements

Windows Forms accessibility changes are in the following areas:

Improved display during High Contrast mode

Enhanced UI accessibility patterns

Improved UI Accessibility properties with the outcome of improved experiences in accessibility tools like Narrator

High Contrast Improvements

Various controls in WinForms are now improved in the way they render under the various HighContrast modes available in the Operating System (OS). Windows 10 has changed the values for some high contrast system colors and Windows Forms is based on the Windows 10 Win32 framework. For the best experience, run on the latest version of Windows and opt in to the latest OS changes by adding an app.manifest file in a test application and un-comment the Windows 10 supportedOS line so that it looks the following example:

<!– Windows 10 –> <supportedOS Id=”{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}” />

Some examples of High Contrast changes are as follows:

Check marks in MenuStrip items are now easier to view

Disabled MenuStrip Items when selected are now easier to view

Text in a selected button is now contrasting enough with the selection color

Disabled text is now easier to read

Before:

After:

Improved Narrator Support

You can observe the following accessibility improvements in the Narrator area after you opt-in to the Accessibility improvements in .NET Framework 4.7.1.

The MonthCalendar control’s value is now read by the Narrator.

The CheckedListBox now notifies Narrator when the CheckedState property has changed so the user is notified that they’ve changed the value of a list item.

DataGridViewCell now reports the correct read-only status to Narrator.

Narrator can now read Disabled ToolStripMenuItem text when previously it would skip over disabled menu items.

UI Accessibility Patterns

Developers of accessibility technology tools will now be able to leverage common UI Accessibility patterns and properties for several WinForms controls. These improvements include:

The ComboBox and the ToolStripSplitButton now support the Expand/Collapse pattern.

The DataGridViewCheckBoxCell now supports the Toggle Pattern.

The ToolStripItem control supports the Name property and the Expand/Collapse pattern.

The NumericUpDown and DomainUpDown controls now support the Name property.

WPF Accessibility improvements

Accessibility improvements in WPF are in the following areas:

UIAutomation LiveRegion support

Screen Readers

High Contrast

UIAutomation LiveRegion Support

Screen readers such as Narrator help people read the UI contents of an application, usually by text-to-speech output of the UI content that’s currently focused. However, if a UI element changes somewhere in the screen and it is not being focused at that point in time, the user may not be notified, and so they may be missing important information.

LiveRegions are meant to solve this problem. A developer can use them to inform the screen reader, or any other UIAutomation client, that an important change has been made to a UI element. The screen reader can then make decisions of its own as to how and when to inform the user of this change. The LiveSetting property also informs the screen reader of the importance of the UI change to the user.

LiveSettingProperty and LiveRegionChangedEvent have been added to System.Windows.Automation.AutomationElementIdentifiers, settable via XAML.

A new DependencyProperty is now registered for “LiveSetting” under System.Windows.Automation.AutomationProperties, as well as Set and Get methods. System.Windows.Automation.Peers.AutomationPeer now has a new method GetLiveSettingCore, which can be overridden to provide a LiveSetting value.

A new enumeration for the possible values of LiveSetting has been added to System.Windows.Automation.

How to make a LiveRegion?

You can set the AutomationProperties.LiveSetting property on the element of interest to make it a “LiveRegion” as shown in the following sample.

Announcing an important UI change

When the data changes on your LiveRegion, and you feel the need to inform a screen reader about that change, you need to explicitly raise an event as illustrated by the following sample.

Screen reader

You can observe the following accessibility improvements in the screen reader area after you opt-in to the Accessibility improvements in .NET Framework 4.7.1.

In previous versions, Expanders were announced by screen readers as buttons, they are now correctly announced as groups (expand/collapse).

In previous releases, DataGridCells were announced by screen readers as “custom”, they are now correctly announced as data grid cell (localized).

Now Screen readers will announce the name of an editable ComboBox.

In previous releases, PasswordBoxes were announced as “no item in view” or had otherwise incorrect behavior, this issue is now fixed.

High Contrast

There are High Contrast improvements in various WPF controls and they are visible when High Contrast theme is set.

Expander control

The focus visual for the expander control is now visible. The keyboard visuals for combo-box, list-box and radio buttons are visible as well.

Before:

After:

CheckBox and RadioButton

The text in CheckBox and RadioButton is now easier to see when selected in high contrast themes.

Before:

After:

ComboBox

The border of a disabled ComboBox is now the same color as disabled text.

Before:

After:

Disabled and focused buttons use the correct theme color.

Before:

After:

Setting a ComboBox’s style to Toolbar, ComboBoxStyleKey caused the dropdown arrow to be invisible, this issue is now fixed.

Before:

After:

DataGrid

The sort indicator arrow in DataGrid now uses correct theme colors.

Before:

After:

Previously, default link style changed to incorrect color on mouse over in high contrast modes and this is now resolved. Similarly, DataGrid checkbox column now uses the expected colors for keyboard focus feedback.

Before:

After:

.NET Framework 4.7.1 SDK tools – SvcConfigEditor.exe and SvcTraceViewer.exe have improved accessibility in the following areas:

Screen Readers

High Contrast

Keyboard focus order and keyboard navigation

One of the key improvements in SvcConfigEditor.exe is the new Diagnostics screen. In previous versions of SvcConfigEditor, the Performance Counter toggle link had no way of displaying which options where available. It was unclear how to enable and/or disable features, and keyboard navigation was limited and unpredictable. Since most of the GUI design was based on labels without action controls, screen readers failed to read and highlight the items correctly, and labels with colors not compatible with different high-contrast settings where abundantly used.

Before:

After:

Screen Readers

You can observe the following accessibility improvements in the screen reader area in .NET Framework 4.7.1 SDK.

In previous version of SvcConfigEditor.exe, screen readers don’t read when tab to ‘Configuration’/ ‘Services’, they are now correctly announced as ‘Configuration’ and ‘Services’.

In previous version of SvcConfigEditor.exe, screen readers don’t read when tab to ‘Address: XXX’/ ‘Binding: XXX’/ ’Contact: XXX’, they are now correctly announced as ‘Address: XXX’/ ‘Binding: XXX’/ ’Contact: XXX’.

High Contrast

WCF SDK tools have improved varied controls where they are now more visible when High Contrast theme is set. You can refer to the following example of high contrast improvement in SvcConfigEditor.exe. There are many other similar improvements.

Before:

After:

Keyboard Focus Order and Keyboard Navigation

In .NET Framework 4.7.1 WCF SDK tools have improved UI keyboard focus order to make it more logical for keyboard access, and improved some controls to be keyboard accessible. You can refer to the following examples:

In previous version of SvcConfigEditor.exe, focus order in “Edit WCF Configuration” window is inappropriate, they are now in more logical focus order.

In previous version of SvcTraceViewer.exe, when you try to navigate to tool bar menu items using keyboard, the tool bar items were not accessible using keyboard, they are accessible now.

In previous version of SvcTraceViewer.exe, in Graph->Formatted tab, Options items are not keyboard accessible. It now can be accessed via keyboard by arrow down button.

WPF – Changing implicit data templates