Modifications de reciblage pour la migration vers .NET Framework 4.5.x
Cet article répertorie les problèmes de compatibilité des applications introduits dans .NET Framework 4.5, 4.5.1 et 4.5.2.
.NET Framework 4.5
ASP.NET
Les méthodes MachineKey.Encode et MachineKey.Decode sont maintenant obsolètes
Détails
Ces méthodes sont désormais obsolètes. La compilation du code qui appelle ces méthodes génère un avertissement du compilateur.
Suggestion
Les alternatives recommandées sont Protect(Byte[], String[]) et Unprotect(Byte[], String[]). Vous pouvez également supprimer les avertissements de génération, ou les éviter en utilisant un compilateur plus ancien. Ces API sont toujours prises en charge.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4,5 |
| Type | Reciblage |
API affectées
Modification de l’espacement de la zone de texte ASP.NET multiligne lors de l’utilisation d’AntiXSSEncoder
Détails
Dans le .NET Framework 4.0, des lignes supplémentaires étaient insérées dans la zone de texte multiligne lors de la publication (postback), quand vous utilisiez System.Web.Security.AntiXss.AntiXssEncoder. Dans .NET Framework 4.5, ces sauts de ligne supplémentaires ne sont pas inclus si l’application web cible .NET Framework 4.5.
Suggestion
Notez que les applications web 4.0 reciblées vers .NET Framework 4.5 peuvent avoir des zones de texte multilignes améliorées qui ne comportent plus de sauts de ligne supplémentaires. Si ce changement n’est pas souhaitable, vous pouvez obtenir l’ancien comportement dans le .NET Framework 4.5 en ciblant le .NET Framework 4.0.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4,5 |
| Type | Reciblage |
WebUtility.HtmlEncode et WebUtility.HtmlDecode font un aller-retour correct au plan BMP
Détails
Pour les applications qui ciblent .NET Framework 4.5, les caractères extérieurs au plan BMP (Basic Multilingual Plane) font un aller-retour correct quand ils sont passés à la méthode HtmlDecode(String).
Suggestion
Ce changement ne doit avoir aucun effet sur les applications actuelles. Toutefois, pour rétablir le comportement d’origine, affectez à l’attribut targetFramework de l’élément <httpRuntime> la valeur d’une chaîne autre que « 4.5 ». Vous pouvez également définir les attributs unicodeEncodingConformance et unicodeDecodingConformance de l'élément de configuration <webUtility> pour contrôler ce comportement indépendamment de la version ciblée du .NET Framework.
| Nom | Valeur |
|---|---|
| Étendue | Edge |
| Version | 4,5 |
| Type | Reciblage |
API affectées
ClickOnce
Les applications publiées avec ClickOnce qui utilisent un certificat de signature de code SHA-256 peuvent échouer sur Windows 2003
Détails
L'exécutable est signé avec SHA256. Auparavant, il était signé avec SHA1, que le certificat de signature du code ait été SHA-1 ou SHA-256. Cela s’applique aux :
- Toutes les applications générées avec Visual Studio 2012 ou ultérieur.
- Toutes les applications générées avec Visual Studio 2010 ou antérieur en présence de .NET Framework 4.5. En outre, si .NET Framework 4.5 (ou une version ultérieure) est présent, le manifeste ClickOnce est également signé avec SHA-256 pour les certificats SHA-256, quelle que soit la version du .NET Framework sur laquelle il a été compilé.
Suggestion
Le changement de signature de l’exécutable ClickOnce affecte uniquement les systèmes Windows Server 2003. Vous devez installer le correctif logiciel KB 938397. Le changement de signature du manifeste avec l'algorithme SHA-256 même quand une application cible .NET Framework 4.0, ou des versions antérieures, présente une dépendance de runtime sur .NET Framework 4.5 ou version ultérieure.
| Nom | Valeur |
|---|---|
| Étendue | Edge |
| Version | 4,5 |
| Type | Reciblage |
Core
La variable d’itérateur foreach est désormais délimitée au sein de l’itération. La sémantique de capture de clôture est donc différente (en C# 5)
Détails
À compter de C# 5 (Visual Studio 2012), les variables d’itérateur foreach sont délimitées au sein de l’itération. Cela peut provoquer des arrêts d’exécution si le code dépendait du fait que les variables ne soient pas incluses dans la clôture de foreach. Les conséquences de ce changement sont qu’une variable d’itérateur passée à un délégué est considérée comme la valeur qu’elle a au moment où le délégué est créé, plutôt que comme la valeur qu’elle a au moment où le délégué est appelé.
Suggestion
Dans l’idéal, le code doit être mis à jour pour prévoir ce nouveau comportement du compilateur. Si vous avez besoin de l’ancienne sémantique, la variable d’itérateur peut être remplacée par une autre variable placée explicitement en dehors de la portée de la boucle.
| Nom | Valeur |
|---|---|
| Étendue | Majeure |
| Version | 4,5 |
| Type | Reciblage |
La propriété IAsyncResult.CompletedSynchronously doit être correcte pour que la tâche obtenue se termine
Détails
Lors de l’appel à TaskFactory.FromAsync, l’implémentation de la propriété CompletedSynchronously doit être correctement configurée pour que la tâche résultante puisse se terminer. Autrement dit, la propriété doit retourner la valeur true si, et uniquement si, l’implémentation s’est terminée de façon synchrone. Auparavant, la propriété n’était pas vérifiée.
Suggestion
Si les implémentations d’System.IAsyncResult retournent comme il se doit la valeur true pour la propriété System.IAsyncResult.CompletedSynchronously uniquement quand une tâche se termine de façon synchrone, l’exécution n’est pas arrêtée. Les utilisateurs doivent examiner leurs éventuelles implémentations d’System.IAsyncResult afin de vérifier qu’elles évaluent correctement si une tâche se termine de manière synchrone ou non.
| Nom | Valeur |
|---|---|
| Étendue | Edge |
| Version | 4,5 |
| Type | Reciblage |
API affectées
- 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 peut lever une exception quand vous modifiez un élément de la liste
Détails
À compter de .NET Framework 4.5, un énumérateur ForEach(Action<T>) lève une exception System.InvalidOperationException si un élément de la collection appelante est modifié. Avant, il ne levait pas d’exception, mais pouvait entraîner des conditions de concurrence.
Suggestion
Dans l’idéal, le code doit être corrigé de manière à ne pas modifier les listes pendant l’énumération de leurs éléments, car cela n’est jamais une opération sûre. Cependant, pour restaurer le comportement précédent, une application peut cibler .NET Framework 4.0.
| Nom | Valeur |
|---|---|
| Étendue | Edge |
| Version | 4,5 |
| Type | Reciblage |
API affectées
L’analyse des objets System.Uri respecte la norme RFC 3987
Détails
L’analyse URI a changé à différents niveaux dans .NET Framework 4.5. Notez, cependant, que ces changements affectent uniquement le code qui cible .NET Framework 4.5. Si un fichier binaire cible .NET Framework 4.0, l’ancien comportement est appliqué. Les changements appliqués à l’analyse URI dans .NET Framework 4.5 sont les suivants :
- L’analyse des URI effectue la normalisation et la vérification des caractères selon les dernières règles IRI de la norme RFC 3987.
- Le formulaire C de normalisation Unicode n’est appliqué que sur la partie hôte de l’URI.
- Les URI mailto: non valides génèrent désormais une exception.
- Les espaces à la fin d’un segment de chemin sont désormais conservés.
- Les URI
file://n’échappent pas le caractère?. - Les caractères de contrôle Unicode allant de
U+0080àU+009Fne sont pas pris en charge. - Les virgules
,ou%2cne sont pas automatiquement sans séquence d’échappement.
Suggestion
Si l’ancienne sémantique d’analyse URI de .NET Framework 4.0 est nécessaire (et c’est souvent le cas), elle peut être utilisée en ciblant .NET Framework 4.0. Pour cela, utilisez un System.Runtime.Versioning.TargetFrameworkAttribute sur l’assembly ou modifiez les propriétés du projet dans l’interface utilisateur du système de projet de Visual Studio.
| Nom | Valeur |
|---|---|
| Étendue | Majeure |
| Version | 4,5 |
| Type | Reciblage |
API affectées
- 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)
La méthode System.Uri.IsWellFormedUriString retourne la valeur false pour les URI relatifs comprenant un caractère deux-points dans le premier segment
Détails
À compter de .NET Framework 4.5, IsWellFormedUriString(String, UriKind) traite les URI relatifs comprenant un : dans leur premier segment comme n’étant pas bien formés. Il s’agit là d’un changement par rapport au comportement de System.Uri.IsWellFormedUriString(String, UriKind) dans .NET Framework 4.0 qui a été apporté pour qu’il soit conforme à la norme RFC 3986.
Suggestion
Ce changement (comme de nombreux autres changements relatifs aux URI) affecte uniquement les applications qui ciblent .NET Framework 4.5 (ou les versions ultérieures). Pour continuer à utiliser l’ancien comportement, ciblez l’application sur .NET Framework 4.0. Si l’ancien comportement est souhaitable, vous pouvez également analyser les URI avant d’appeler System.Uri.IsWellFormedUriString(String, UriKind) pour rechercher les caractères : que vous voulez supprimer à des fins de validation.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4,5 |
| Type | Reciblage |
API affectées
Entity Framework
La version d’Entity Framework doit correspondre à la version du .NET Framework
Détails
La version d’Entity Framework (EF) doit correspondre à la version de .NET Framework. Entity Framework 5 est recommandé pour .NET Framework 4.5. Il existe certains problèmes connus avec EF 4.x dans un projet .NET Framework 4.5 concernant System.ComponentModel.DataAnnotations. Dans .NET Framework 4.5, ces annotations ont été déplacées vers un autre assembly, ce qui pose problème pour déterminer les annotations à utiliser.
Suggestion
Mise à niveau vers Entity Framework 5 pour .NET Framework 4.5
| Nom | Valeur |
|---|---|
| Étendue | Majeure |
| Version | 4,5 |
| Type | Reciblage |
Windows Forms
Le constructeur EncoderParameter est obsolète
Détails
Le constructeur EncoderParameter(Encoder, Int32, Int32, Int32, Int32) est désormais obsolète et génère des avertissements quand il est utilisé.
Suggestion
Même si le constructeur EncoderParameter(Encoder, Int32, Int32, Int32, Int32) continue de fonctionner, le constructeur suivant doit être utilisé à sa place pour éviter l’avertissement de génération obsolète lors de la recompilation du code avec les outils .NET Framework 4.5 : EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4,5 |
| Type | Reciblage |
API affectées
Windows Communication Foundation (WCF)
Écriture de sortie binaire à l’aide de BodyWriter
Détails
Si vous dérivez de la classe System.ServiceModel.Channels.BodyWriter et que vous utilisez l’implémentation de OnWriteBodyContents(XmlDictionaryWriter writer) pour écrire une sortie binaire, certaines modifications seront peut-être nécessaire lorsque vous reciblerez vers .NET Framework 4.5. Vérifiez l’état d’écriture et, si c’est WriterState.Start, émettez l’élément XML d’enveloppement Binary comme indiqué dans l’extrait de code suivant.
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();
}
}
En outre, si vous dérivez de la classe System.ServiceModel.Channels.StreamBodyWriter et que vous avez remplacé la méthode OnWriteBodyContents(XmlDictionaryWriter writer), certaines modifications peuvent être requises. Lors du ciblage de .NET Framework 4.0, il était nécessaire d’écrire explicitement l’élément Binary lors du remplacement de cette méthode. Cela n’est plus nécessaire lorsque vous ciblez .NET Framework 4.5, ce qui entraîne l’absence d’écriture du corps.
Windows Presentation Foundation (WPF)
Dans WPF, TextBox.Text et la liaison de données peuvent être désynchronisés
Détails
Dans certains cas, la propriété Text reflète une valeur précédente de la propriété liée aux données si cette propriété est modifiée au cours d'une opération d'écriture de liaison de données.
Suggestion
Cela ne doit pas avoir d'impact négatif. Vous pouvez, cependant, restaurer le comportement précédent en affectant à la propriété KeepTextBoxDisplaySynchronizedWithTextProperty la valeur false.
| Valeur | |
|---|---|
| Portée | Edge |
| Version | 4,5 |
| Type | Reciblage |
API affectées
Windows Workflow Foundation (WF)
Les nouvelles surcharges (ambiguës) Dispatcher.Invoke peuvent entraîner un comportement différent
Détails
NET Framework 4.5 ajoute de nouvelles surcharges à Dispatcher.Invoke qui incluent un paramètre de type Action. Quand le code existant est recompilé, les compilateurs peuvent résoudre les appels aux méthodes Dispatcher.Invoke dotées d’un paramètre Delegate comme des appels aux méthodes Dispatcher.Invoke ayant un paramètre Action. Si un appel à une surcharge Dispatcher.Invoke avec paramètre Delegate est résolu comme un appel à une surcharge Dispatcher.Invoke avec paramètre Action, les différences de comportement suivantes peuvent survenir :
- Si une exception se produit, les événements UnhandledExceptionFilter et UnhandledException ne sont pas déclenchés. À la place, les exceptions sont gérées par l'événement System.Threading.Tasks.TaskScheduler.UnobservedTaskException.
- Les appels à certains membres, tels que Result, sont bloqués jusqu'à ce que l'opération soit terminée.
Suggestion
Pour éviter toute ambiguïté (et d’éventuelles différences au niveau de la gestion des exceptions et du blocage des comportements), le code Dispatcher.Invoke appelant peut passer un object[] vide en tant que deuxième paramètre à l’appel Invoke de manière à garantir la résolution de la surcharge de méthode .NET Framework 4.0.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4,5 |
| Type | Reciblage |
API affectées
- Dispatcher.Invoke(Delegate, Object[])
- Dispatcher.Invoke(Delegate, TimeSpan, Object[])
- Dispatcher.Invoke(Delegate, TimeSpan, DispatcherPriority, Object[])
- Dispatcher.Invoke(Delegate, DispatcherPriority, Object[])
Certaines API WorkFlow de glisser-déplacer sont obsolètes
Détails
Cette API WorkFlow de glisser-déplacer est obsolète et génère des avertissements du compilateur si l’application est régénérée avec la version 4.5.
Suggestion
Utilisez à la place les nouvelles API System.Activities.Presentation.DragDropHelper qui prennent en charge les opérations avec plusieurs objets. Vous pouvez également supprimer les avertissements de génération ou les éviter en utilisant un compilateur plus ancien. Ces API sont toujours prises en charge.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4,5 |
| Type | Reciblage |
API affectées
- DragDropHelper.DoDragMove(WorkflowViewElement, Point)
- DragDropHelper.GetCompositeView(DragEventArgs)
- DragDropHelper.GetDraggedModelItem(DragEventArgs)
- DragDropHelper.GetDroppedObject(DependencyObject, DragEventArgs, EditingContext)
Les types WorkFlow 3.0 sont obsolètes
Détails
Les API WWF (Windows Workflow Foundation) 3.0 (celles de l’espace de noms System.Workflow) sont désormais obsolètes.
Suggestion
Les nouvelles API de WWF 4.0 (celles de System.Activities) doivent être utilisées à la place. Vous pouvez consulter un exemple d’utilisation des nouvelles API ici et obtenir une aide ici. Étant donné que les API WWF 3.0 sont toujours prises en charge, vous pouvez également les utiliser et éviter l’avertissement au moment de la génération en le supprimant ou en utilisant un compilateur plus ancien.
| Nom | Valeur |
|---|---|
| Étendue | Majeure |
| Version | 4,5 |
| Type | Reciblage |
WorkflowDesigner.Load ne supprime pas la propriété de symbole
Détails
Quand vous ciblez .NET Framework 4.5 dans le Concepteur de flux de travail et que vous chargez un flux de travail 3.5 réhébergé avec la méthode Load(), une exception System.Xaml.XamlDuplicateMemberException est levée quand vous enregistrez le flux de travail.
Suggestion
Ce bogue se produit uniquement lorsque vous reciblez le .NET Framework 4.5 dans le Concepteur de flux de travail. Vous pouvez donc contourner le problème en définissant WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName sur le .NET Framework 4.0.
Vous pouvez aussi éviter le problème en utilisant la méthode Load(String) pour charger le flux de travail, au lieu de Load().
| Nom | Valeur |
|---|---|
| Étendue | Majeure |
| Version | 4,5 |
| Type | Reciblage |
API affectées
XML, XSLT
La validation du schéma XML est plus stricte
Détails
Dans .NET Framework 4.5, la validation du schéma XML est plus stricte. Si vous utilisez xsd:anyURI pour valider un URI tel qu'un protocole mailto, la validation échoue si l'URI contient des espaces. Dans les versions antérieures du .NET Framework, la validation réussissait. Le changement affecte uniquement les applications qui ciblent .NET Framework 4.5.
Suggestion
Si une validation moins précise de .NET Framework 4.0 est nécessaire, l’application de validation peut cibler la version 4.0 du .NET Framework. Toutefois, si .NET Framework 4.5 est reciblé, effectuez une revue du code pour vérifier que les URI non valides (avec des espaces) ne sont pas attendus comme valeurs d’attribut avec le type de données anyURI.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4,5 |
| Type | Reciblage |
.NET Framework 4.5.1
ADO.NET
DbParameter.Precision et DbParameter.Scale sont maintenant des membres virtuels publics
Détails
Les propriétés Precision et Scale sont implémentées en tant que propriétés virtuelles publiques. Elles remplacent les implémentations d'interface explicites correspondantes, IDbDataParameter.Precision et IDbDataParameter.Scale.
Suggestion
Lorsque vous régénérez un fournisseur de base de données ADO.NET, vous devez désormais appliquer le mot clé « override » aux propriétés Precision et Scale. Cette opération est nécessaire uniquement si vous régénérez les composants. Les fichiers binaires existants continuent de fonctionner.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4.5.1 |
| Type | Reciblage |
API affectées
Core
ObsoleteAttribute est exporté à la fois comme ObsoleteAttribute et comme DeprecatedAttribute dans les scénarios WinMD
Détails
Quand vous créez une bibliothèque de métadonnées Windows (fichier .winmd), l’attribut System.ObsoleteAttribute est exporté à la fois comme System.ObsoleteAttribute et comme Windows.Foundation.DeprecatedAttribute.
Suggestion
La recompilation de code source existant qui utilise l’attribut System.ObsoleteAttribute peut générer des avertissements quand ce code est consommé à partir de C++/CX ou de JavaScript. Nous déconseillons d’appliquer à la fois System.ObsoleteAttribute et Windows.Foundation.DeprecatedAttribute au code d’assemblys managés, car cela peut produire des avertissements de génération.
| Nom | Valeur |
|---|---|
| Étendue | Edge |
| Version | 4.5.1 |
| Type | Reciblage |
Entity Framework
La génération d’un fichier edmx Entity Framework avec Visual Studio 2013 peut échouer avec l’erreur MSB4062 si vous utilisez les tâches EntityDeploySplit ou EntityClean
Détails
L’emplacement des fichiers des outils MSBuild 12.0 (inclus dans Visual Studio 2013) a changé, ce qui rend les anciens fichiers de cibles Entity Framework non valides. Les tâches EntityDeploySplit et EntityClean échouent, car elles ne parviennent pas à trouver Microsoft.Data.Entity.Build.Tasks.dll. Notez que ce problème est dû à un changement d’ensemble d’outils (MSBuild/VS), et non à un changement du .NET Framework. Il est dû à la mise à niveau des outils de développement, et non à celle du .NET Framework.
Suggestion
Les fichiers de cibles Entity Framework ont été corrigés pour fonctionner avec la nouvelle disposition MSBuild de .NET Framework 4.6. Vous pouvez résoudre ce problème en mettant à niveau votre .NET Framework vers la version 4.6. Vous pouvez également appliquer cette solution de contournement pour corriger directement les fichiers de cibles.
| Nom | Valeur |
|---|---|
| Étendue | Majeure |
| Version | 4.5.1 |
| Type | Reciblage |
MSBuild
La tâche ResolveAssemblyReference avertit désormais en cas de dépendances avec une architecture incorrecte
Détails
La tâche émet un avertissement, MSB3270, qui indique qu’une référence ou l’une de ses dépendances ne correspond pas à l’architecture de l’application. Cette situation se produit, par exemple, si une application qui a été compilée avec l'option AnyCPU inclut une référence x86. Ainsi, l'application peut échouer au moment de l'exécution (si l'application est déployée en tant que processus x64 dans notre exemple).
Suggestion
Deux domaines sont impactés :
- La recompilation génère des avertissements qui n'étaient pas apparus quand l'application avait été compilée sous une version antérieure de MSBuild. En revanche, étant donné que l'avertissement identifie une source potentielle d'échec du runtime, vous devez l'examiner et le traiter.
- Si les avertissements sont considérés comme des erreurs, la compilation de l'application échouera.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4.5.1 |
| Type | Reciblage |
Windows Presentation Foundation (WPF)
La liaison de données bidirectionnelle avec une propriété ayant un accesseur Set non public n’est pas prise en charge
Détails
La liaison de données avec une propriété sans accesseur Set public n’a jamais été prise en charge. À compter de .NET Framework 4.5.1, ce scénario lève une exception System.InvalidOperationException. Notez que cette nouvelle exception sera levée uniquement pour les applications qui ciblent spécifiquement le .NET Framework 4.5.1. Si une application cible le .NET Framework 4.5, l’appel sera autorisé. Si l’application ne cible pas une version particulière du .NET Framework, la liaison sera traitée comme étant unidirectionnelle.
Suggestion
L’application doit être mise à jour pour utiliser une liaison unidirectionnelle ou exposer publiquement l’accesseur Set de la propriété. Vous pouvez également cibler le .NET Framework 4.5 pour obtenir l’ancien comportement de l’application.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4.5.1 |
| Type | Reciblage |
API affectées
.NET Framework 4.5.2
Visual Basic .NET
VB.NET ne prend plus en charge la qualification partielle des espaces de noms pour les API System.Windows
Détails
À compter de .NET Framework 4.5.2, les projets VB.NET ne peuvent plus spécifier d’API System.Windows avec des espaces de noms partiellement qualifiés. Par exemple, la référence à Windows.Forms.DialogResult échoue. Le code doit référencer le nom qualifié complet (DialogResult) ou importer l’espace de noms et référencer System.Windows.Forms.DialogResult.
Suggestion
Le code doit être mis à jour pour référencer les API System.Windows avec des noms simples (en important l’espace de noms nécessaire) ou avec des noms qualifiés complets.
| Nom | Valeur |
|---|---|
| Étendue | Secondaire |
| Version | 4.5.2 |
| Type | Reciblage |
Windows Forms
DataObject.GetData récupère maintenant les données au format UTF-8
Détails
Pour les applications qui ciblent le .NET Framework 4 ou qui s’exécutent sur le .NET Framework 4.5.1 ou versions antérieures, DataObject.GetData récupère les données au format HTML sous forme de chaîne ASCII. Ainsi, les caractères non-ASCII (caractères dont les codes ASCII sont supérieurs à 0x7F) sont représentés par deux caractères aléatoires.
Pour les applications qui ciblent le .NET Framework 4.5 ou version ultérieure et qui s’exécutent sur le .NET Framework 4.5.2, DataObject.GetData récupère les données au format HTML sous la forme de données UTF-8, qui représentent correctement les caractères supérieurs à 0x7F.
Suggestion
Si vous avez implémenté une solution de contournement pour ce problème d’encodage des chaînes au format HTML (par exemple, en encodant explicitement la chaîne HTML récupérée à partir du Presse-papiers en la passant à System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) et que vous reciblez votre application de la version 4 à la version 4.5, cette solution doit être supprimée. Si l’ancien comportement est nécessaire, l’application peut cibler le .NET Framework 4.0 pour l’obtenir.
| Nom | Valeur |
|---|---|
| Étendue | Edge |
| Version | 4.5.2 |
| Type | Reciblage |
API affectées
Windows Workflow Foundation (WF)
WorkflowDesigner.Load ne supprime pas la propriété de symbole
Détails
Quand vous ciblez .NET Framework 4.5 dans le Concepteur de flux de travail et que vous chargez un flux de travail 3.5 réhébergé avec la méthode Load(), une exception System.Xaml.XamlDuplicateMemberException est levée quand vous enregistrez le flux de travail.
Suggestion
Ce bogue se produit uniquement lorsque vous reciblez le .NET Framework 4.5 dans le Concepteur de flux de travail. Vous pouvez donc contourner le problème en définissant WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName sur le .NET Framework 4.0.
Vous pouvez aussi éviter le problème en utilisant la méthode Load(String) pour charger le flux de travail, au lieu de Load().
| Nom | Valeur |
|---|---|
| Étendue | Majeure |
| Version | 4,5 |
| Type | Reciblage |
API affectées
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour