Cambios de redestinación para la migración a .NET Framework 4.5.x

En este artículo se enumeran los problemas de compatibilidad de aplicaciones que se introdujeron en .NET Framework 4.5, 4.5.1 y 4.5.2.

.NET Framework 4.5

ASP.NET

Los métodos MachineKey.Encode y MachineKey.Decode ahora están obsoletos

Detalles

Estos métodos están obsoletos. La compilación del código que llama a estos métodos genera una advertencia del compilador.

Sugerencia

Las alternativas recomendadas son Protect(Byte[], String[]) y Unprotect(Byte[], String[]). Como alternativa, se pueden suprimir las advertencias de compilación o usar un compilador anterior para evitarlas. Las API siguen siendo compatibles.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Redestinación

API afectadas

• MachineKey.Encode(Byte[], MachineKeyProtection)
• MachineKey.Decode(String, MachineKeyProtection)

Cambio de interlineado de los cuadros de texto multilínea de ASP.NET al usar AntiXSSEncoder

Detalles

En .NET Framework 4.0, se introdujeron líneas adicionales entre las líneas de un cuadro de texto multilínea en postback si se usaba el elemento System.Web.Security.AntiXss.AntiXssEncoder. En .NET Framework 4.5 no se incluyen estos saltos de línea adicionales, pero únicamente si la aplicación web tiene como destino .NET Framework 4.5.

Sugerencia

Tenga en cuenta que las aplicaciones web de la versión 4.0 redestinadas a .NET Framework 4.5 pueden tener cuadros de texto multilínea mejorados para dejar de introducir saltos de línea adicionales. Si este no es el comportamiento deseado, es posible recuperar el al ejecutar la aplicación en .NET Framework 4.5 estableciendo como destino .NET Framework 4.0.

Nombre	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Redestinación

WebUtility.HtmlEncode y WebUtility.HtmlDecode realizan correctamente el recorrido de ida y vuelta de BMP

Detalles

En las aplicaciones que tienen como destino .NET Framework 4.5, los caracteres que no pertenecen a Basic Multilingual Plane (BMP) realizan correctamente el recorrido de ida y vuelta cuando se pasan al método HtmlDecode(String).

Sugerencia

Este cambio no debería tener ningún efecto en las aplicaciones actuales, pero, para restaurar el comportamiento original, establezca el atributo targetFramework del elemento <httpRuntime> en una cadena distinta a "4.5". También puede establecer los atributos unicodeEncodingConformance y unicodeDecodingConformance del elemento de configuración <webUtility> para controlar este comportamiento con independencia de la versión de .NET Framework que se use como destino.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Redestinación

API afectadas

• WebUtility.HtmlEncode(String)
• WebUtility.HtmlEncode(String, TextWriter)

ClickOnce

Puede producirse un error en las aplicaciones publicadas con ClickOnce que usan un certificado de firma de código SHA-256 en Windows 2003

Detalles

El archivo ejecutable está firmado con SHA-256. Antes se firmaba con SHA1, independientemente de si el certificado de firma de código era SHA-1 o SHA-256. Esto se aplica a lo siguiente:

• Todas las aplicaciones compiladas con Visual Studio 2012 o versiones posteriores.
• Aplicaciones compiladas con Visual Studio 2010 o versiones anteriores en sistemas con .NET Framework 4.5. Además, si está presente .NET Framework 4.5 o versiones posteriores, el manifiesto de ClickOnce también está firmado con SHA-256 para certificados SHA-256, independientemente de la versión de .NET Framework con la que se compiló.

Sugerencia

El cambio en la firma del ejecutable ClickOnce solo afecta a los sistemas Windows Server 2003; necesitan que KB 938397 esté instalado. El cambio al firmar el manifiesto con SHA-256, incluso cuando una aplicación tiene como destino .NET Framework 4.0 o versiones anteriores, introduce una dependencia de tiempo de ejecución en .NET Framework 4.5 o versiones posteriores.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Redestinación

Core

