What’s new in .NET Framework 4.7.1 (Part 3)

Hello Readers,

This post is in continuation with “What’s new in .NET Framework 4.7.1 Part 2“.

[Whats new in .Net Framework 4.7.1 Part 1,Whats new in .Net Framework 4.7.1 Part 2]

New Features includes:

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.

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

• 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 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\ AllowDevelopmentWithoutDevLicense 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

Whats new in .Net Framework 4.7.1 Part 1

Whats new in .Net Framework 4.7.1 Part 2

Whats new in .Net Framework 4.7.1 Part 3

Reference:

MSDN Announcement

For now signing off until next post. If you have any queries/suggestions please let me know in the comment section below.

Thanks for reading!