Neuzuweisungsänderungen für die Migration zu .NET Framework 4.5.x

  • Artikel

In diesem Artikel werden App-Kompatibilitätsprobleme aufgeführt, die in .NET Framework 4.5, 4.5.1 und 4.5.2 auftreten.

.NET Framework 4.5

ASP.NET

Die Methoden MachineKey.Encode und MachineKey.Decode sind jetzt veraltet

Details

Diese Methoden sind jetzt veraltet. Die Kompilierung von Code, der diese Methoden aufruft, erzeugt eine Compilerwarnung.

Vorschlag

Die empfohlenen Alternativen sind Protect(Byte[], String[]) und Unprotect(Byte[], String[]). Alternativ können die Buildwarnungen unterdrückt oder durch die Verwendung eines älteren Compilers vermieden werden. Die APIs werden weiterhin unterstützt.

name Wert
Bereich Gering
Version 4.5
Typ Neuzuweisung

Betroffene APIs

Geänderter Abstand für mehrzeilige ASP.NET-Textfelder (TextBox) bei Verwendung von AntiXSSEncoder

Details

In .NET Framework 4.0 wurden zwischen Zeilen eines mehrzeiligen Textfelds beim Postback zusätzliche Zeilen eingefügt, wenn System.Web.Security.AntiXss.AntiXssEncoder verwendet wird. In .NET Framework 4.5 sind diese zusätzlichen Zeilenumbrüche nicht enthalten, wenn die Web-App auf .NET Framework 4.5 ausgelegt ist.

Vorschlag

Beachten Sie, dass bei Web-Apps der Version 4.0, die auf .NET Framework 4.5 neu ausgelegt wurden, mehrzeilige Textfelder möglicherweise verbessert wurden, damit diese keine zusätzlichen Zeilenumbrüche mehr einfügen. Wenn dies nicht erwünscht ist, kann die App das alte Verhalten verwenden, wenn sie unter .NET Framework 4.5 ausgeführt wird, indem sie auf .NET Framework 4.0 ausgerichtet wird.

Name Wert
Bereich Gering
Version 4.5
Typ Neuzuweisung

WebUtility.HtmlEncode und WebUtility.HtmlDecode führen für die BMP eine ordnungsgemäße Roundtripkonvertierung durch

Details

Bei Anwendungen mit der Zielplattform .NET Framework 4.5 wird für Zeichen, die sich außerhalb der Basic Multilingual Plane (BMP) befinden, eine erfolgreiche Roundtripkonvertierung durchgeführt, wenn sie an die HtmlDecode(String)-Methoden übergeben werden.

Vorschlag

Diese Änderung sollte keine Auswirkung auf aktuelle Anwendungen haben. Wenn Sie jedoch das ursprüngliche Verhalten wiederherstellen möchten, legen Sie das Attribut targetFramework des Elements <httpRuntime> auf eine andere Zeichenfolge als „4.5“ fest. Sie können die unicodeEncodingConformance- und unicodeDecodingConformance-Attribute des <webUtility>-Konfigurationselements auch festlegen, um dieses Verhalten unabhängig von der Zielversion von .NET Framework zu steuern.

name Wert
Bereich Microsoft Edge
Version 4.5
Typ Neuzuweisung

Betroffene APIs

ClickOnce

Mit ClickOnce veröffentlichte Apps, die ein SHA-256-Codesignaturzertifikat verwenden, verursachen unter Windows 2003 möglicherweise einen Fehler

Details

Die ausführbare Datei ist mit SHA256 signiert. Früher wurde sie mit SHA1 signiert, unabhängig davon, ob das Codesignaturzertifikat SHA-1 oder SHA-256 war. Dies gilt für:

  • Alle Anwendungen, die mit Visual Studio 2012 oder höher erstellt wurden.
  • Anwendungen, die mit Visual Studio 2010 oder früher auf Systemen mit vorhandenem .NET Framework 4.5 erstellt wurden. Darüber hinaus wird das ClickOnce-Manifest, wenn .NET Framework 4.5 oder höher vorhanden ist, auch mit SHA-256 für SHA-256-Zertifikate signiert, unabhängig von der .NET Framework-Version, mit der es kompiliert wurde.

