Modifiche di reindirizzamento per la migrazione a .NET Framework 4.5.x

Questo articolo elenca i problemi di compatibilità delle app introdotti in .NET Framework 4.5, 4.5.1 e 4.5.2.

.NET Framework 4.5

ASP.NET

I metodi MachineKey.Encode e MachineKey.Decode sono ora obsoleti

Dettagli

Questi metodi sono ora obsoleti. La compilazione del codice che chiama tali metodi genera un avviso del compilatore.

Suggerimento

Le alternative consigliate sono Protect(Byte[], String[]) e Unprotect(Byte[], String[]). In alternativa, è possibile eliminare gli avvisi di compilazione o evitarli usando un compilatore precedente. Le API sono ancora supportate.

Nome valore
Scope Secondarie
Versione 4.5
Type Ridestinazione

API interessate

La spaziatura ASP.NET TextBox su più righe è cambiata quando si usa AntiXS edizione Standard ncoder

Dettagli

In .NET Framework 4.0 vengono inserite righe aggiuntive tra le righe di una casella di testo a più righe durante il postback, se si usa System.Web.Security.AntiXss.AntiXssEncoder. In .NET Framework 4.5 queste interruzioni di riga aggiuntive non vengono incluse, ma solo se l'app Web è destinata a .NET Framework 4.5

Suggerimento

Tenere presente che le app Web 4.0 ridestinate a .NET Framework 4.5, possono avere caselle di testo a più righe migliorate in modo che non vengano più inserite interruzioni di riga aggiuntive. Se non è opportuno, l'app può avere il comportamento precedente quando viene eseguita in .NET Framework 4.5 usando .NET Framework 4.0 come destinazione.

Nome valore
Scope Secondarie
Versione 4.5
Type Ridestinazione

Round trip corretto di WebUtility.HtmlEncode e WebUtility.HtmlDecode per BMP

Dettagli

Per le applicazioni destinate a .NET Framework 4.5, i caratteri al di fuori del piano di base multilinguistico (BMP, Basic Multilingual Plane) eseguono correttamente il round trip quando vengono passati ai metodi HtmlDecode(String).

Suggerimento

Questa modifica non deve avere alcun effetto sulle applicazioni correnti, ma per ripristinare il comportamento originale, impostare l'attributo dell'elemento targetFramework<httpRuntime> su una stringa diversa da "4.5". È inoltre possibile impostare gli attributi unicodeEncodingConformance e unicodeDecodingConformance dell'elemento di configurazione <webUtility> per controllare questo comportamento indipendentemente dalla versione di destinazione di .NET Framework.

Nome valore
Scope Edge
Versione 4.5
Type Ridestinazione

API interessate

ClickOnce

Possibili errori in Windows 2003 per le app pubblicate con ClickOnce che usano un certificato per la firma del codice SHA-256

Dettagli

Il file eseguibile è firmato con SHA256. In precedenza, veniva firmato con SHA1 indipendentemente dal fatto che il certificato di firma del codice fosse SHA-1 o SHA-256. Si applica a:

  • Tutte le applicazioni compilate con Visual Studio 2012 o versioni successive.
  • Applicazioni compilate con Visual Studio 2010 o versioni precedenti su sistemi in cui è presente .NET Framework 4.5. Se inoltre è presente .NET Framework 4.5 o versione successiva, il manifesto ClickOnce viene firmato anche con SHA-256 per i certificati SHA-256 indipendentemente dalla versione di .NET Framework per cui è stato compilato.

Suggerimento

La modifica della firma del file eseguibile di ClickOnce interessa solo i sistemi Windows Server 2003, in cui è richiesta l'installazione di quanto indicato nell'articolo 938397 della Knowledge Base . La modifica relativa alla firma del manifesto con SHA-256 anche quando un'app è destinata a .NET Framework 4.0 o a versioni precedenti introduce una dipendenza del runtime da .NET Framework 4.5 o da una versione successiva.

Nome valore
Scope Edge
Versione 4.5
Type Ridestinazione

Memoria centrale

