Partager via

Changements cassants des bibliothèques .NET Core dans .NET Core 1.0-3.0

  • Article

Les bibliothèques .NET principales fournissent les primitives et d’autres types généraux utilisés par .NET Core.

Les changements cassants suivants sont documentés sur cette page :

Modification avec rupture Version introduite
Le passage de GroupCollection à des méthodes d’extension prenant IEnumerable<T> nécessite de lever l’ambiguïté .NET Core 3.0
API qui rapportent désormais le produit de rapport et non la version de fichier .NET Core 3.0
Les instances EncoderFallbackBuffer personnalisées ne peuvent pas revenir en arrière de manière récursive .NET Core 3.0
Modification du comportement d’analyse et de mise en forme à virgule flottante .NET Core 3.0
Les opérations d’analyse à virgule flottante n’échouent plus ou lèvent une OverflowException .NET Core 3.0
InvalidAsynchronousStateException déplacé vers un autre assembly .NET Core 3.0
Le remplacement de séquences d’octets UTF-8 mal formées suit les instructions Unicode .NET Core 3.0
TypeDescriptionProviderAttribute déplacé vers un autre assembly .NET Core 3.0
ZipArchiveEntry ne gère plus les archives avec des tailles d’entrée incohérentes .NET Core 3.0
FieldInfo.SetValue lève une exception pour les champs statiques et init uniquement .NET Core 3.0
Les API de chemin d’accès ne lèvent pas d’exception pour les caractères non valides .NET Core 2.1
Champs privés ajoutés aux types de struct intégrés .NET Core 2.1
Modification de la valeur par défaut de UseShellExecute .NET Core 2.1
Versions OpenSSL sur macOS .NET Core 2.1
UnauthorizedAccessException levée par FileSystemInfo.Attributes .NET Core 1.0
La gestion des exceptions d’état de processus endommagées n’est pas prise en charge .NET Core 1.0
Les propriétés UriBuilder ne précèdent plus les caractères de début .NET Core 1.0
Process.StartInfo lève une exception InvalidOperationException pour les processus que vous n’avez pas démarrés .NET Core 1.0

.NET Core 3.0

Le passage de GroupCollection à des méthodes d’extension prenant IEnumerable<T> nécessite de lever l’ambiguïté

Lors de l’appel d’une méthode d’extension qui prend un IEnumerable<T> sur un GroupCollection, vous devez lever l’ambiguïté du type à l’aide d’un forçage de type.

Description de la modification

À compter de .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implémente IEnumerable<KeyValuePair<String,Group>> en plus des autres types, notamment IEnumerable<Group>. Cela entraîne une ambiguïté lors de l’appel d’une méthode d’extension qui prend un IEnumerable<T>. Si vous appelez une telle méthode d’extension sur une instance GroupCollection, par exemple Enumerable.Count, l’erreur du compilateur suivante s’affichera :

CS1061 : « GroupCollection » ne contient pas de définition pour « Nombre » et aucune méthode d’extension accessible « Nombre » acceptant un premier argument de type « GroupCollection » n’a été trouvée (une directive using ou une référence d’assembly est-elle manquante ?)

Dans les versions précédentes de .NET, il n’y avait aucune ambiguïté et aucune erreur du compilateur.

Version introduite

3.0

Raison du changement

Il s’agissait d’un changement cassant involontaire. Comme c’est le cas depuis un certain temps, nous n’avons pas l’intention de le rétablir. En outre, un tel changement serait lui-même cassant.

Pour les instances GroupCollection, vous pouvez lever l’ambiguïté des appels aux méthodes d’extension qui acceptent un IEnumerable<T> avec un forçage de type.

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

Category

Bibliothèques .NET Core

API affectées

Toute méthode d’extension qui accepte un élément IEnumerable<T> est affectée. Par exemple :

API qui rapportent désormais la version du produit de rapport et non la version de fichier

La plupart des API qui retournent des versions dans .NET Core retournent désormais la version du produit plutôt que la version du fichier.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, les méthodes, telles que Environment.Version, RuntimeInformation.FrameworkDescription et la boîte de dialogue des propriétés de fichier pour les assemblys .NET Core reflètent la version de fichier. À compter de .NET Core 3.0, elles reflètent la version du produit.

