Retargeting Changes for Migration from .NET Framework 4.5.1 to 4.5.2

Introduction

Retargeting changes affect apps that are recompiled to target a different .NET Framework. They include:

  • Changes in the design-time environment. For example, build tools may emit warnings when previously they did not.

  • Changes in the runtime environment. These affect only apps that specifically target the retargeted .NET Framework. Apps that target previous versions of the .NET Framework behave as they did when running under those versions.

In the topics that describe retargeting changes, we have classified individual items by their expected impact, as follows:

Major This is a significant change that affects a large number of apps or that requires substantial modification of code.

Minor This is a change that affects a small number of apps or that requires minor modification of code.

Edge case This is a change that affects apps under very specific scenarios that are not common.

Transparent This is a change that has no noticeable effect on the app's developer or user. The app should not require modification because of this change.

If you are migrating from the .NET Framework 4.5.1 to 4.5.2, review the following topics for application compatibility issues that may affect your app:

Visual Basic .NET

VB.NET no longer supports partial namespace qualification for System.Windows APIs

Details Beginning in .NET Framework 4.5.2, VB.NET projects cannot specify System.Windows APIs with partially-qualified namespaces. For example, referring to Windows.Forms.DialogResult will fail. Instead, code must refer to the fully qualified name (DialogResult) or import the specific namespace and refer simply to DialogResult.
Suggestion Code should be updated to refer to System.Windows APIs either with simple names (and importing the relevant namespace) or with fully qualified names.
Scope Minor
Version 4.5.2
Type Retargeting

Windows Forms

DataObject.GetData now retrieves data as UTF-8

Details For apps that target the .NET Framework 4 or that run on the .NET Framework 4.5.1 or earlier versions, DataObject.GetData retrieves HTML-formatted data as an ASCII string. As a result, non-ASCII characters (characters whose ASCII codes are greater than 0x7F) are represented by two random characters.

For apps that target the .NET Framework 4.5 or later and run on the .NET Framework 4.5.2, DataObject.GetData retrieves HTML-formatted data as UTF-8, which represents characters greater than 0x7F correctly.

Suggestion If you implemented a workaround for the encoding problem with HTML-formatted strings (for example, by explicitly encoding the HTML string retrieved from the Clipboard by passing it to GetString(Byte[], Int32, Int32)) and you're retargeting your app from version 4 to 4.5, that workaround should be removed.If the old behavior is needed for some reason, the app can target the .NET Framework 4.0 to get that behavior.
Scope Edge
Version 4.5.2
Type Retargeting
Affected APIs

Windows Workflow Foundation (WF)

WorkflowDesigner.Load doesn't remove symbol property

Details When targeting the .NET Framework 4.5 in the workflow designer, and loading a re-hosted 3.5 workflow with the Load() method, a XamlDuplicateMemberException is thrown while saving the workflow.
Suggestion This bug only manifests when targeting .NET Framework 4.5 in the workflow designer, so it can be worked around by setting the WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName to the 4.0 .NET Framework.Alternatively, the issue may be avoided by using the Load(String) method to load the workflow, instead of Load().
Scope Major
Version 4.5
Type Retargeting
Affected APIs