Neuzuweisungsänderungen für die Migration zu .NET Framework 4.5.x
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
- 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 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
bisU+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
- 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)
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:
- Tritt eine Ausnahme auf, werden die UnhandledExceptionFilter- und UnhandledException-Ereignisse nicht ausgelöst. Stattdessen werden Ausnahmen durch das System.Threading.Tasks.TaskScheduler.UnobservedTaskException-Ereignis behandelt.
- Bis der Vorgang abgeschlossen ist, werden Aufrufe an einige Member, z. B. Result, blockiert.
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
- Dispatcher.Invoke(Delegate, Object[])
- Dispatcher.Invoke(Delegate, TimeSpan, Object[])
- Dispatcher.Invoke(Delegate, TimeSpan, DispatcherPriority, Object[])
- Dispatcher.Invoke(Delegate, DispatcherPriority, Object[])
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
- DragDropHelper.DoDragMove(WorkflowViewElement, Point)
- DragDropHelper.GetCompositeView(DragEventArgs)
- DragDropHelper.GetDraggedModelItem(DragEventArgs)
- DragDropHelper.GetDroppedObject(DependencyObject, DragEventArgs, EditingContext)
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
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für