La figure suivante illustre la différence entre les informations de version pour l’assembly System.Runtime.dll de .NET Core 2.2 (à gauche) et de .NET Core 3.0 (à droite), comme indiqué dans la boîte de dialogue des propriétés du fichier de l’Explorateur Windows.

Difference in product version information

Version introduite

3.0

Aucun. Ce changement devrait simplifier la détection des versions et la rendre plus intuitive.

Category

Bibliothèques .NET Core

API affectées

Les instances EncoderFallbackBuffer personnalisées ne peuvent pas revenir en arrière de manière récursive

Les instances EncoderFallbackBuffer personnalisées ne peuvent pas revenir en arrière de manière récursive. L’implémentation de EncoderFallbackBuffer.GetNextChar() doit entraîner une séquence de caractères convertible en encodage de destination. Autrement, une exception se produit.

Description de la modification

Pendant une opération de transcodage de caractère à octet, le runtime détecte les séquences UTF-16 mal formées ou non convertibles et fournit ces caractères à la méthode EncoderFallbackBuffer.Fallback. La méthode Fallback détermine quels caractères doivent être substitués aux données non modifiables d’origine et ces caractères sont vidés en appelant EncoderFallbackBuffer.GetNextChar dans une boucle.

Le runtime tente ensuite de transcoder ces caractères de substitution vers l’encodage cible. Si cette opération réussit, le runtime continue le transcodage à partir de l’endroit où il s’est arrêté dans la chaîne d’entrée d’origine.

Auparavant, les implémentations personnalisées de EncoderFallbackBuffer.GetNextChar() peuvent retourner des séquences de caractères qui ne sont pas convertibles en l’encodage de destination. Si les caractères substitués ne peuvent pas être transcodés en l’encodage cible, le runtime appelle de nouveau la méthode EncoderFallbackBuffer.Fallback avec les caractères de substitution, en attendant que la méthode EncoderFallbackBuffer.GetNextChar() retourne une nouvelle séquence de substitution. Ce processus se poursuit jusqu’à ce que le runtime rencontre éventuellement une substitution bien formée, convertible ou jusqu’à ce qu’un nombre maximal de récursions soit atteint.

À compter de .NET Core 3.0, les implémentations personnalisées de EncoderFallbackBuffer.GetNextChar() doivent retourner des séquences de caractères convertibles en l’encodage de destination. Si les caractères substitués ne peuvent pas être transcodés vers l’encodage cible, une exception ArgumentException est levée. Le runtime n’effectue plus d’appels récursifs dans l’instance EncoderFallbackBuffer.

Ce comportement s’applique uniquement lorsque les trois conditions suivantes sont remplies :

  • Le runtime détecte une séquence UTF-16 mal formée ou une séquence UTF-16 qui ne peut pas être convertie en encodage cible.
  • Une commande EncoderFallback personnalisée a été spécifiée.
  • La commande personnalisée EncoderFallback tente de remplacer une nouvelle séquence UTF-16 mal formée ou non convertible.

Version introduite

3.0

La plupart des développeurs n’ont pas besoin de prendre de mesures.

Si une application utilise une classe EncoderFallback et EncoderFallbackBuffer personnalisée, assurez-vous que l’implémentation de EncoderFallbackBuffer.Fallback remplit la mémoire tampon de secours avec des données UTF-16 bien formées qui sont directement convertibles en encodage cible lorsque la méthode Fallback est appelée pour la première fois par le runtime.

Category

Bibliothèques .NET Core

API affectées

Comportement de mise en forme et d’analyse de type virgule flottante modifié

Le comportement d’analyse et de mise en forme de type virgule flottante (par les types Double et Single) est désormais conforme à l’IEEE. Cela garantit que le comportement des types virgule flottante dans .NET correspond à celui d’autres langages conformes à l’IEEE. Par exemple, double.Parse("SomeLiteral") doit toujours correspondre à ce que C# produit pour double x = SomeLiteral.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, la mise en forme avec Double.ToString et Single.ToString et l’analyse avec Double.Parse, Double.TryParse, Single.Parse et Single.TryParse ne sont pas conformes à l’IEEE. Par conséquent, il est impossible de garantir qu’une valeur effectue un aller-retour avec n’importe quelle chaîne de format standard ou personnalisée prise en charge. Pour certaines entrées, la tentative d’analyse d’une valeur formatée peut échouer et, pour d’autres, la valeur analysée n’est pas égale à la valeur d’origine.

