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
Here are some code samples that will enable you to declare, use and apply configuration builders.
ASP.NET Execution Step Feature
We have added a new API to enable this: HttpApplication.OnExecuteRequestStep(Action<HttpContextBase, Action> callback)
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: 
WCF SDK Tools Accessibility Improvements
.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
This feature enables the automatic update of elements that use implicit DataTemplates after changing a resource. When an application adds, removes, or replaces a value declared in a ResourceDictionary, WPF automatically updates all elements that use the value in most cases, including the implicit style case: <Style TargetType=”Button”. Here the value should apply to all buttons in the scope of the resource. This feature supports a similar update in the implicit data template case where the value should apply to all in-scope ContentPresenters whose content is a Book: <DataTemplate DataType=”{x:Type local:Book}”>
This feature’s principal client is Visual Studio’s “Edit-and-Continue” facility, when a user changes a DataTemplate resource in a running application and expects to see the effect of that change when the application continues. However it could also prove useful to any application with changing DataTemplate resources.
The feature is controlled by a new property ResourceDictionary.InvalidatesImplicitDataTemplateResources. After setting this to True, any changes to DataTemplate resources in the dictionary will cause all ContentPresenters in the scope of the dictionary to re-evaluate their choice of DataTemplate. This is a moderately expensive process – our recommendation is to not to enable it unless you really need it.
WPF – Distinguishing dynamic values in a template
This feature enables a caller to determine whether a value obtained from a template is “dynamic”. Diagnostic assistants, such as Visual Studio’s “Edit-and-Continue” facility, need to know whether a templated value is dynamic, in order to propagate a user’s changes correctly.
The feature is implemented by a new method on the class DependencyPropertyHelper:
This returns true if the template’s value for the given property is “dynamic”, that is if it declared via DynamicResourceReference or TemplateBinding, or via Binding or one of its derived classes.
WPF – SourceInfo for elements in templates
Diagnostic assistants such as Visual Studio’s “Edit-and-Continue” facility can use SourceInfo to locate the file and line number where a given element was declared. The SourceInfo is now available for elements declared in a template loaded from XAML (as opposed to compiled BAML). This enables diagnostic assistants to do a better job. This feature is enabled automatically whenever SourceInfo itself is enabled.
WPF – Enable Visual Diagnostics
This feature provides a number of ways to control the VisualDiagnostics features. Diagnostic assistants can request WPF to share internal information. This feature gives both the assistant and the application developer more control over when this sharing is enabled. The VisualDiagnostic features in WPF, with their introduction in .NET Framework 4.6, were initially only enabled when a managed debugger was attached. However, scenarios have arisen involving other components (besides a debugger) that can reasonably be considered as a diagnostic assistant, e.g. Visual Studio’s design surface. Thus, the need for a public way to control the features. The feature is controlled by two new methods on the class VisualDiagnostics, and by a number of registry keys, app-context switches, and environment variables.
The methods enable and disable the VisualTreeChanged event. You can only enable this event in a “diagnostic scenario”, defined as one of the following:
- A debugger is attached
- Windows 10 Developer Mode is set. More precisely, registry key HKLMSOFTWAREMicrosoftWindowsCurrentVersionAppModelUnlockAllowDevelopmentWithoutDevLicense has value 1
- Environment variable ENABLE_XAML_DIAGNOSTICS_VISUAL_TREE_NOTIFICATIONS is set to a value different from “0” or “false” (case-insensitive).
Changes to the visual tree are disallowed while a VisualTreeChanged event is in progress. Specifically, an InvalidOperationException is thrown by any of the following actions:
- Changing a visual or logical parent
- Changing a resource dictionary
- Changing a DependencyProperty value on a FrameworkElement or FrameworkContentElement.
This guards against unexpected and unsupported re-entrancy.
It is possible to override this InvalidOperationException, should you encounter a situation where debugging is impeded by it. To do so, add the following AppContext Switch to the <runtime> section of the app config file and set it to true,
Switch.System.Windows.Diagnostics.AllowChangesDuringVisualTreeChanged
None of the features mentioned here are supported in production applications. They are intended only for diagnostic assistance.
Finally, you may want to run your application under the debugger, but in “production mode” without any potential interference from the VisualDiagnostic features. To do so, add the following AppContext Switch to the <runtime> section of the app config file and set it to true,
Switch.System.Windows.Diagnostics.DisableDiagnostics
Closing
Please try out these improvements in the .NET Framework and let us know what you think. Please share your feedback in the comments below or on GitHub.
![Rich Lander [MSFT]](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/letter-avatar/cb895f2fa6fae6447bab144d4f3ec4b3.svg){kind=avatar}
Why don’t you publish Git tags in https://github.com/Microsoft/referencesource?. That way it would be easier to determine the right version of the sources for inspection/debugging.
DataGrid
Before:
After:
Looks like in the sort indicator nothing has changed