La sérialisation d'un HashSet

Je suis en train de sérialiser un Hashset, mais je vais avoir pas de chance. Chaque fois que j'essaie d'ouvrir les données sérialisées, je reçois un vide HashSet. Cependant, une Liste fonctionne très bien. Exemple de code:

[Serializable()]
public class MyClass : ISerializable
{
    public MyClass(SerializationInfo info, StreamingContext ctxt)
    {
        HashSet<string> hashset = (HashSet<string>)info.GetValue("hashset", typeof(HashSet<string>));
        List<string> list = (List<string>)info.GetValue("list", typeof(List<string>));
        Console.WriteLine("Printing Hashset:");
        foreach (string line in hashset)
        {
            Console.WriteLine(line);
        }
        Console.WriteLine("Printing List:");
        foreach (string line in list)
        {
            Console.WriteLine(line);
        }
    }

    public void GetObjectData(SerializationInfo info, StreamingContext ctxt)
    {
        HashSet<string> hashset = new HashSet<string>();
        hashset.Add("One");
        hashset.Add("Two");
        hashset.Add("Three");
        info.AddValue("hashset", hashset);
        List<string> list = new List<string>();
        list.Add("One");
        list.Add("Two");
        list.Add("Three");
        info.AddValue("list", list);
    }
}

Et lorsqu'il est exécuté, il imprime:

Printing Hashset:
Printing List:
One
Two
Three

De sorte que la Liste fonctionne bien, mais le HashSet est de retour à vide. Un peu coincé - n'importe qui peut voir ce que je fais mal? Grâce

Pourquoi faites-vous la sérialisation vous-même? Pourquoi ne pas utiliser le DataContractSerializer ?

InformationsquelleAutor Frederik | 2010-11-16

.net c#c#-4.0 hash hashset

3

Mise à jour:

Comme Hans Passant a déclaré il y a solution de contournement simple, il suffit d'appeler HashSet.OnDeserialization manuellement.
```
var hashset = (HashSet<string>)info.GetValue("hashset", typeof(HashSet<string>));
hashset.OnDeserialization(this);
```
Il aide également avec d'autres Génériques collections.

Aussi loin que je peux voir, c'est probablement un bug dans HashSet<T> mise en œuvre. HashSet correctement sérialisé dans SerializationInfo:
```
public virtual void GetObjectData(SerializationInfo info, StreamingContext context)
{
  if (info == null)
  {
    throw new ArgumentNullException("info");
  }
  info.AddValue("Version", this.m_version);
  info.AddValue("Comparer", this.m_comparer, typeof(IEqualityComparer<T>));
  info.AddValue("Capacity", (this.m_buckets == null) ? 0 : this.m_buckets.Length);
  if (this.m_buckets != null)
  {
    T[] array = new T[this.m_count];
    this.CopyTo(array);
    info.AddValue("Elements", array, typeof(T[]));
  }
}
```
et SerializationInfo correctement restaurée. Vous pouvez vérifier par vous-même, jetez un oeil à: (((System.Collections.Generic.HashSet<string>)(info.m_data[0]))).m_siInfo.m_data[3] mais ne parvient pas à restaurer son état:

Tous, il n'est tout simplement magasins SerializationInfo:
```
protected HashSet(SerializationInfo info, StreamingContext context)
{
  this.m_siInfo = info;
}
```
Vous pouvez vérifier (hashset).m_siInfo.MemberValues[3], les valeurs ont été correcly restauré par le formateur, mais pas "interprété" par HashSet.

Problème similaire a Dictionary<TKey,TValue> ou, par exemple,LinkedList<T>.

List<T> (ou similaire réseau sur la base des collections Stack<T>) n'a pas de problème puisqu'ils sérialisé sous forme de tableau (sans logique).

Solution de contournement a été posté par Hans Passant.