À compter de .NET Core 3.0, les opérations d’analyse et de mise en forme de type virgule flottante sont conformes à l’IEEE 754.

Le tableau suivant présente deux extraits de code et la façon dont la sortie change entre .NET Core 2.2 et .NET Core 3.1.

Extrait de code Sortie sur .NET Core 2.2 Sortie sur .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 -0
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Pour plus d’informations, consultez le billet de blog Améliorations de l’analyse et de la mise en forme de type virgule flottante dans .NET Core 3.0.

Version introduite

3.0

La section Impact potentiel sur le code existant du billet de blog Améliorations de l’analyse et de la mise en forme de type virgule flottante dans .NET Core 3.0 suggère les changements que vous pouvez apporter à votre code si vous souhaitez maintenir le comportement précédent.

  • Pour certaines différences de mise en forme, vous pouvez obtenir un comportement équivalent au comportement précédent en spécifiant une chaîne de format différente.
  • Pour les différences d’analyse, il n’existe aucun mécanisme pour revenir au comportement précédent.

Category

Bibliothèques .NET Core

API affectées

Les opérations d’analyse de type virgule flottante n’échouent plus ou lèvent une OverflowException

Les méthodes d’analyse de type virgule flottante ne lèvent plus d’exception OverflowException et ne retournent plus false lorsqu’elles analysent une chaîne dont la valeur numérique est en dehors de la plage du type virgule flottante Single ou Double.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, les méthodes Double.Parse et Single.Parse lèvent une exception OverflowException pour les valeurs en dehors de la plage pour leur type respectif. Les méthodes Double.TryParse et Single.TryParse retournent false pour les représentations de la chaîne des valeurs numériques hors plage.

À compter de .NET Core 3.0, les méthodes Double.Parse, Double.TryParse, Single.Parse et Single.TryParse n’échouent plus lors de l’analyse des chaînes numériques hors limites. Au lieu de cela, les méthodes d’analyse Double retournent Double.PositiveInfinity pour les valeurs supérieures à Double.MaxValue et Double.NegativeInfinity pour les valeurs inférieures à Double.MinValue. De même, les méthodes d’analyse Single retournent Single.PositiveInfinity pour les valeurs supérieures à Single.MaxValue, et Single.NegativeInfinity pour les valeurs inférieures à Single.MinValue.

Ce changement a été apporté pour améliorer la conformité à l’IEEE 754:2008.

Version introduite

3.0

Ce changement peut affecter votre code de deux façons :

  • Votre code dépend du gestionnaire de OverflowException à exécuter lors d’un dépassement. Dans ce cas, vous devez supprimer l’instruction catch et placer tout code nécessaire dans une instruction If qui vérifie si Double.IsInfinity ou Single.IsInfinity est égal à true.

  • Votre code suppose que les valeurs de type virgule flottante sont différentes de Infinity. Dans ce cas, vous devez ajouter le code nécessaire pour vérifier les valeurs de type virgule flottante PositiveInfinity et NegativeInfinity.

Category

Bibliothèques .NET Core

API affectées

InvalidAsynchronousStateException déplacé vers un autre assembly

La classe InvalidAsynchronousStateException a été déplacée.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, la classe InvalidAsynchronousStateException se trouve dans l’assembly System.ComponentModel.TypeConverter.

À compter de .NET Core 3.0, elle réside dans l’assembly System.ComponentModel.Primitives.

Version introduite

3.0

Ce changement affecte uniquement les applications qui utilisent la réflexion pour charger le InvalidAsynchronousStateException en appelant une méthode telle que Assembly.GetType ou une surcharge de Activator.CreateInstance qui suppose que le type se trouve dans un assembly particulier. Si c’est le cas, mettez à jour l’assembly référencé dans l’appel de méthode pour refléter le nouvel emplacement d’assembly du type.

Category

Bibliothèques .NET Core

API affectées

Aucun.

Le remplacement de séquences d’octets UTF-8 mal formées suit les instructions Unicode