L'ambito della variabile iteratore Foreach è ora all'interno dell'iterazione, quindi la semantica di acquisizione della chiusura è diversa (in C# 5)

Dettagli

A partire da C# 5 (Visual Studio 2012), le variabili iteratore foreach hanno ambito limitato all'interno dell'iterazione. Ciò può causare interruzioni se il codice dipende dal fatto che le variabili non siano incluse nella chiusura di foreach. Il sintomo di questa modifica è che una variabile iteratore passata a un delegato viene gestita come avente il valore esistente al momento della creazione del delegato, invece del valore esistente al momento della chiamata del delegato.

Suggerimento

Idealmente, è consigliabile aggiornare il codice in modo che tenga conto del nuovo comportamento del compilatore. Se è richiesta la semantica precedente, la variabile iteratore può essere sostituita con una variabile separata che viene inserita in modo esplicito all'esterno dell'ambito del ciclo.

Nome valore
Scope Principale
Versione 4.5
Type Ridestinazione

La proprietà IAsyncResult.CompletedSynchronously deve essere corretta per garantire il completamento dell'attività risultante

Dettagli

Quando si chiama TaskFactory.FromAsync, l'implementazione della proprietà CompletedSynchronously deve essere corretta per consentire il completamento dell'attività risultante. Ovvero la proprietà deve restituire true unicamente se l'implementazione è stata completata in modo sincrono. Precedentemente, la proprietà non veniva verificata.

Suggerimento

Se le implementazioni di System.IAsyncResult restituiscono correttamente true per la proprietà System.IAsyncResult.CompletedSynchronously solo quando un'attività viene completata in modo sincrono, non verrà applicata alcuna interruzione. È consigliabile che gli utenti verifichino le eventuali implementazioni di System.IAsyncResult di loro proprietà, per assicurarsi che valutino in modo corretto se un'attività viene completata o meno in modo sincrono.

Nome valore
Scope Edge
Versione 4.5
Type Ridestinazione

API interessate

List<T>.ForEach può generare un'eccezione quando si modifica una voce di elenco

Dettagli

A partire da .NET Framework 4.5, un enumeratore ForEach(Action<T>) genera un'eccezione System.InvalidOperationException in caso di modifica di un elemento nella raccolta chiamante. Nelle versioni precedenti questa condizione non genera un'eccezione ma può causare situazioni di race condition.

Suggerimento

Idealmente, il codice dovrebbe essere corretto per evitare la modifica degli elenchi durante l'enumerazione dei relativi elementi, perché questa non è mai un'operazione sicura. Per ripristinare il comportamento precedente, tuttavia, un'app può essere destinata a .NET Framework 4.0.

Nome valore
Scope Edge
Versione 4.5
Type Ridestinazione

API interessate

L'analisi di System.Uri è conforme a RFC 3987

Dettagli

L'analisi URI ha subito vari cambiamenti in .NET Framework 4.5. Si noti, tuttavia, che queste modifiche influiscono solo sul codice destinato a .NET Framework 4.5. Se un file binario è destinato a .NET Framework 4.0, viene rispettato il comportamento precedente. Le modifiche introdotte per l'analisi URI in .NET Framework 4.5 includono:

  • L'analisi URI eseguirà la normalizzazione e il controllo dei caratteri in base alle regole URI più recenti nella specifica RFC 3987.
  • Il formato C di normalizzazione Unicode verrà applicato solo alla parte host dell'URI.
  • Gli URI mailto: non validi causeranno ora un'eccezione.
  • I punti finali alla fine di un segmento di percorso vengono ora mantenuti.
  • Negli URI file:// non viene usato un codice di escape per il carattere ?.
  • I caratteri di controllo Unicode da U+0080 a U+009F non sono supportati.
  • Per i caratteri virgola , o %2c non viene rimosso automaticamente il codice di escape.

Suggerimento

Se la semantica di analisi URI di .NET Framework 4.0 precedente è ancora necessaria, anche se spesso non lo è, è possibile usarla scegliendo .NET Framework 4.0 come destinazione. A tale scopo è possibile usare un System.Runtime.Versioning.TargetFrameworkAttribute nell'assembly o l'interfaccia utente del sistema di progetti di Visual Studio nella pagina delle proprietà del progetto.