Vorschlag

Die Änderung bei der Signierung der ausführbaren ClickOnce-Datei betrifft nur Windows Server 2003-Systeme. Für diese ist die Installation von KB 938397 erforderlich. Die Änderung bei der Signierung des Manifests mit SHA-256, selbst wenn eine App auf .NET Framework 4.0 oder frühere Versionen abzielt, führt eine Laufzeitabhängigkeit von .NET Framework 4.5 oder einer höheren Version ein.

name Wert
Bereich Microsoft Edge
Version 4.5
Typ Neuzuweisung

Core

Der Gültigkeitsbereich der Foreach-Iteratorvariable ist jetzt auf die Iteration beschränkt, weswegen sich die Semantik für die Abschlusserfassung (in C# 5) unterscheidet

Details

Ab C# 5 (Visual Studio 2012) ist der Gültigkeitsbereich von foreach-Iteratorvariablen auf die Iteration beschränkt. Dies kann zu Fehlern führen, wenn der Code zuvor davon abhängig war, dass die Variablen nicht in den foreach-Abschluss einbezogen wurden. Diese Änderung führt dazu, dass eine an einen Delegaten übergebene Iteratorvariable als der Wert behandelt wird, den sie zum Zeitpunkt der Erstellung des Delegaten aufwies, anstatt sie als den Wert zu behandeln, den sie zum Zeitpunkt aufwies, als der Delegat aufgerufen wurde.

Vorschlag

Idealerweise sollte der Code aktualisiert werden, um das neue Compilerverhalten zu erwarten. Wenn die alte Semantik erforderlich ist, kann die Iteratorvariable durch eine separate Variable ersetzt werden, die explizit außerhalb des Gültigkeitsbereichs der Schleife platziert wird.

name Wert
Bereich Hauptversion
Version 4.5
Typ Neuzuweisung

Die IAsyncResult.CompletedSynchronously-Eigenschaft muss korrekt sein, damit die resultierende Aufgabe abgeschlossen wird

Details

Wenn Sie TaskFactory.FromAsync aufrufen, muss die Implementierung der CompletedSynchronously-Eigenschaft korrekt sein, damit die resultierende Aufgabe abgeschlossen wird. Das heißt, die Eigenschaft muss für den Fall, und ausschließlich für den Fall, dass die Implementierung synchron abgeschlossen wurde, „true“ zurückgeben. Zuvor wurde die Eigenschaft nicht überprüft.

Vorschlag

Wenn System.IAsyncResult-Implementierungen nur dann ordnungsgemäß TRUE für die System.IAsyncResult.CompletedSynchronously-Eigenschaft zurückgeben, wenn eine Aufgabe synchron abgeschlossen wurde, tritt kein Fehler auf. Benutzer sollten System.IAsyncResult-Implementierungen überprüfen, die sie ggf. besitzen, um sicherzustellen, dass ordnungsgemäß ausgewertet wird, ob eine Aufgabe synchron abgeschlossen wurde.

name Wert
Bereich Microsoft Edge
Version 4.5
Typ Neuzuweisung

Betroffene APIs

List<T>.ForEach kann beim Ändern eines Listenelements eine Ausnahme auslösen

Details

Ab .NET Framework 4.5 löst ein ForEach(Action<T>)-Enumerator eine System.InvalidOperationException-Ausnahme aus, wenn ein Element in der aufrufenden Sammlung geändert wird. Zuvor hätte dies keine Ausnahme ausgelöst, aber zu Racebedingungen geführt.

Vorschlag

Im Idealfall sollte der Code unveränderlich sein, damit Listen nicht geändert werden, während ihre Elemente aufgezählt werden, da dies nie ein sicherer Vorgang ist. Eine App kann auf .NET Framework 4.0 ausgelegt werden, um zum vorherigen Verhalten zurückzukehren.

name Wert
Bereich Microsoft Edge
Version 4.5
Typ Neuzuweisung

Betroffene APIs

Die System.Uri-Analyse entspricht den Vorgaben in RFC 3987

Details

Die URI-Analyse hat sich seit .NET Framework 4.5 auf verschiedene Weisen geändert. Beachten Sie jedoch, dass sich diese Änderungen nur auf Code auswirken, der auf .NET Framework 4.5 ausgelegt ist. Wenn eine Binärdatei auf .NET Framework 4.0 ausgelegt ist, wird das alte Verhalten beachtet. Änderungen an der URI-Analyse in .NET Framework 4.5 umfassen Folgendes:

  • Die URI-Analyse führt die Normalisierung und Zeichenüberprüfung gemäß den neuesten IRI-Regeln in RFC 3987 aus.
  • Die Unicode-Normalisierungsform C wird nur für den Hostteil des URIs ausgeführt.
  • Ungültige Angabe für „Mailto“: URIs lösen nun eine Ausnahme aus.
  • Nachgestellte Punkte am Ende eines Pfadsegments bleiben nun erhalten.
  • file://-URIs versehen das ?-Zeichen nicht mit einem Escapezeichen.
  • Die Unicode-Steuerzeichen U+0080 bis U+009F werden nicht unterstützt.
  • Für die Kommazeichen , und %2c wird das Escapezeichen nicht automatisch entfernt.

Vorschlag

Wenn die alte Semantik der .NET Framework 4.0-URI-Analyse erforderlich ist (was nicht häufig der Fall ist), kann sie durch Ausrichtung auf .NET Framework 4.0 verwendet werden. Dies kann mithilfe von System.Runtime.Versioning.TargetFrameworkAttribute für die Assembly oder auf der Seite „Projekteigenschaften“ über die Benutzeroberfläche des Projektsystems von Visual Studio erreicht werden.

name Wert
Bereich Hauptversion
Version 4.5
Typ Neuzuweisung

Betroffene APIs

Die Methode System.Uri.IsWellFormedUriString gibt für relative URIs mit einem Doppelpunktzeichen im ersten Segment FALSE zurück

Details

Ab .NET Framework 4.5 zeigt IsWellFormedUriString(String, UriKind) für relative URIs mit einem : im ersten Segment an, dass es sich nicht um einen wohlgeformten relativen URI handelt. Dies ist eine Änderung des System.Uri.IsWellFormedUriString(String, UriKind)-Verhaltens in .NET Framework 4.0, die vorgenommen wurde, um eine Übereinstimmung mit RFC3986 sicherzustellen.

Vorschlag

Diese Änderung wirkt sich (wie viele andere URI-Änderungen auch) nur auf Anwendungen aus, die auf .NET Framework 4.5 (oder höher) ausgerichtet sind. Damit Sie weiterhin das alte Verhalten verwenden können, müssen Sie als Zielplattform für die App NET Framework 4.0 verwenden. Überprüfen Sie alternativ die URIs, bevor Sie System.Uri.IsWellFormedUriString(String, UriKind) aufrufen, und suchen Sie nach :-Zeichen, die Sie für die Überprüfung entfernen sollten, wenn das alte Verhalten bevorzugt wird.

name Wert
Bereich Gering
Version 4.5
Typ Neuzuweisung

Betroffene APIs

Entity Framework

Die Version von Entity Framework muss mit der Version von .NET Framework übereinstimmen

Details

Die Version von Entity Framework muss mit der .NET Framework-Version übereinstimmen. Für .NET Framework 4.5 wird Entity Framework 5 empfohlen. Bei EF 4.x in einem .NET Framework 4.5-Projekt sind im Zusammenhang mit System.ComponentModel.DataAnnotations mehrere Probleme bekannt. In .NET Framework 4.5 wurden diese in eine andere Assembly verschoben. Daher gibt es Probleme mit der Bestimmung der zu verwendenden Anmerkungen.

Vorschlag

Führen Sie bei Verwendung von .NET Framework 4.5 ein Upgrade auf Entity Framework 5 durch.

name Wert
Bereich Hauptversion
Version 4.5
Typ Neuzuweisung

Windows Forms

EncoderParameter ctor ist veraltet

Details

Der EncoderParameter(Encoder, Int32, Int32, Int32, Int32)-Konstruktor ist jetzt veraltet und gibt Buildwarnungen aus, wenn er verwendet wird.

Vorschlag

Obwohl der EncoderParameter(Encoder, Int32, Int32, Int32, Int32)-Konstruktor weiterhin funktioniert, sollte stattdessen der folgende Konstruktor verwendet werden, um die veraltete Buildwarnung zu vermeiden, wenn Code mit .NET Framework 4.5-Tools erneut kompiliert wird: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).

