Retargeting Changes for Migration from .NET Framework 4.5.1 to 4.5.2
- (4.0 | 4.5)
- (4.0 | 4.5.1)
- (4.0 | 4.5.2)
- (4.0 | 4.6)
- (4.0 | 4.6.1)
- (4.0 | 4.6.2)
- (4.0 | 4.7)
- (4.0 | 4.7.1)
- (4.0 | 4.7.2)
- (4.0 | 4.8)
- (4.5 | 4.5.1)
- (4.5 | 4.5.2)
- (4.5 | 4.6)
- (4.5 | 4.6.1)
- (4.5 | 4.6.2)
- (4.5 | 4.7)
- (4.5 | 4.7.1)
- (4.5 | 4.7.2)
- (4.5 | 4.8)
- (4.5.1 | 4.5.2)
- (4.5.1 | 4.6)
- (4.5.1 | 4.6.1)
- (4.5.1 | 4.6.2)
- (4.5.1 | 4.7)
- (4.5.1 | 4.7.1)
- (4.5.1 | 4.7.2)
- (4.5.2 | 4.6)
- (4.5.2 | 4.6.1)
- (4.5.2 | 4.6.2)
- (4.5.2 | 4.7)
- (4.5.2 | 4.7.1)
- (4.5.2 | 4.7.2)
- (4.5.2 | 4.8)
- (4.6 | 4.6.1)
- (4.6 | 4.6.2)
- (4.6 | 4.7)
- (4.6 | 4.7.1)
- (4.6 | 4.7.2)
- (4.6 | 4.8)
- (4.6.1 | 4.6.2)
- (4.6.1 | 4.7)
- (4.6.1 | 4.7.1)
- (4.6.1 | 4.7.2)
- (4.6.1 | 4.8)
- (4.6.2 | 4.7)
- (4.6.2 | 4.7.1)
- (4.6.2 | 4.7.2)
- (4.6.2 | 4.8)
- (4.7 | 4.7.1)
- (4.7 | 4.7.2)
- (4.7 | 4.8)
- (4.7.1 | 4.7.2)
- (4.7.1 | 4.8)
- (4.7.2 | 4.8)
- (4.8 | 4.8.1)
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 System.Windows.Forms.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.
Name | Value |
---|---|
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.
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 System.Text.UTF8Encoding.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.
Name | Value |
---|---|
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 System.Xaml.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().
Name | Value |
---|---|
Scope | Major |
Version | 4.5 |
Type | Retargeting |
Affected APIs
Feedback
Submit and view feedback for