Povratne informacije Uredi

Retargeting Changes for Migration from .NET Framework 4.5 to 4.5.2

  • Članak
  • 5 min. za čitanje

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

ADO.NET

DbParameter.Precision and DbParameter.Scale are now public virtual members

Details

Precision and Scale are implemented as public virtual properties. They replace the corresponding explicit interface implementations, IDbDataParameter.Precision and IDbDataParameter.Scale.

Suggestion

When re-building an ADO.NET database provider, these differences will require the 'override' keyword to be applied to the Precision and Scale properties. This is only needed when re-building the components; existing binaries will continue to work.

Name Value
Scope Minor
Version 4.5.1
Type Retargeting

Affected APIs

Core

ObsoleteAttribute exports as both ObsoleteAttribute and DeprecatedAttribute in WinMD scenarios

Details

When you create a Windows Metadata library (.winmd file), the System.ObsoleteAttribute attribute is exported as both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute.

Suggestion

Recompilation of existing source code that uses the System.ObsoleteAttribute attribute may generate warnings when consuming that code from C++/CX or JavaScript.We do not recommend applying both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute to code in managed assemblies; it may result in build warnings.

Name Value
Scope Edge
Version 4.5.1
Type Retargeting

Entity Framework

Building an Entity Framework edmx with Visual Studio 2013 can fail with error MSB4062 if using the EntityDeploySplit or EntityClean tasks

Details

MSBuild 12.0 tools (included in Visual Studio 2013) changed MSBuild file locations, causing older Entity Framework targets files to be invalid. The result is that EntityDeploySplit and EntityClean tasks fail because they are unable to find Microsoft.Data.Entity.Build.Tasks.dll. Note that this break is because of a toolset (MSBuild/VS) change, not because of a .NET Framework change. It will only occur when upgrading developer tools, not when merely upgrading the .NET Framework.

Suggestion

Entity Framework targets files are fixed to work with the new MSBuild layout beginning in the .NET Framework 4.6. Upgrading to that version of the Framework will fix this issue. Alternatively, this workaround can be used to patch the targets files directly.

Name Value
Scope Major
Version 4.5.1
Type Retargeting

MSBuild

ResolveAssemblyReference task now warns of dependencies with the wrong architecture

Details

The task emits a warning, MSB3270, which indicates that a reference or any of its dependencies does not match the app's architecture. For example, this occurs if an app that was compiled with the AnyCPU option includes an x86 reference. Such a scenario could result in an app failure at run time (in this case, if the app is deployed as an x64 process).

Suggestion

There are two areas of impact:

  • Recompilation generates warnings that did not appear when the app was compiled under a previous version of MSBuild. However, because the warning identifies a possible source of runtime failure, it should be investigated and addressed.
  • If warnings are treated as errors, the app will fail to compile.
Name Value
Scope Minor
Version 4.5.1
Type Retargeting

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.

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 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 Presentation Foundation (WPF)

Two-way data-binding to a property with a non-public setter is not supported

Details

Attempting to data bind to a property without a public setter has never been a supported scenario. Beginning in the .NET Framework 4.5.1, this scenario will throw an System.InvalidOperationException. Note that this new exception will only be thrown for apps that specifically target the .NET Framework 4.5.1. If an app targets the .NET Framework 4.5, the call will be allowed. If the app does not target a particular .NET Framework version, the binding will be treated as one-way.

Suggestion

The app should be updated to either use one-way binding, or expose the property's setter publicly. Alternatively, targeting the .NET Framework 4.5 will cause the app to exhibit the old behavior.

Name Value
Scope Minor
Version 4.5.1
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