Nome valore
Scope Principale
Versione 4.5
Type Ridestinazione

API interessate

Il metodo System.Uri.IsWellFormedUriString restituisce false per gli URI relativi con un carattere due punti nel primo segmento

Dettagli

A partire da .NET Framework 4.5, IsWellFormedUriString(String, UriKind) tratterà gli URI relativi con : nella primo segmento come non ben formati. Si tratta di una modifica rispetto al comportamento di System.Uri.IsWellFormedUriString(String, UriKind) in .NET Framework 4.0, introdotta per conformarsi a RFC3986.

Suggerimento

Questa modifica (come molte altre modifiche relative agli URI) influirà solo sulle applicazioni destinate a .NET Framework 4.5 o versioni successive. Per continuare a usare il comportamento precedente, scegliere .NET Framework 4.0 come destinazione dell'app. In alternativa, analizzare l'URI prima di chiamare System.Uri.IsWellFormedUriString(String, UriKind) per cercare caratteri : che è possibile rimuovere ai fini della convalida, se si desidera mantenere il comportamento precedente.

Nome valore
Scope Secondarie
Versione 4.5
Type Ridestinazione

API interessate

Entity Framework

La versione di Entity Framework deve corrispondere alla versione di .NET Framework

Dettagli

La versione di Entity Framework (EF) deve corrispondere alla versione di .NET Framework. Per .NET Framework 4.5 è consigliato Entity Framework 5. Esistono alcuni problemi noti con Entity Framework 4.x in un progetto .NET Framework 4.5 in relazione a System.ComponentModel.DataAnnotations. In .NET Framework 4.5 questi elementi sono stati spostati in un assembly diverso, quindi esistono problemi che determinano le annotazioni da usare.

Suggerimento

Eseguire l'aggiornamento a Entity Framework 5 per .NET Framework 4.5

Nome valore
Scope Principale
Versione 4.5
Type Ridestinazione

WinForms

Il costruttore EncoderParameter è obsoleto

Dettagli

Il costruttore EncoderParameter(Encoder, Int32, Int32, Int32, Int32) è ora obsoleto e l'eventuale uso causerà avvisi di compilazione.

Suggerimento

Anche se il costruttore EncoderParameter(Encoder, Int32, Int32, Int32, Int32) continuerà a funzionare, è necessario usare il costruttore seguente per evitare l'avviso di compilazione obsoleto durante la ricompilazione del codice con gli strumenti di .NET Framework 4.5: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).

Nome valore
Scope Secondarie
Versione 4.5
Type Ridestinazione

API interessate

Windows Communication Foundation (WCF)

Scrittura di output binari con BodyWriter

Dettagli

Se si deriva dalla classe System.ServiceModel.Channels.BodyWriter e si usa l'implementazione di OnWriteBodyContents(XmlDictionaryWriter writer) per scrivere l'output binario, potrebbe essere necessario apportare alcune modifiche quando si esegue il retarget a .NET Framework 4.5. Controllare lo stato di scrittura e, se è WriterState.Start, generare l'elemento Binary XML di wrapping come illustrato nel frammento di codice seguente.

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();
    }
}

Inoltre, se si deriva dalla classe System.ServiceModel.Channels.StreamBodyWriter ed è stato eseguito l'override del metodo OnWriteBodyContents(XmlDictionaryWriter writer), potrebbero essere necessarie alcune modifiche. Quando la destinazione è .NET Framework 4.0, era necessario scrivere in modo esplicito l'elemento quando si esegue l'override Binary di questo metodo. Questa operazione non è più necessaria quando si usa .NET Framework 4.5 e in questo modo il corpo non viene scritto.

Windows Presentation Foundation (WPF)

TextBox.Text di WPF può non essere sincronizzata con il data binding

Dettagli

In alcuni casi, la proprietà Text riflette un valore precedente del valore della proprietà associata a dati se viene modificata durante un'operazione di scrittura di associazione dati.

Suggerimento