Name Wert
Bereich Gering
Version 4.5
Typ Neuzuweisung

Betroffene APIs

Windows Communication Foundation (WCF)

Schreiben der binären Ausgabe mithilfe von BodyWriter

Details

Wenn Sie von der Klasse System.ServiceModel.Channels.BodyWriter ableiten und die Implementierung von OnWriteBodyContents(XmlDictionaryWriter writer) zum Schreiben der binären Ausgabe verwenden, müssen möglicherweise einige Änderungen vorgenommen werden, wenn Sie das Ziel in .NET Framework 4.5 ändern. Überprüfen Sie den Schreibstatus, und wenn dieser WriterState.Start ist, geben Sie das umschließende Binary-XML-Element aus, wie im folgenden Codeschnipsel gezeigt.

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

Wenn Sie von der Klasse System.ServiceModel.Channels.StreamBodyWriter ableiten und die Methode OnWriteBodyContents(XmlDictionaryWriter writer) überschrieben haben, sind zudem möglicherweise einige Änderungen erforderlich. Mit .NET Framework 4.0 als Ziel war es erforderlich, das Binary-Element explizit zu schreiben, wenn diese Methode überschrieben wird. Das ist nicht mehr erforderlich, wenn Sie .NET Framework 4.5 als Ziel verwenden, und dadurch wird der Textkörper nicht geschrieben.