La variable de iterador Foreach ahora tiene como ámbito la iteración, por lo que la semántica de captura de clausura es diferente (en C#5)

Detalles

A partir de C#5 (Visual Studio 2012), las variables de iterador foreach tienen como ámbito la iteración. Esto puede provocar interrupciones si el código dependía anteriormente de que las variables no se incluyeran en la clausura de foreach. El síntoma de este cambio es que una variable de iterador que se pasa a un delegado se trata como el valor que tiene en el momento de creación del delegado, en lugar de como el valor que tiene en el momento de invocarlo.

Sugerencia

Lo ideal sería actualizar el código para que espere el nuevo comportamiento del compilador. Si es necesario usar la semántica anterior, es posible reemplazar la variable de iterador por una variable independiente colocada de forma explícita fuera del ámbito del bucle.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Redestinación

La propiedad IAsyncResult.CompletedSynchronously debe ser correcta para que se complete la tarea resultante

Detalles

Al llamar a TaskFactory.FromAsync, la implementación de la propiedad CompletedSynchronously debe ser correcta para que se complete la tarea resultante. Es decir, la propiedad debe devolver true solo si la implementación se completó de manera sincrónica. Anteriormente, esta propiedad no se comprobaba.

Sugerencia

Si las implementaciones de System.IAsyncResult devuelven true para la propiedad System.IAsyncResult.CompletedSynchronously solo cuando una tarea se completa de manera sincrónica, no se observará ninguna interrupción. Los usuarios deberían revisar las implementaciones de System.IAsyncResult que posean (en caso de poseer alguna) para asegurarse de que evalúan correctamente si una tarea se completó de forma sincrónica o no.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Redestinación

API afectadas

• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>)
• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>, TaskCreationOptions)
• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>, TaskCreationOptions, TaskScheduler)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>)
• TaskFactory.FromAsync(Func<AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, Object)
• TaskFactory.FromAsync(Func<AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, Object)
• TaskFactory.FromAsync<TArg1>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(Func<AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, Object)
• TaskFactory.FromAsync<TResult>(Func<AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>, TaskCreationOptions, TaskScheduler)
• TaskFactory.FromAsync<TArg1,TArg2>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, Object)
• TaskFactory.FromAsync<TArg1,TArg2>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TResult>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, Object)
• TaskFactory.FromAsync<TArg1,TResult>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TResult>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, TArg3, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, TArg3, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TResult>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3,TResult>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, TArg3, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3,TResult>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, TArg3, Object, TaskCreationOptions)

List<T>.ForEach puede iniciar una excepción al modificar un elemento de lista

Detalles

A partir de .NET Framework 4.5, un enumerador ForEach(Action<T>) iniciará una excepción System.InvalidOperationException si se modifica un elemento de la colección que realiza la llamada. En versiones anteriores no se iniciaban excepciones en estos casos, aunque sí podían producirse condiciones de carrera.

Sugerencia

Lo ideal es corregir el código para no modificar listas durante la enumeración de sus elementos, ya que esta nunca es una operación segura. Pero para revertir al comportamiento anterior, es posible seleccionar .NET Framework 4.0 como destino de una aplicación.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Redestinación

API afectadas

• List<T>.ForEach(Action<T>)

El análisis de System.Uri cumple con las disposiciones de RFC 3987

Detalles

El análisis de URI se ha modificado de varias formas en .NET Framework 4.5. Pero tenga en cuenta que estos cambios solo afectan al código que tenga como destino .NET Framework 4.5. Si un binario tiene como destino .NET Framework 4.0, se observará el comportamiento anterior. Entre los cambios efectuados en el análisis de URI en .NET Framework 4.5 se incluyen los siguientes:

• Los análisis de identificadores URI efectuarán comprobaciones de normalización y caracteres conforme a las normas más recientes sobre IRI indicadas en RFC 3987.
• La forma de normalización C de Unicode solo se ejecutará en la sección de host del identificador URI.
• Mailto no válido: Los identificadores URI ahora generarán una excepción.
• Ahora se conservan los puntos finales al final de un segmento de trazado.
• Los identificadores URI de file:// no aplican secuencias de escape al carácter ?.
• Los caracteres de control Unicode U+0080 a U+009F no son compatibles.
• Las secuencias de escape de los caracteres de coma , y %2c no se eliminan automáticamente.

Sugerencia

Si es necesario usar la semántica de análisis de URI anterior de .NET Framework 4.0 (lo que no es habitual), se puede usar si se selecciona .NET Framework 4.0 como destino. Esto se puede hacer mediante un atributo System.Runtime.Versioning.TargetFrameworkAttribute en el ensamblado, o bien a través de la interfaz de usuario del sistema del proyecto de Visual Studio, en la página "Propiedades del proyecto".

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Redestinación