Non dovrebbe avere alcun impatto negativo. Tuttavia, è possibile ripristinare il comportamento precedente impostando la proprietà KeepTextBoxDisplaySynchronizedWithTextProperty su false.

Valore
Scope Edge
Versione 4.5
Type Ridestinazione

API interessate

Windows Workflow Foundation (WF)

Nuovi overload per Dispatcher.Invoke (ambigui) potrebbe causare un comportamento diverso

Dettagli

.NET Framework 4.5 aggiunge nuovi overload a Dispatcher.Invoke che includono un parametro di tipo Action. Se il codice esistente viene ricompilato, i compilatori possono risolvere le chiamate ai metodi Dispatcher.Invoke con un parametro Delegate come chiamate ai metodi Dispatcher.Invoke con un parametro Action. Se una chiamata a un overload Dispatcher.Invoke con un Delegate parametro viene risolta come chiamata a un overload Dispatcher.Invoke con un Action parametro, possono verificarsi le differenze di comportamento seguenti:

Suggerimento

Per evitare ambiguità (e potenziali differenze nella gestione delle eccezioni o per i comportamenti di blocco), il codice che chiama Dispatcher.Invoke può passare un oggetto vuoto [] come secondo parametro della chiamata Invoke per essere certi di usare l'overload del metodo .NET Framework 4.0.

Nome valore
Scope Secondarie
Versione 4.5
Type Ridestinazione

API interessate

Alcune API WorkFlow con trascinamento della selezione sono obsolete

Dettagli

Questa API WorkFlow con trascinamento della selezione è obsoleta e genera avvisi del compilatore se l'app viene ricompilata per la versione 4.5.

Suggerimento

In alternativa è consigliabile usare le nuove API System.Activities.Presentation.DragDropHelper che supportano operazioni con più oggetti. In alternativa, è possibile eliminare gli avvisi di compilazione o evitarli usando un compilatore precedente. Le API sono ancora supportate.

Nome valore
Scope Secondarie
Versione 4.5
Type Ridestinazione

API interessate

I tipi di WorkFlow 3.0 sono obsoleti

Dettagli

Le API Windows Workflow Foundation (WWF) 3.0 (dallo spazio dei nomi System.Workflow) sono obsolete.

Suggerimento

È ora necessario usare le nuove API WWF 4.0 (in System. Activities). Un esempio di uso delle nuove API è disponibile qui e altre indicazioni sono disponibili qui. In alternativa, dato che le API WWF 3.0 sono ancora supportate, è possibile usarle ed evitare l'avviso in fase di compilazione, eliminandolo o usando un compilatore precedente.

Nome valore
Scope Principale
Versione 4.5
Type Ridestinazione

WorkflowDesigner.Load non rimuove la proprietà del simbolo

Dettagli

Se si usa .NET Framework 4.5 come destinazione in Progettazione flussi di lavoro e si carica un flusso di lavoro 3.5 riallocato con il metodo Load(), viene generata un'eccezione System.Xaml.XamlDuplicateMemberException durante il salvataggio del flusso di lavoro.

Suggerimento

Questo bug si manifesta solo quando si seleziona .NET Framework 4.5 come destinazione in Progettazione flussi di lavoro, quindi è possibile evitarlo impostando WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName su .NET Framework 4.0.

In alternativa, è possibile evitare il problema usando il Load(String) metodo per caricare il flusso di Load()lavoro, anziché .

Nome valore
Scope Principale
Versione 4.5
Type Ridestinazione

API interessate

XML, XSLT

La convalida di XML Schema è più rigida

Dettagli

In .NET Framework 4.5 la convalida XML Schema è più rigida. Se si usa xsd:anyURI per convalidare un URI, come un protocollo mailto, la convalida ha esito negativo se sono presenti spazi nell'URI. Nelle versioni precedenti di .NET Framework la convalida aveva esito positivo. La modifica influisce solo sulle applicazioni destinate a .NET Framework 4.5.

Suggerimento