À mon humble avis, BinaryFormatter n'est pas vraiment bon et efficace pour stocker des valeurs. Vous pouvez essayer d'utiliser DataContractSerializer (il peut gérer de tels types) ou aller avec la sérialisation aides telles que protobuf.net, json.net etc. Voir Pourquoi est-sérialisation binaire plus vite que la sérialisation xml? et Les Tests de performances de Serializations utilisé par la WCF Liaisons
- Veuillez sauvegarder votre avis pourquoi il n'est pas vraiment bon ou efficace.
- Probablement, ce sera un autre post. Si il a vraiment besoin je peux poster ici ou tout simplement e-mail pour vous. Juste quelques points: 1. Sérialiser pour objet de disque avec int champ, vous allez vous retrouver avec ~153 octets du fichier, car il contient tous les noms de type de. Comparer avec les 4 octets de la valeur de int lui-même. 2. Vérifier BinaryFormatter mise en œuvre ou simplement de mesurer la performance à comparer avec la plaine de la valeur binaire de l'écrivain. 3. N'oubliez pas de problèmes de compatibilité, de sorte que si vous mettez à jour l'assemblée sur le serveur, vous devez utiliser quelques astuces pour ne pas échouer avec la désérialisation des anciennes valeurs.
- Dans le cas où vous intéressant: nous penser à l'aide de BinaryFormatter que notre sérialisation backend, mais il trouve assez de ne pas optimale pendant certain nombre de tests. Notre système distribué est de 10 à 50 000 nœuds, nous avons terminé avec notre propre réalisation, en 2007, mais la réflexion sur le passage à ProtoBuffers depuis que notre solution est assez semblable.
- Merci - j'ai juste fini par appeler ToList() sur le HashSets lors de la sérialisation d'eux...
- vérifiez facile de Hans solution de contournement.
- vérifier Marc Gravel, en réponse à Pourquoi la sérialisation binaire plus vite que la sérialisation xml? bit.ly/cVmpvG
- Martyshchenko: Point 1-3 est pas pertinent. Bien que fwrite est plus rapide et plus petit, vous n'avez pas de sécurité de type (et tout un tas d'autres subtilités, comme cyclique de données, etc). Si la taille est un problème, vous pouvez simplement gzip le flux d'octets.
- dépend" comme d'habitude. gziping ajoute de la performance et de la mémoire de l'empreinte par le client. Nous avons à traiter au moins 10 000 clients par serveur. Chaque tâche supplémentaire (c'est à dire gzipping) gouttes de réactivité et d'augmenter les exigences matérielles. BinaryFormatter ajoute énormément de métadonnées avec les descriptions de champ (y compris la sauvegarde du compilateur noms de champ), types, etc. Même gzip ne peux pas beaucoup vous aider. Aussi, en raison de lourdes réflexion dépendance il vraiment lent.
- Je ne pense pas que je lâche le type de sécurité "plaine binaire écrivain". BinaryFormatter est juste pratique façon pour sérialiser/désérialiser les données à transférer. Votre propre mise en œuvre peut être autant en sécurité que vous avez besoin/envie. Après tout, il vient d'octets et de le rendre safe convention est atteint par l'utilisation de certains autres wrappers soit cadre ou de votre propre. Voir aussi Marc réponses qu'il donne quelques infos. J'ai mis à jour ma réponse avec des liens vers eux.
- Martyshchenko: Avez-vous regardé les options pour le BinaryFormatter le rendre plus petit? Comme type simple info, etc?
- la dernière fois que j'ai vérifié c'est du milieu de l'année 2007. Pouvez-vous me donner des exemple comment sérialiser champ int au moins 8-10 fichier octets? Et comment éviter la perte de performance sur de grands objets?
- Martyshchenko: Vous ne! Sérialiser un type que vous ne pouvez pas prendre l'adresse de l' (comme dangereux), et le binaire écrivain est inutile. Maintenant, vous devez concevoir votre propre conteneur et de générer un graphe d'objets, et il faut juste aussi longtemps que le BinaryFormatter. Je suis d'accord, si vous avez de style C les structures, les binaires de l'écrivain est le meilleur, mais dans le monde géré, tels standa-alone "data" est rare.
- Martyshchenko: Regardez FormatterTypeStyle, FormatterAssemblyStyle et TypeFilterLevel.
- en disant "plaine binaire écrivain" je ne veux pas dire System.IO.BinaryWriter nous venons de mettre en œuvre leurs propres sérialiseur pour les types de base (int, float, paniers int, des tableaux, des jeux, des cartes, etc.) et a généré sérialiseurs semblable, WCF attributs (DataContract, DataMember). De sorte que chaque objet peut être sérialisé par nos sérialisation backend (juste des données), soit par courrier en écrivant propre logique de sérialisation, à l'aide de types de base ou d'objets connus. La dernière variante permet par exemple de construire et de sérialiser les données des deltas ou des types complexes qui peuvent efficacement "emballé" manuellement.
- du mieux que je reçois aujourd'hui est de 135 octets pour le champ int k au lieu de 153 octets. Mais les performances n'ont pas disparu.
- Martyshchenko: Il n'a pas à émettre les informations de type à chaque fois. Par exemple: sérialiser un int[1000] ou un couple de int champs.
- mais là où ça aide? J'ai des commandes avec des données dans mon protocole, chacune des commandes habituellement séparés les uns des autres. Ainsi, pour envoyer la commande que je dois commencer sérialiseur, encore et encore, et il va enregistrer les informations de type à chaque fois que j'ai sérialisé commande.
InformationsquelleAutor Nick Martyshchenko
2

La différence est que HashSet<> met en œuvre ISerializable, List<> ne fonctionne pas. La solution de contournement est d'appeler son OnDeserialization() la méthode explicite, bien que je ne suis pas sûr de savoir si c'est la bonne chose à faire.
```
        var hashset = (HashSet<string>)info.GetValue("hashset", typeof(HashSet<string>));
        hashset.OnDeserialization(this);
        var list = (List<string>)info.GetValue("list", typeof(List<string>));
        //etc..
```
- Merci, bon à savoir de façon facile. J'oublie que HashSet<T> ont à mettre en œuvre ISerializable.OnDeserialization() et de ne pas vérifier.
InformationsquelleAutor Hans Passant

Vous devez vous connecter pour publier un commentaire.