Windows Presentation Foundation (WPF)

WPF-TextBox.Text wird möglicherweise nicht mehr mit der Datenbindung synchronisiert

Details

In einigen Fällen stellt die Text-Eigenschaft einen früheren Wert des datengebundenen Eigenschaftswerts dar, wenn die Eigenschaft während eines Datenbindungsschreibvorgangs geändert wird.

Vorschlag

Dies sollte keine negativen Auswirkungen haben. Sie können jedoch das vorherige Verhalten wiederherstellen, indem Sie die KeepTextBoxDisplaySynchronizedWithTextProperty-Eigenschaft auf false festlegen.

Wert
Umfang Microsoft Edge
Version 4.5
Typ Neuzuweisung

Betroffene APIs

Windows Workflow Foundation (WF)

Neue (mehrdeutige) Dispatcher.Invoke-Überladungen können zu unterschiedlichem Verhalten führen

Details

.NET Framework 4.5 wurde um neue Überladungen für Dispatcher.Invoke ergänzt, die einen Parameter vom Typ Action enthalten. Wenn vorhandener Code erneut kompiliert wird, lösen die Compiler möglicherweise Aufrufe der Dispatcher.Invoke-Methoden, die einen Delegate-Parameter aufweisen, als Aufrufe von Dispatcher.Invoke-Methoden mit einem Action-Parameter auf. Wird ein Aufruf an eine Dispatcher.Invoke-Überladung mit einem Delegate-Parameter als Aufruf an eine Dispatcher.Invoke-Überladung mit einem Action-Parameter aufgelöst, kann es zu folgenden unterschiedlichen Verhalten kommen:

Vorschlag

Um Unklarheiten zu vermeiden (und mögliche Abweichungen bei der Ausnahmebehandlung oder bei blockierendem Verhalten), kann Code, der „Dispatcher.Invoke“ aufruft, ein leeres Objekt [] als zweiten Parameter an den Invoke-Aufruf übergeben, um sicherzustellen, dass nach der .NET Framework 4.0-Methodenüberladung aufgelöst wird.

name Wert
Bereich Gering
Version 4.5
Typ Neuzuweisung

Betroffene APIs

Einige Drag & Drop-APIs für WorkFlow sind veraltet.

Details