Se è necessario usare la convalida .NET Framework 4.0 meno restrittiva, l'applicazione da convalidare può essere destinata alla versione 4.0 di .NET Framework. In caso di ridestinazione a .NET Framework 4.5, tuttavia, è necessario rivedere il codice per assicurarsi che gli URI non validi (con spazi) non siano previsti come valori di attributo con il tipo di dati anyURI.

Nome valore
Scope Secondarie
Versione 4.5
Type Ridestinazione

.NET Framework 4.5.1

ADO.NET

DbParameter.Precision e DbParameter.Scale sono ora membri virtuali pubblici

Dettagli

Precision e Scale sono implementati come proprietà virtuali pubbliche. Sostituiscono le corrispondenti implementazioni esplicite dell'interfaccia, IDbDataParameter.Precision e IDbDataParameter.Scale.

Suggerimento

Quando si ricompila un provider di database ADO.NET, queste differenze richiederanno l'applicazione della parola chiave 'override' alle proprietà Precision e Scale. Questo è necessario solo quando si ricompilano i componenti. I file binari esistenti continueranno a funzionare.

Nome valore
Scope Secondarie
Versione 4.5.1
Type Ridestinazione

API interessate

Memoria centrale

L'attributo ObsoleteAttribute viene esportato sia come ObsoleteAttribute che come DeprecatedAttribute negli scenari WinMD

Dettagli

Quando si crea una raccolta di metadati Windows (file con estensione winmd), l'attributo System.ObsoleteAttribute viene esportato sia come System.ObsoleteAttribute che come Windows.Foundation.DeprecatedAttribute.

Suggerimento

La ricompilazione del codice sorgente esistente che usa l'attributo System.ObsoleteAttribute può generare avvisi quando si utilizza tale codice da C++/CX o JavaScript. È sconsigliabile applicare sia System.ObsoleteAttribute che Windows.Foundation.DeprecatedAttribute al codice negli assembly gestiti, perché potrebbero essere generati avvisi di compilazione.

Nome valore
Scope Edge
Versione 4.5.1
Type Ridestinazione

Entity Framework

La compilazione di un file edmx di Entity Framework con Visual Studio 2013 può avere esito negativo con errore MSB4062 se si usano le attività EntityDeploySplit o EntityClean

Dettagli

Gli strumenti di MSBuild 12.0 (inclusi in Visual Studio 2013) hanno modificato i percorsi dei file MSBuild, invalidando i vecchi file di destinazioni di Entity Framework. Il risultato è che le attività EntityDeploySplit e EntityClean hanno esito negativo perché non sono in grado di trovare Microsoft.Data.Entity.Build.Tasks.dll. Si noti che questo problema è causato da una modifica del set di strumenti (MSBuild/VS) e non da una modifica di .NET Framework. Si verificherà solo quando si aggiornano gli strumenti di sviluppo, e non aggiornando semplicemente .NET Framework.

Suggerimento

I file di destinazioni di Entity Framework sono stati corretti per supportare il nuovo layout MSBuild a partire da .NET Framework 4.6. L'aggiornamento a tale versione di .NET Framework consentirà di risolvere questo problema. È possibile anche usare questa soluzione alternativa per applicare direttamente una patch ai file di destinazione.

Nome valore
Scope Principale
Versione 4.5.1
Type Ridestinazione

MSBuild

L'attiva ResolveAssemblyReference genera ora avvisi in caso di dipendenze con l'architettura non corretta

Dettagli