API afectadas

• Uri(String)
• Uri(String, Boolean)
• Uri(String, UriKind)
• Uri(Uri, String)
• Uri.TryCreate(String, UriKind, Uri)
• Uri.TryCreate(Uri, String, Uri)
• Uri.TryCreate(Uri, Uri, Uri)

El método System.Uri.IsWellFormedUriString devuelve false para los identificadores URI relativos con un carácter de dos puntos en el primer segmento

Detalles

A partir de .NET Framework 4.5, IsWellFormedUriString(String, UriKind) tratará los identificadores URI relativos con un : en el primer segmento como mal formados. Se trata de un cambio con respecto al comportamiento de System.Uri.IsWellFormedUriString(String, UriKind) en .NET Framework 4.0 que se realizó para cumplir con RFC3986.

Sugerencia

Este cambio (como muchos otros cambios de URI) solo afecta a las aplicaciones destinadas a .NET Framework 4.5 (o una versión posterior). Para seguir usando el comportamiento anterior, cambie el destino de la aplicación a .NET Framework 4.0. Como alternativa, examine el URI antes de llamar a System.Uri.IsWellFormedUriString(String, UriKind) en busca de caracteres : que se puedan quitar con fines de validación, si quiere el comportamiento anterior.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Redestinación

API afectadas

• Uri.IsWellFormedUriString(String, UriKind)

Entity Framework

La versión de Entity Framework debe coincidir con la versión de .NET Framework

Detalles

La versión de Entity Framework (EF) se debe hacer coincidir con la de .NET Framework. Para .NET Framework 4.5 se recomienda Entity Framework 5. Hay algunos problemas conocidos con EF 4.x en un proyecto de .NET Framework 4.5 relacionados con System.ComponentModel.DataAnnotations. En .NET Framework 4.5, estos se movieron a otro ensamblado, por lo que hay problemas a la hora de determinar qué anotaciones se van a usar.

Sugerencia

Actualizar a Entity Framework 5 para .NET Framework 4.5

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Redestinación

Windows Forms

El constructor EncoderParameter está obsoleto

Detalles

El constructor EncoderParameter(Encoder, Int32, Int32, Int32, Int32) está obsoleto e introducirá advertencias de compilación si se usa.

Sugerencia

Aunque el constructor EncoderParameter(Encoder, Int32, Int32, Int32, Int32) seguirá funcionando, en su lugar hay que usar el constructor siguiente para evitar la advertencia de compilación obsoleta al volver a compilar el código con las herramientas de .NET Framework 4.5: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).

Nombre	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Redestinación

API afectadas

• EncoderParameter(Encoder, Int32, Int32, Int32, Int32)

Windows Communication Foundation (WCF)

Escritura de una salida binaria mediante BodyWriter

Detalles

Si deriva de la clase System.ServiceModel.Channels.BodyWriter y usa la implementación de OnWriteBodyContents(XmlDictionaryWriter writer) para escribir una salida binaria, es posible que sea necesario realizar algunos cambios al volver a establecer .NET Framework 4.5 como destino. Compruebe el estado de escritura y, si es WriterState.Start, emita el elemento XML de ajuste Binary como se muestra en el siguiente fragmento de código.

protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
{
    bool wroteStartElement = false;
    if (writer.WriteState == WriteState.Start)
    {
        writer.WriteStartElement("Binary", string.Empty);
        wroteStartElement = true;
    }
    writer.WriteBase64(buffer, offset, count);
    if (wroteStartElement)
    {
        writer.WriteEndElement();
    }
}

Además, si deriva de la clase System.ServiceModel.Channels.StreamBodyWriter y ha invalidado el método OnWriteBodyContents(XmlDictionaryWriter writer), es posible que se necesiten algunos cambios. Al establecer como destino .NET Framework 4.0, era necesario escribir explícitamente el elemento Binary al invalidar este método. Esto ya no es necesario cuando se tiene como destino .NET Framework 4.5 y hacerlo impide que se escriba el cuerpo.

Windows Presentation Foundation (WPF)

TextBox.Text de WPF se puede desincronizar con el enlace de datos

Detalles

En algunos casos, la propiedad Text refleja un valor anterior al valor de propiedad de enlace de datos si la propiedad se modifica durante una operación de escritura de enlace de datos.