Diese Drag & Drop-API für WorkFlow ist veraltet und löst Compilerwarnungen aus, wenn die App mit Version 4.5 neu erstellt wird.

Vorschlag

Stattdessen sollten neue System.Activities.Presentation.DragDropHelper-APIs verwendet werden, die Vorgänge mit mehreren Objekten unterstützen. Alternativ können die Buildwarnungen unterdrückt oder durch die Verwendung eines älteren Compilers vermieden werden. Die APIs werden weiterhin unterstützt.

name Wert
Bereich Gering
Version 4.5
Typ Neuzuweisung

Betroffene APIs

WorkFlow 3.0-Typen sind veraltet

Details

WWF 3.0-APIs (Windows Workflow Foundation ) (aus dem System.Workflow-Namespace) sind jetzt veraltet.

Vorschlag

Stattdessen sollten die neuen WWF 4.0-APIs (in System.Activities) verwendet werden. Ein Beispiel zur Verwendung der neuen APIs finden Sie hier und weitere Anleitungen sind hier verfügbar. Da die WWF-3.0-APIs weiterhin unterstützt werden, können sie verwendet und die Warnung zur Buildzeit vermieden werden, indem sie entweder unterdrückt oder ein älterer Compiler verwendet wird.

name Wert
Bereich Hauptversion
Version 4.5
Typ Neuzuweisung

WorkflowDesigner.Load entfernt die Symbol-Eigenschaft nicht

Details

Wenn für den Workflow-Designer .NET Framework 4.5 als Zielplattform verwendet und ein neu gehosteter Workflow der Version 3.5 mit der Methode Load() geladen wird, wird beim Speichern des Workflows eine System.Xaml.XamlDuplicateMemberException ausgelöst.

Vorschlag

Dieser Fehler wird nur offenkundig, wenn der Workflow-Designer auf .NET Framework 4.5 ausgerichtet ist. Daher kann das Problem umgangen werden, indem WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName auf .NET Framework 4.0 festgelegt wird.

Alternativ kann das Problem vermieden werden, indem anstelle von Load() die Load(String)-Methode zum Laden des Workflows verwendet wird.

Name Wert
Bereich Hauptversion
Version 4.5
Typ Neuzuweisung

Betroffene APIs

XML, XSLT

Die XML-Schemaüberprüfung ist genauer

Details

In .NET Framework 4.5 ist die XML-Schemaüberprüfung genauer. Wenn Sie xsd:anyURI verwenden, um einen URI wie ein mailto-Protokoll zu überprüfen, tritt bei der Validierung ein Fehler auf, wenn der URI Leerzeichen enthält. In früheren Versionen von .NET Framework war die Validierung erfolgreich. Die Änderung betrifft nur Anwendungen, die auf .NET Framework 4.5 ausgerichtet sind.

Vorschlag

Wenn eine weniger genaue Überprüfung für .NET Framework 4.0 erforderlich ist, kann die überprüfende Anwendung auf Version 4.0 von .NET Framework ausgerichtet werden. Bei einer Neuausrichtung auf .NET Framework 4.5 sollte jedoch ein Code Review erfolgen, um sicherzustellen, dass ungültige URIs (mit Leerzeichen) nicht als Attributwerte mit dem Datentyp „anyURI“ erwartet werden.

name Wert
Bereich Gering
Version 4.5
Typ Neuzuweisung

.NET Framework 4.5.1

ADO.NET

DbParameter.Precision und DbParameter.Scale sind jetzt öffentliche virtuelle Member

Details

Precision und Scale werden als öffentliche virtuelle Eigenschaften implementiert. Sie ersetzen die entsprechenden expliziten Schnittstellenimplementierungen IDbDataParameter.Precision und IDbDataParameter.Scale.

Vorschlag

Wenn Sie einen ADO.NET-Datenbankanbieter neu erstellen, erfordern diese Unterschiede die Anwendung des Schlüsselworts „override“ auf die Eigenschaften „Precision“ und „Scale“. Dies ist nur beim erneuten Erstellen von Komponenten erforderlich. Vorhandene Binärdateien funktionieren weiterhin.

