Share via

Changements cassants dans .NET Core 2.1

  • Article

Si vous effectuez une migration vers la version 2.1 de .NET Core, les changements cassants répertoriés dans cet article peuvent affecter votre application.

Bibliothèques .NET Core

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

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

MSBuild

Outils de projet désormais inclus dans le kit SDK

Le kit SDK .NET Core 2.1 inclut désormais des outils CLI courants, et vous n’avez plus besoin de référencer ces outils à partir du projet.

Description de la modification

Dans .NET Core 2.0, les projets référencent des outils .NET externes avec le paramètre de projet <DotNetCliToolReference>. Dans .NET Core 2.1, certains de ces outils sont inclus dans le kit SDK .NET Core et le paramètre n’est plus nécessaire. Si vous incluez des références à ces outils dans votre projet, vous recevez une erreur de ce type : L’outil « Microsoft.EntityFrameworkCore.Tools.DotNet » est désormais inclus dans le kit SDK .NET Core.

Outils désormais inclus dans le kit SDK .NET Core 2.1 :

Valeur <DotNetCliToolReference> Outil
Microsoft.DotNet.Watcher.Tools dotnet-watch
Microsoft.Extensions.SecretManager.Tools dotnet-user-secrets
Microsoft.Extensions.Caching.SqlConfig.Tools dotnet-sql-cache
Microsoft.EntityFrameworkCore.Tools.DotNet dotnet-ef

Version introduite

SDK .NET Core 2.1.300

Supprimez le paramètre <DotNetCliToolReference> dans votre projet.

Category

MSBuild

API affectées

N/A

Voir aussi