Sugerencia

Esto no debería tener ningún impacto negativo. Sin embargo, puede restaurar el comportamiento anterior estableciendo la propiedad KeepTextBoxDisplaySynchronizedWithTextProperty en false.

	Value
Ámbito	Borde
Versión	4.5
Tipo	Redestinación

API afectadas

• TextBox.Text

Windows Workflow Foundation (WF)

Las nuevas sobrecargas (ambiguas) de Dispatcher.Invoke pueden generar otro comportamiento

Detalles

.NET Framework 4.5 agrega nuevas sobrecargas para Dispatcher.Invoke, entre las que se incluye un parámetro de tipo Action. Cuando el código existente se vuelve a compilar, los compiladores pueden resolver llamadas a métodos Dispatcher.Invoke que tienen un parámetro Delegate como llamadas a métodos Dispatcher.Invoke con un parámetro Action. Si una llamada a una sobrecarga Dispatcher.Invoke con un parámetro Delegate se resuelve como una llamada a una sobrecarga Dispatcher.Invoke con un parámetro Action, se pueden producir las diferencias de comportamiento siguientes:

• Si se produce una excepción, no se inician los eventos UnhandledExceptionFilter y UnhandledException. En su lugar, las excepciones se controlan mediante el evento System.Threading.Tasks.TaskScheduler.UnobservedTaskException.
• Las llamadas a algunos miembros, como Result, se bloquean hasta que se completa la operación.

Sugerencia

Para evitar ambigüedades (y posibles diferencias en el control de excepciones o los comportamientos de bloqueo), el código que llame a Dispatcher.Invoke puede pasar un objeto vacío [] como segundo parámetro de la llamada a Invoke para garantizar que la resolución se resuelva en la sobrecarga del método de .NET Framework 4.0.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Redestinación

API afectadas

• Dispatcher.Invoke(Delegate, Object[])
• Dispatcher.Invoke(Delegate, TimeSpan, Object[])
• Dispatcher.Invoke(Delegate, TimeSpan, DispatcherPriority, Object[])
• Dispatcher.Invoke(Delegate, DispatcherPriority, Object[])

Algunas API WorkFlow de arrastrar y colocar están obsoletas

Detalles

Esta API WorkFlow de arrastrar y colocar está obsoleta y generará advertencias del compilador si la aplicación se vuelve a compilar en 4.5.

Sugerencia

En su lugar, se deben usar las API System.Activities.Presentation.DragDropHelper nuevas compatibles con operaciones con varios objetos. También es posible suprimir las advertencias de compilación o usar un compilador anterior para evitarlas. Las API siguen siendo compatibles.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Redestinación

API afectadas

• DragDropHelper.DoDragMove(WorkflowViewElement, Point)
• DragDropHelper.GetCompositeView(DragEventArgs)
• DragDropHelper.GetDraggedModelItem(DragEventArgs)
• DragDropHelper.GetDroppedObject(DependencyObject, DragEventArgs, EditingContext)

Los tipos de WorkFlow 3.0 están obsoletos

Detalles

Las API de Windows Workflow Foundation (WWF) 3.0 (las procedentes del espacio de nombres System.Workflow) ahora están obsoletas.

Sugerencia

En su lugar, deben usarse nuevas API de WWF 4.0 (en System.Activities). Puede encontrar un ejemplo de uso de las nuevas API aquí. Hay disponible más información aquí. Además, las API de WWF 3.0 continúan siendo compatibles, por lo que pueden seguir usándose. También se puede evitar la advertencia de tiempo de compilación suprimiéndola o usando un compilador anterior.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Redestinación

El método WorkflowDesigner.Load no elimina una propiedad de símbolo

Detalles

Al seleccionar .NET Framework 4.5 como destino en el Diseñador de flujo de trabajo y cargar un flujo de trabajo de la versión 3.5 rehospedado con el método Load(), se inicia una excepción System.Xaml.XamlDuplicateMemberException mientras se guarda el flujo de trabajo.

Sugerencia

Este error solo se manifiesta al seleccionar .NET Framework 4.5 como destino en el Diseñador de flujo de trabajo, por lo que una posible solución alternativa es establecer WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName a la versión 4.0 de .NET Framework.

Como alternativa, el problema se puede evitar mediante el uso del método Load(String) para cargar el flujo de trabajo, en lugar de Load().