Quand la classe UTF8Encoding rencontre une séquence d’octets UTF-8 incorrecte lors d’une opération de transcodage d’un octet à un caractère, elle remplace cette séquence par un caractère de remplacement « � » (caractère de remplacement U + FFFD) dans la chaîne de sortie. .NET Core 3.0 diffère des versions précédentes de .NET Core et de .NET Framework en suivant les meilleures pratiques Unicode pour effectuer ce remplacement pendant l’opération de transcodage.

Cela fait partie d’un effort plus large pour améliorer la gestion UTF-8 dans .NET, notamment par les nouveaux types System.Text.Unicode.Utf8 et System.Text.Rune. Le type UTF8Encoding a reçu des mécanismes de gestion des erreurs améliorés afin qu’il produise une sortie cohérente avec les types nouvellement introduits.

Description de la modification

À compter de .NET Core 3.0, lors du transcodage en caractères, la classe UTF8Encoding effectue une substitution de caractères en fonction des meilleures pratiques Unicode. Le mécanisme de substitution utilisé est décrit parNorme Unicode, Version 12.0, Sec. 3.9 (PDF) dans le titre intitulé Substitution U+FFFD des sous-parties maximales.

Ce comportement s’applique uniquement lorsque la séquence d’octets d’entrée contient des données UTF-8 mal formées. En outre, si l’instance UTF8Encoding a été construite avec throwOnInvalidBytes: true, l’instance UTF8Encoding continue de lever sur une entrée non valide plutôt que d’effectuer un remplacement U+FFFD. Pour plus d’informations sur le constructeur UTF8Encoding, consultez UTF8Encoding(Boolean, Boolean).

Le tableau suivant illustre l’impact de ce changement avec une entrée de 3 octets non valide :

Entrée de 3 octets mal formée Sortie avant .NET Core 3.0 Sortie commençant pas .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (sortie à 2 caractères) [ FFFD FFFD FFFD ] (sortie à 3 caractères)

La sortie à 3 caractères est la sortie préférée, selon le tableau 3-9 du PDF de la norme Unicode précédemment cité.

Version introduite

3.0

Aucune action n’est requise de la part du développeur.

Category

Bibliothèques .NET Core

API affectées

TypeDescriptionProviderAttribute déplacé vers un autre assembly

La classe TypeDescriptionProviderAttribute a été déplacée.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, la classe TypeDescriptionProviderAttribute réside dans l’assembly System.ComponentModel.TypeConverter.

À compter de .NET Core 3.0, elle réside dans l’assembly System.ObjectModel.

Version introduite

3.0

Ce changement affecte uniquement les applications qui utilisent la réflexion pour charger le type TypeDescriptionProviderAttribute en appelant une méthode telle que Assembly.GetType ou une surcharge de Activator.CreateInstance qui suppose que le type se trouve dans un assembly particulier. Si c’est le cas, l’assembly référencé dans l’appel de méthode doit être mis à jour pour refléter le nouvel emplacement d’assembly du type.

Category

Windows Forms

API affectées

Aucun.

ZipArchiveEntry ne gère plus les archives avec des tailles d’entrée incohérentes

Les archives zip indiquent à la fois la taille compressée et la taille non compressée des données dans le répertoire central et l’en-tête local. Les données d’entrée elles-mêmes indiquent également leur taille. Dans .NET Core 2.2 et versions antérieures, ces valeurs n’ont jamais été vérifiées par souci de cohérence. À partir de .NET Core 3.0, elles le sont.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, ZipArchiveEntry.Open() réussit même si l’en-tête local n’est pas en accord avec l’en-tête central du fichier zip. Les données sont compressées jusqu’à ce que la fin du flux compressé soit atteinte même si sa longueur dépasse la taille de fichier non compressée répertoriée dans le répertoire central/en-tête local.

À compter de .NET Core 3.0, la méthode ZipArchiveEntry.Open() vérifie que l’en-tête local et l’en-tête central s’accordent sur les tailles compressée et non compressée d’une entrée. Si ce n’est pas le cas, la méthode lève un InvalidDataException si l’en-tête local et/ou le descripteur de données de l’archive répertorient des tailles qui ne correspondent pas au répertoire central du fichier zip. Lors de la lecture d’une entrée, les données décompressées sont tronquées à la taille de fichier non compressée répertoriée dans l’en-tête.

Ce changement a été apporté pour s’assurer qu’un ZipArchiveEntry représente correctement la taille de ses données et que seule cette quantité de données est lue.

