SYSLIB0051 : les API de prise en charge de la sérialisation héritées sont obsolètes

  • Article

Les types d’API suivants sont obsolètes, à compter de .NET 8. Leur appel dans le code génère un avertissement SYSLIB0051 au moment de la compilation.

Pour obtenir la liste complète des API affectées, consultez API obsolètes : SYSLIB0051.

Solution de contournement

  • Si vous avez créé un type personnalisé dérivé de System.Exception, déterminez si vous avez vraiment besoin qu’il soit sérialisable. Il est probable que vous n’ayez pas besoin qu’elle soit sérialisable, car la sérialisation des exceptions est principalement destinée à prendre en charge le remoting, et la prise en charge du remoting a été supprimée dans .NET Core 1.0.

    Si votre type d’exception personnalisé est défini comme celui indiqué dans l’extrait de code suivant, supprimez simplement l’attribut [Serializable], le constructeur de sérialisation et le remplacement de la méthode GetObjectData(SerializationInfo, StreamingContext).

    [Serializable] // Remove this attribute.
public class MyException : Exception
{
    public MyException() { }
    public MyException(string message) : base(message) { }
    public MyException(string message, Exception inner) : base(message, inner) { }

    // Remove this constructor.
    protected MyException(SerializationInfo info, StreamingContext context)
        : base(info, context)
    {
        // ...
    }

    // Remove this method.
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        // ...

        base.GetObjectData(info, context);
    }
}

    Dans certains cas, vous ne pouvez pas supprimer ces API de votre type d’exception personnalisé, par exemple, si vous produisez une bibliothèque contrainte par les exigences de compatibilité des API. Dans ce cas, il est recommandé de rendre obsolètes votre propre constructeur de sérialisation et vos propres méthodes GetObjectData à l’aide du code de diagnostic SYSLIB0051, comme indiqué dans le code suivant. Étant donné que, dans l’idéal, personne en dehors de l’infrastructure de sérialisation elle-même ne devrait appeler ces API, l’obsolescence ne devrait d’impact que sur les autres types qui sous-classent votre type d’exception personnalisé. Elle ne devrait pas avoir d’impact viral sur les personnes qui attrapent, construisent ou utilisent votre type d’exception personnalisé.

    [Serializable]
public class MyException : Exception
{
    public MyException() { }
    public MyException(string message) : base(message) { }
    public MyException(string message, Exception inner) : base(message, inner) { }

    [Obsolete(DiagnosticId = "SYSLIB0051")] // Add this attribute to the serialization ctor.
    protected MyException(SerializationInfo info, StreamingContext context)
        : base(info, context)
    {
        // ...
    }

    [Obsolete(DiagnosticId = "SYSLIB0051")] // Add this attribute to GetObjectData.
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        // ...

        base.GetObjectData(info, context);
    }
}

    Si vous ciblez de manière croisée .NET Framework et .NET 8+, vous pouvez utiliser une instruction #if pour appliquer l’obsolescence de manière conditionnelle. Il s’agit de la même stratégie que celle utilisée par l’équipe .NET dans la base de code des bibliothèques .NET lors du ciblage croisé des runtimes.

    [Serializable]
public class MyException : Exception
{
    // ...

#if NET8_0_OR_GREATER
    [Obsolete(DiagnosticId = "SYSLIB0051")] // add this attribute to the serialization ctor
#endif
    protected MyException(SerializationInfo info, StreamingContext context)
        : base(info, context)
    {
        // ...
    }

#if NET8_0_OR_GREATER
    [Obsolete(DiagnosticId = "SYSLIB0051")] // add this attribute to GetObjectData
#endif
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        // ...

        base.GetObjectData(info, context);
    }
}

  • Si vous avez déclaré un type qui sous-classe un type .NET attribué avec [Serializable] et que vous recevez des avertissements SYSLIB0051, suivez les instructions pour les types d’exceptions personnalisés dans le point précédent.

Conseil

Si votre type personnalisé [Serializable] ne sous-classe pas un type .NET, vous ne verrez pas d’avertissements SYSLIB0051. Toutefois, nous vous déconseillons d’annoter votre type de cette manière, car les bibliothèques de sérialisation modernes comme System.Text.Json n’en ont pas besoin. Envisagez de supprimer l’attribut [Serializable] et l’interface ISerializable. Au lieu de cela, utilisez votre bibliothèque de sérialisation pour accéder aux objets du type par le biais de ses propriétés publiques plutôt que de ses champs privés.

Supprimer un avertissement

Si vous devez utiliser les API obsolètes, vous pouvez supprimer l’avertissement dans le code ou dans votre fichier projet.

Pour supprimer une seule violation, ajoutez des directives de préprocesseur à votre fichier source pour désactiver, puis réactiver l’avertissement.

// Disable the warning.
#pragma warning disable SYSLIB0051

// Code that uses obsolete API.
// ...

// Re-enable the warning.
#pragma warning restore SYSLIB0051

Pour supprimer tous les avertissements SYSLIB0051 dans votre projet, ajoutez une propriété <NoWarn> à votre fichier projet.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
   ...
   <NoWarn>$(NoWarn);SYSLIB0051</NoWarn>
  </PropertyGroup>
</Project>

Pour plus d’informations, consultez Supprimer des avertissements.

Voir aussi