name Wert
Bereich Gering
Version 4.5.1
Typ Neuzuweisung

Betroffene APIs

Core

ObsoleteAttribute wird in WinMD-Szenarios sowohl als ObsoleteAttribute als auch als DeprecatedAttribute exportiert

Details

Wenn Sie eine Windows-Metadatenbibliothek (WINMD-Datei) erstellen, wird das Attribut System.ObsoleteAttribute als System.ObsoleteAttribute und als Windows.Foundation.DeprecatedAttribute exportiert.

Vorschlag

Durch die Neukompilierung von vorhandenem Quellcode, in dem das Attribut System.ObsoleteAttribute verwendet wird, können Warnungen generiert werden, wenn dieser Code von C++/CX oder JavaScript verarbeitet wird. Es wird davon abgeraten, sowohl System.ObsoleteAttribute als auch Windows.Foundation.DeprecatedAttribute in Code in verwalteten Assemblys anzuwenden, da dies zu Buildwarnungen führen kann.

name Wert
Bereich Microsoft Edge
Version 4.5.1
Typ Neuzuweisung

Entity Framework

Beim Erstellen einer Entity Framework-EDMX-Datei mit Visual Studio 2013 kann der Fehler MSB4062 auftreten, wenn die Aufgabe „EntityDeploySplit“ oder „EntityClean“ verwendet wird

Details

MSBuild 12.0-Tools (enthalten in Visual Studio 2013) haben die MSBuild-Dateispeicherorte geändert, wodurch ältere Entity Framework-Zieldateien ungültig geworden sind. Das führt dazu, dass EntityDeploySplit- und EntityClean-Aufgaben fehlschlagen, da sie Microsoft.Data.Entity.Build.Tasks.dll nicht finden können. Beachten Sie, dass dieses Problem aufgrund einer Änderung des Toolsets (MSBuild/VS) und nicht aufgrund einer Änderung an .NET Framework auftritt. Es tritt nur beim Upgrade von Entwicklertools und nicht beim Aktualisieren von .NET Framework auf.

Vorschlag

Die Entity Framework-Zieldateien wurden so korrigiert, dass sie mit dem neuen MSBuild-Layout genutzt werden können, das ab .NET Framework 4.6 verwendet wird. Ein Upgrade auf diese Version von .NET Framework wird dieses Problem beheben. Alternativ können Sie diese Problemumgehung verwenden, um die Zieldateien direkt zu patchen.

name Wert
Bereich Hauptversion
Version 4.5.1
Typ Neuzuweisung

MSBuild

Die ResolveAssemblyReference-Aufgabe warnt jetzt vor Abhängigkeiten von der falschen Architektur

Details

Die Aufgabe gibt die Warnung MSB3270 aus, die angibt, dass ein Verweis oder eine seiner Abhängigkeiten nicht der Architektur der App entspricht. Dies erfolgt z. B., wenn eine App, die mit der AnyCPU-Option kompiliert wurde, einen x86-Verweis enthält. Ein solches Szenario kann einen App-Fehler zur Laufzeit ergeben (in diesem Fall, wenn die App als x64-Prozess bereitgestellt wird).

Vorschlag

Es gibt zwei Bereiche mit Auswirkungen:

  • Bei der Neukompilierung werden Warnungen generiert, die nicht angezeigt wurden, als die App mit einer früheren Version von MSBuild kompiliert wurde. Da die Warnung eine potenzielle Quelle des Laufzeitfehlers angibt, sollte sie untersucht werden.
  • Wenn Warnungen wie Fehler behandelt werden, kann die Anwendung nicht kompiliert werden.
name Wert
Bereich Gering
Version 4.5.1
Typ Neuzuweisung

Windows Presentation Foundation (WPF)

Die bidirektionale Datenbindung an eine Eigenschaft mit einem nicht öffentlichen Setter wird nicht unterstützt

Details