Version introduite

3.0

Repackagez toute archive zip qui présente ces problèmes.

Category

Bibliothèques .NET Core

API affectées

FieldInfo.SetValue lève une exception pour les champs statiques et init uniquement

À compter de .NET Core 3.0, une exception est levée lorsque vous tentez de définir une valeur sur un champ statique InitOnly en appelant System.Reflection.FieldInfo.SetValue.

Description de la modification

Dans .NET Framework et les versions de .NET Core antérieures à la version 3.0, vous pouvez définir la valeur d’un champ statique qui est constante après son initialisation (en lecture seule en C#) en appelant System.Reflection.FieldInfo.SetValue. Cependant, le fait de définir un tel champ de cette manière a entraîné un comportement imprévisible basé sur la version cible de .Net Framework et les paramètres d’optimisation.

Dans .NET Core 3.0 et versions ultérieures, lorsque vous appelez SetValue sur un champ InitOnly statique, une exception System.FieldAccessException est levée.

Conseil

Un champ InitOnly est un champ qui ne peut être défini qu’au moment où il est déclaré ou dans le constructeur pour la classe conteneur. En d’autres termes, il est constant après son initialisation.

Version introduite

3.0

Initialisez des champs InitOnly statiques dans un constructeur statique. Cela s’applique aux types dynamiques et non dynamiques.

Vous pouvez également supprimer l’attribut FieldAttributes.InitOnly du champ, puis appeler FieldInfo.SetValue.

Category

Bibliothèques .NET Core

API affectées

.NET Core 2.1

Les API de chemin d’accès ne lèvent pas d’exception pour les caractères non valides

Les API qui impliquent des chemins d’accès ne valident plus les caractères de chemin d’accès ou lèvent une exception ArgumentException si un caractère non valide est trouvé.

Description de la modification

Dans .NET Framework et .NET Core 1.0 à 2.0, les méthodes répertoriées dans la section API affectées lèvent une exception ArgumentException si l’argument de chemin contient un caractère de chemin d’accès non valide. À compter de .NET Core 2.1, ces méthodes ne vérifient plus les caractères de chemin d’accès non valides ou elles lèvent une exception si un caractère non valide est trouvé.

Raison du changement

La validation agressive des caractères de chemin bloque certains scénarios multiplateformes. Cette modification a été introduite afin que .NET n’essaie pas de répliquer ni de prédire le résultat des appels d’API du système d’exploitation. Pour plus d’informations, consultez le billet de blog Aperçu de System.IO dans .NET Core 2.1.

Version introduite

.NET Core 2.1

Si votre code était basé sur ces API pour vérifier s'il existe des caractères non valides, vous pouvez ajouter un appel à Path.GetInvalidPathChars.

API affectées

Voir aussi

Champs privés ajoutés aux types de struct intégrés

Des champs privés ont été ajoutés à certains types de struct dans les assemblys de référence. Par conséquent, en C#, ces types de struct doivent toujours être instanciés à l’aide de l’opérateur new ou le littéral par défaut.

Description de la modification

Dans .NET Core 2.0 et versions précédentes, certains types de struct, par exemple, ConsoleKeyInfo, pouvaient être instanciés sans l’opérateur new ni le littéral par défaut en C#. Cela était dû au fait que les assemblys de référence utilisés par le compilateur C# ne contenaient pas les champs privés des structs. Tous les champs privés pour les types de struct .NET sont ajoutés aux assemblys de référence à partir de .NET Core 2.1.

Par exemple, le code C# suivant est compilé dans .NET Core 2.0, mais pas dans .NET Core 2.1 :

ConsoleKeyInfo key;    // Struct type

if (key.ToString() == "y")
{
    Console.WriteLine("Yes!");
}

Dans .NET Core 2.1, le code précédent génère l’erreur du compilateur suivante : CS0165 – Utilisation de la variable locale non attribuée « clé »

Version introduite

2.1

Instanciez les types de struct à l’aide de l’opérateur new ou du littéral par défaut.

Par exemple :

ConsoleKeyInfo key = new ConsoleKeyInfo();    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

ConsoleKeyInfo key = default;    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

Category

Bibliothèques .NET Core

API affectées

Modification de la valeur par défaut de UseShellExecute

ProcessStartInfo.UseShellExecute a une valeur par défaut de false sur .NET Core. Sur .NET Framework, la valeur par défaut est true.

Description de la modification

Process.Start permet de lancer une application directement, par exemple avec du code comme Process.Start("mspaint.exe") qui lance l’application Paint. Cela permet également de lancer indirectement une application associée si ProcessStartInfo.UseShellExecute est défini sur true. Sur .NET Framework, la valeur par défaut de ProcessStartInfo.UseShellExecute est true, ce qui signifie que le code comme Process.Start("mytextfile.txt") lance le Bloc-notes si vous avez associé des fichiers .txt à cet éditeur. Pour empêcher indirectement le lancement d’une application sur .NET Framework, vous devez définir explicitement ProcessStartInfo.UseShellExecute sur false. Sur .NET Core, la valeur par défaut de ProcessStartInfo.UseShellExecute est false. Cela signifie que, par défaut, les applications associées ne sont pas lancées quand vous appelez Process.Start.

Les propriétés suivantes sur System.Diagnostics.ProcessStartInfo sont fonctionnelles uniquement quand ProcessStartInfo.UseShellExecute est défini sur true :

Cette modification a été introduite dans .NET Core pour des raisons de performances. En règle générale, Process.Start est utilisé pour lancer une application directement. Le lancement d’une application directement n’a pas besoin d’impliquer l’interpréteur de commandes Windows ni d’entraîner le coût de performances associé. Pour accélérer ce cas par défaut, .NET Core modifie la valeur par défaut en remplaçant ProcessStartInfo.UseShellExecute par false. Vous pouvez choisir le chemin plus lent si nécessaire.

Version introduite

2.1

Notes

Dans les versions antérieures de .NET Core, UseShellExecute n’était pas implémenté pour Windows.

Si votre application s’appuie sur l’ancien comportement, appelez Process.Start(ProcessStartInfo) avec UseShellExecute défini sur true sur l’objet ProcessStartInfo.

Category

Bibliothèques .NET Core

API affectées

Versions OpenSSL sur macOS

Les runtimes .NET Core 3.0 et versions ultérieures sur macOS préfèrent désormais les versions OpenSSL 1.1.x aux versions OpenSSL 1.0.x pour les types AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSsl, RSAOpenSsl et SafeEvpPKeyHandle.

Le runtime .NET Core 2.1 prend désormais en charge les versions OpenSSL 1.1.x mais préfère toujours les versions OpenSSL 1.0.x.

Description de la modification

Auparavant, le runtime .NET Core utilisait les versions OpenSSL 1.0.x sur macOS pour les types qui interagissent avec OpenSSL. La version OpenSSL 1.0.x la plus récente, OpenSSL 1.0.2, n’est plus prise en charge. Pour conserver les types qui utilisent OpenSSL sur les versions prises en charge d’OpenSSL, les runtimes .NET Core 3.0 et versions ultérieures utilisent désormais des versions plus récentes d’OpenSSL sur macOS.

En raison de ce changement, le comportement des runtimes .NET Core sur macOS est le suivant :

  • Les runtimes .NET Core 3.0 et versions ultérieures utilisent OpenSSL 1.1.x le cas échéant. Ils repassent à OpenSSL 1.0.x uniquement si aucune version 1.1.x n’est disponible.

    Pour les appelants qui utilisent les types d’interopérabilité OpenSSL avec des P/Invokes personnalisés, suivez les instructions contenues dans les remarques SafeEvpPKeyHandle.OpenSslVersion. Votre application peut se bloquer si vous ne vérifiez pas la valeur OpenSslVersion.

  • Le runtime .NET Core 2.1 utilise OpenSSL 1.0.x le cas échéant. Il repasse à OpenSSL 1.1.x si aucune version 1.0.x n’est disponible.

    Le runtime 2.1 préfère la version antérieure d’OpenSSL, car la propriété SafeEvpPKeyHandle.OpenSslVersion n’existe pas dans .NET Core 2.1. La version OpenSSL ne peut donc pas être déterminée de manière fiable au moment de l’exécution.

Version introduite

  • .NET Core 2.1.16
  • .NET Core 3.0.3
  • .NET Core 3.1.2

Category

Bibliothèques .NET Core

API affectées

.NET Core 1.0

UnauthorizedAccessException levé par FileSystemInfo.Attributes

Dans .NET Core, une exception UnauthorizedAccessException est levée quand l’appelant tente de définir une valeur d’attribut de fichier sans disposer de l’autorisation d’accès en écriture.

Description de la modification

Dans .NET Framework, une exception ArgumentException est levée quand l’appelant tente de définir une valeur d’attribut de fichier dans FileSystemInfo.Attributes sans disposer de l’autorisation d’accès en écriture. Dans .NET Core, une exception UnauthorizedAccessException est levée à la place. (Dans .NET Core, une exception ArgumentException est toujours levée si l’appelant tente de définir un attribut de fichier non valide.)

Version introduite

1.0

Modifiez toutes les instructions catch pour intercepter une exception UnauthorizedAccessException au lieu de, ou en plus de ArgumentException, si nécessaire.

Category

Bibliothèques .NET Core

API affectées

La gestion des exceptions état altéré n’est pas prise en charge

La gestion des exceptions d’état de processus altéré dans .NET Core n’est pas prise en charge.

Description de la modification

Auparavant, les exceptions d’état de processus altéré pouvaient être interceptées et gérées par des gestionnaires d’exceptions de code managé, par exemple à l’aide d’une instruction try-catch en C#.

À compter de .NET Core 1.0, les exceptions d’état de processus altéré ne peuvent pas être gérées par du code managé. Le Common Language Runtime ne fournit pas d’exceptions d’état de processus altéré au code managé.

Version introduite

1.0

Évitez d’avoir à gérer les exceptions d’état de processus altéré en traitant plutôt les situations qui les entraînent. S’il est absolument nécessaire de gérer les exceptions d’état de processus altéré, écrivez le gestionnaire d’exceptions en code C ou C++.

Category

Bibliothèques .NET Core

API affectées

Les propriétés UriBuilder ne précèdent plus les caractères de début

UriBuilder.Fragment ne précède plus un caractère de début # et UriBuilder.Query ne précède plus un caractère de début ? le cas échéant.

Description de la modification

Dans .NET Framework, les propriétés UriBuilder.Fragment et UriBuilder.Query ajoutent toujours un # caractère ou ? respectivement à la valeur stockée. Ce comportement peut entraîner des caractères # ou ? multiples dans la valeur stockée si la chaîne contient déjà l’un de ces caractères de début. Par exemple, la valeur de UriBuilder.Fragment peut devenir ##main.

À compter de .NET Core 1.0, ces propriétés n’ajoutent plus les caractères # ni ? à la valeur stockée si celle-ci est déjà présente au début de la chaîne.

Version introduite

1.0

Il n’est plus nécessaire de supprimer explicitement l’un de ces caractères de début quand vous définissez les valeurs de propriété. Cela s’avère particulièrement utile quand vous ajoutez des valeurs, car il n’est plus nécessaire de supprimer le caractère de début # ni ? à chaque fois.

Par exemple, l’extrait de code suivant montre la différence de comportement entre .NET Framework et .NET Core.

var builder = new UriBuilder();
builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);
  • Dans .NET Framework, la sortie est ????one=1&two=2&three=3&four=4.
  • Dans .NET Core, la sortie est ?one=1&two=2&three=3&four=4.

Category

Bibliothèques .NET Core

API affectées

Process.StartInfo lève une exception InvalidOperationException pour des processus que vous n’avez pas démarrés

La lecture de la propriété Process.StartInfo pour les processus que votre code n’a pas démarrés lève une exception InvalidOperationException.

Description de la modification

Dans .NET Framework, l’accès à la propriété Process.StartInfo pour les processus que votre code n’a pas démarrés retourne un objet factice ProcessStartInfo. L’objet factice contient des valeurs par défaut pour toutes ses propriétés sauf EnvironmentVariables.

À compter de .NET Core 1.0, si vous lisez la propriété Process.StartInfo d’un processus que vous n’avez pas démarré (c’est-à-dire en appelant Process.Start), une exception InvalidOperationException est levée.

Version introduite

1.0

N’accédez pas à la propriété Process.StartInfo pour les processus que votre code n’a pas démarrés. Par exemple, ne lisez pas cette propriété pour les processus retournés par Process.GetProcesses.

Category

Bibliothèques .NET Core

API affectées