Nombre	Valor
Ámbito	Major
Versión	4.5
Tipo	Redestinación

API afectadas

• WorkflowDesigner.Load()

XML, XSLT

Validación del esquema XML más estricta

Detalles

En .NET Framework 4.5, la validación del esquema XML es más estricta. Si usa xsd:anyURI para validar un identificador URI, como un protocolo mailto, la validación producirá un error si hay espacios en el URI. En versiones anteriores de .NET Framework, la validación se realizaba correctamente. El cambio solo afecta a las aplicaciones que tienen como destino .NET Framework 4.5.

Sugerencia

Si se necesita la validación de .NET Framework 4.0 (menos estricta), la aplicación que realiza la validación puede establecer la versión 4.0 de .NET Framework como destino. Pero en la redestinación a .NET Framework 4.5, se debe realizar la revisión del código para asegurarse de que los URI no válidos (con espacios en blanco) no se esperan como valores de atributo con el tipo de datos anyURI.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Redestinación

.NET Framework 4.5.1

ADO.NET

DbParameter.Precision y DbParameter.Scale son ahora miembros virtuales públicos

Detalles

Precision y Scale se implementan como propiedades públicas virtuales. Reemplazan las implementaciones de interfaz explícitas correspondientes, IDbDataParameter.Precision y IDbDataParameter.Scale.

Sugerencia

Al volver a compilar un proveedor de base de datos de ADO.NET, estas diferencias necesitarán que se aplique la palabra clave "override" a las propiedades Scale y Precision. Esto solo es necesario al volver a compilar los componentes; los archivos binarios existentes continuarán funcionando.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Redestinación

API afectadas

• DbParameter.Precision
• DbParameter.Scale

Core

ObsoleteAttribute se exporta como ObsoleteAttribute y DeprecatedAttribute en escenarios de WinMD

Detalles

Cuando se crea una biblioteca de metadatos de Windows (archivo .winmd), el atributo System.ObsoleteAttribute se exporta como System.ObsoleteAttribute y como Windows.Foundation.DeprecatedAttribute.

Sugerencia

Volver a compilar el código fuente existente que usa el atributo System.ObsoleteAttribute puede generar advertencias cuando ese código se usa desde C++/CX o JavaScript. No se recomienda aplicar System.ObsoleteAttribute y Windows.Foundation.DeprecatedAttribute al código en los ensamblados administrados; se podrían producir advertencias de compilación.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5.1
Tipo	Redestinación

Entity Framework

Se puede producir un error MSB4062 al compilar un archivo edmx de Entity Framework con Visual Studio 2013 si se usan las tareas EntityDeploySplit o EntityClean

Detalles

Las herramientas de MSBuild 12.0 (incluidas en Visual Studio 2013) cambiaron las ubicaciones de los archivos de MSBuild, lo que invalida los archivos de destinos antiguos de Entity Framework. El resultado es un error de las tareas EntityDeploySplit y EntityClean debido a que no pueden buscar Microsoft.Data.Entity.Build.Tasks.dll. Tenga en cuenta que esta interrupción se produce como consecuencia del cambio en un conjunto de herramientas (MSBuild/VS), no en .NET Framework. Solo se producirá al actualizar las herramientas de desarrollo, no al actualizar únicamente .NET Framework.

Sugerencia

Los archivos de destinos de Entity Framework se corrigieron para funcionar con el nuevo diseño de MSBuild a partir de .NET Framework 4.6. Este problema se soluciona actualizando a esta versión de .NET Framework. También es posible usar esta solución alternativa para aplicar la revisión directamente a los archivos de destinos.

NOMBRE	Valor
Ámbito	Major
Versión	4.5.1
Tipo	Redestinación

MSBuild

La tarea ResolveAssemblyReference ahora advierte sobre dependencias con la arquitectura incorrecta

Detalles

La tarea emite una advertencia, MSB3270, que indica que una referencia o cualquiera de sus dependencias no coincide con la arquitectura de la aplicación. Por ejemplo, esto ocurre si una aplicación compilada con la opción AnyCPU incluye una referencia a x86. Este tipo de escenario podría producir un error de la aplicación en tiempo de ejecución (en este caso, si la aplicación se implementa como un proceso x64).

Sugerencia

Existen dos áreas de impacto:

• Una nueva compilación genera advertencias que no aparecieron al compilar la aplicación con una versión anterior de MSBuild. Sin embargo, dado que la advertencia identifica un posible origen de errores en el runtime, se debe investigar y solucionar.
• Si las advertencias se tratan como errores, la aplicación no se compilará.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Redestinación

Windows Presentation Foundation (WPF)

No se admite el enlace de datos bidireccional a una propiedad con un establecedor no público

Detalles

Nunca se ha admitido el escenario de tratar de enlazar datos a una propiedad sin establecedor público. A partir de .NET Framework 4.5.1, este escenario iniciará una excepción System.InvalidOperationException. Tenga en cuenta que esta nueva excepción solo se iniciará para aquellas aplicaciones que tengan .NET Framework 4.5.1 como destino específico. Si una aplicación tiene como destino .NET Framework 4.5, se permitirá la llamada. Si la aplicación no tiene como destino ninguna versión concreta de .NET Framework, el enlace se tratará como unidireccional.

Sugerencia

Debería actualizarse la aplicación para utilizar un enlace bidireccional, o bien para exponer públicamente el establecedor de la propiedad. También es posible establecer .NET Framework 4.5 como destino para que la aplicación presente el comportamiento anterior.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Redestinación

API afectadas

• BindingMode.TwoWay

.NET Framework 4.5.2

Visual Basic .NET

VB.NET ya no admite la calificación de espacios de nombres parciales para las API de System.Windows

Detalles

A partir de .NET Framework 4.5.2, los proyectos de VB.NET ya no pueden especificar API de System.Windows con espacios de nombres parciales. Por ejemplo, se producirá un error al hacer referencia a Windows.Forms.DialogResult. En su lugar, el código debe hacer referencia al nombre completo (DialogResult) o importar el espacio de nombres específico y simplemente hacer referencia a System.Windows.Forms.DialogResult.

Sugerencia

Debería actualizarse el código para hacer referencia a las API System.Windows con nombres simples (e importar el espacio de nombres correspondiente) o con nombres completos.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.2
Tipo	Redestinación

Windows Forms

DataObject.GetData ahora recupera los datos como UTF-8

Detalles

Para las aplicaciones que tienen como destino .NET Framework 4 o que se ejecutan en .NET Framework 4.5.1 o versiones anteriores, DataObject.GetData recupera los datos con formato HTML como una cadena ASCII. Como resultado, los caracteres que no son ASCII (cuyos códigos ASCII son mayores que 0x7F) se representan mediante dos caracteres aleatorios.

Para aplicaciones que tienen como destino .NET Framework 4.5 o posterior y que se ejecutan en .NET Framework 4.5.2, DataObject.GetData recupera datos con formato HTML como UTF-8, que representa correctamente caracteres mayores que 0x7F.

Sugerencia

Si implementó una solución alternativa para el problema de codificación mediante cadenas con formato HTML (por ejemplo, mediante la codificación explícita de la cadena HTML recuperada del Portapapeles y su transferencia a System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) y va a redestinar la aplicación de la versión 4 a la versión 4.5, esa solución alternativa se debe eliminar. Si por algún motivo se necesita el comportamiento anterior, la aplicación se puede destinar a .NET Framework 4.0 para obtenerlo.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5.2
Tipo	Redestinación

API afectadas

• DataObject.GetData(String)
• DataObject.GetData(Type)
• DataObject.GetData(String, Boolean)

Windows Workflow Foundation (WF)

El método WorkflowDesigner.Load no elimina una propiedad de símbolo

Detalles

Al seleccionar .NET Framework 4.5 como destino en el Diseñador de flujo de trabajo y cargar un flujo de trabajo de la versión 3.5 rehospedado con el método Load(), se inicia una excepción System.Xaml.XamlDuplicateMemberException mientras se guarda el flujo de trabajo.

Sugerencia

Este error solo se manifiesta al seleccionar .NET Framework 4.5 como destino en el Diseñador de flujo de trabajo, por lo que una posible solución alternativa es establecer WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName a la versión 4.0 de .NET Framework.

Como alternativa, el problema se puede evitar mediante el uso del método Load(String) para cargar el flujo de trabajo, en lugar de Load().

Nombre	Valor
Ámbito	Major
Versión	4.5
Tipo	Redestinación

API afectadas

• WorkflowDesigner.Load()