L'attività genera un avviso, MSB3270, che indica la mancata corrispondenza di un riferimento o di una delle sue dipendenze all'architettura dell'app. Questa situazione si verifica ad esempio se un'app compilata con l'opzione AnyCPU include un riferimento x86. Uno scenario di questo tipo potrebbe provocare un errore dell'app in fase di esecuzione (nel caso descritto, se l'app viene distribuita come processo x64).

Suggerimento

Le possibili conseguenze riguardano le aree seguenti:

  • La ricompilazione genera avvisi che non venivano visualizzati quando l'app veniva compilata con una versione precedente di MSBuild. Tuttavia, dal momento che l'avviso identifica una possibile fonte di errore di runtime, deve essere analizzato e affrontato.
  • Se gli avvisi vengono considerati errori, la compilazione dell'app non verrà completata.
Nome valore
Scope Secondarie
Versione 4.5.1
Type Ridestinazione

Windows Presentation Foundation (WPF)

Il data binding bidirezionale con una proprietà senza un setter pubblico non è supportato

Dettagli

Il data binding per una proprietà senza un setter pubblico non è mai stata uno scenario supportato. A partire da .NET Framework 4.5.1, questo scenario genererà una System.InvalidOperationException. Si noti che la nuova eccezione verrà generata soltanto per le app destinate specificamente a .NET Framework 4.5.1. Per le app destinate a .NET Framework 4.5, la chiamata sarà consentita. Se l'app non è destinata a una versione specifica di .NET Framework, l'associazione verrà considerata unidirezionale.

Suggerimento

È consigliabile aggiornare l'app per usare l'associazione unidirezionale o esporre pubblicamente il setter della proprietà. In alternativa, è possibile destinare l'app a .NET Framework 4.5 per ottenere il comportamento precedente.

Nome valore
Scope Secondarie
Versione 4.5.1
Type Ridestinazione

API interessate

.NET Framework 4.5.2

Visual Basic .NET

VB.NET non supporta più la qualificazione parziale dello spazio dei nomi per le API System.Windows

Dettagli

A partire da .NET Framework 4.5.2, i progetti VB.NET non possono specificare API System.Windows con spazi dei nomi parzialmente qualificati. Ad esempio, un riferimento a Windows.Forms.DialogResult avrà esito negativo. Il codice deve invece fare riferimento al nome completo (DialogResult) o importare lo spazio dei nomi specifico e fare semplicemente riferimento a System.Windows.Forms.DialogResult.

Suggerimento

È consigliabile aggiornare il codice in modo che faccia riferimento alle API System.Windows tramite nomi semplici (e importare lo spazio dei nomi rilevante) o con nomi completi.

Nome valore
Scope Secondarie
Versione 4.5.2
Type Ridestinazione

WinForms

DataObject.GetData ora recupera i dati come UTF-8

Dettagli

Per le app destinate a .NET Framework 4 o che vengono eseguite in .NET Framework 4.5.1 o in versioni precedenti, DataObject.GetData recupera dati in formato HTML sotto forma di stringa ASCII. Di conseguenza, i caratteri non ASCII, ovvero quelli i cui codici ASCII sono maggiori di 0x7F, vengono rappresentati da due caratteri casuali.

Per le app destinate a .NET Framework 4.5 o versione successiva ed eseguite in .NET Framework 4.5.2, DataObject.GetData recupera i dati in formato HTML come UTF-8, che rappresenta correttamente i caratteri con codici maggiori di 0x7F.

Suggerimento

Se è stata implementata una soluzione alternativa per il problema di codifica con le stringhe in formato HTML, ad esempio codificando in modo esplicito la stringa HTML recuperata dagli Appunti passandola a System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32), e si intende ridestinare l'app dalla versione 4 alla versione 4.5, è necessario rimuovere questa soluzione alternativa. Se per qualche motivo è necessario il comportamento precedente, l'app può essere destinata a .NET Framework 4.0 per ottenere tale comportamento.

Nome valore
Scope Edge
Versione 4.5.2
Type Ridestinazione

API interessate

Windows Workflow Foundation (WF)

WorkflowDesigner.Load non rimuove la proprietà del simbolo

Dettagli

Se si usa .NET Framework 4.5 come destinazione in Progettazione flussi di lavoro e si carica un flusso di lavoro 3.5 riallocato con il metodo Load(), viene generata un'eccezione System.Xaml.XamlDuplicateMemberException durante il salvataggio del flusso di lavoro.

Suggerimento

Questo bug si manifesta solo quando si seleziona .NET Framework 4.5 come destinazione in Progettazione flussi di lavoro, quindi è possibile evitarlo impostando WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName su .NET Framework 4.0.

In alternativa, è possibile evitare il problema usando il Load(String) metodo per caricare il flusso di Load()lavoro, anziché .

Nome valore
Scope Principale
Versione 4.5
Type Ridestinazione

API interessate