Der Versuch, Daten ohne einen öffentlichen Setter an eine Eigenschaft zu binden, wurde nie unterstützt. Ab .NET Framework 4.5.1 löst dieses Szenario System.InvalidOperationException aus. Beachten Sie, dass diese neue Ausnahme nur für Apps ausgelöst wird, die speziell auf .NET Framework 4.5.1 abzielen. Wenn eine App auf .NET Framework 4.5 ausgerichtet ist, wird der Aufruf zugelassen. Wenn die App nicht auf eine bestimmte Version von .NET Framework ausgerichtet ist, wird die Bindung als unidirektionale Bindung behandelt.

Vorschlag

Die App sollte aktualisiert werden, um entweder die unidirektionale Bindung zu verwenden oder den Setter der Eigenschaft öffentlich zur Verfügung zu stellen. Alternativ können Sie die App auf .NET Framework 4.5 ausrichten, um das alte Verhalten zu erreichen.

name Wert
Bereich Gering
Version 4.5.1
Typ Neuzuweisung

Betroffene APIs

.NET Framework 4.5.2

Visual Basic .NET

VB.NET unterstützt die Angabe partieller Namespaces für System.Windows-APIs nicht mehr

Details

Ab .NET Framework 4.5.2 können VB.NET-Projekte keine System.Windows-APIs mit teilweise qualifizierten Namespaces angeben. Der Verweis auf Windows.Forms.DialogResult führt z. B. zu einem Fehler. Stattdessen muss der Code auf den vollqualifizierten Namen (DialogResult) verweisen oder den bestimmten Namespace importieren und dann einfach auf System.Windows.Forms.DialogResult verweisen.

Vorschlag

Der Code sollte aktualisiert werden, um auf System.Windows-APIs mit einfachen Namen (und den entsprechenden Namespace importieren) oder mit vollqualifizierten Namen zu verweisen.

name Wert
Bereich Gering
Version 4.5.2
Typ Neuzuweisung

Windows Forms

DataObject.GetData ruft Daten jetzt als UTF-8 ab

Details

In Apps, die für .NET Framework 4 konzipiert sind oder die unter .NET Framework 4.5.1 oder früheren Versionen ausgeführt werden, ruft DataObject.GetData HTML-formatierte Daten als ASCII-Zeichenfolge ab. Als Resultat werden nicht-ASCII-Zeichen (Zeichen mit ASCII-Codes größer als 0x7F) durch zwei zufällige Zeichen dargestellt.

In Apps, die .NET Framework 4.5 oder eine neuere Version als Ziel verwenden und unter .NET Framework 4.5.2 ausgeführt werden, ruft DataObject.GetData HTML-formatierte Daten als UTF-8 ab und stellt Zeichen größer als „0x7F“ korrekt dar.

Vorschlag

Wenn Sie eine Problemumgehung für das Codierungsproblem mit HTML-formatierten Zeichenfolgen implementiert haben (z.B. durch explizites Codieren der HTML-Zeichenfolge aus der Zwischenablage durch Übergabe an System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) und das Ziel Ihrer App von Version 4 zu 4.5 neu zuweisen, sollten Sie diese Problemumgehung entfernen. Wenn das alte Verhalten benötigt wird, kann die App auf .NET Framework 4.0 ausgerichtet werden.

name Wert
Bereich Microsoft Edge
Version 4.5.2
Typ Neuzuweisung

Betroffene APIs

Windows Workflow Foundation (WF)

WorkflowDesigner.Load entfernt die Symbol-Eigenschaft nicht

Details

Wenn für den Workflow-Designer .NET Framework 4.5 als Zielplattform verwendet und ein neu gehosteter Workflow der Version 3.5 mit der Methode Load() geladen wird, wird beim Speichern des Workflows eine System.Xaml.XamlDuplicateMemberException ausgelöst.

Vorschlag

Dieser Fehler wird nur offenkundig, wenn der Workflow-Designer auf .NET Framework 4.5 ausgerichtet ist. Daher kann das Problem umgangen werden, indem WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName auf .NET Framework 4.0 festgelegt wird.

Alternativ kann das Problem vermieden werden, indem anstelle von Load() die Load(String)-Methode zum Laden des Workflows verwendet wird.

Name Wert
Bereich Hauptversion
Version 4.5
Typ Neuzuweisung

Betroffene APIs