Alternative à la sérialisation XML pour la configuration

Question

Actuellement, nous utilisons un objet de configuration géant qui est sérialisé vers/depuis le XML. Cela a bien fonctionné la plupart du temps, mais nous constatons qu'en cas de perte de puissance et de plantage de l'application, le fichier peut être laissé dans un état qui le rend incapable de se désérialiser correctement, corrompant ainsi les informations de configuration.

J'aimerais utiliser l'app.config intégré, mais il ne semble pas prendre facilement en charge les classes personnalisées. Par exemple, avec la sérialisation XML, je peux facilement sérialiser une classe générique list<ComplexClass> sans code supplémentaire. Cela fonctionne tout simplement. Il semble que lorsque vous utilisez app.config, vous devez fournir une tonne d'informations et de classes personnalisées pour que cela fonctionne. De plus, la plupart des tutoriels de "configuration personnalisée" datent de 2007 et peuvent être dépassés pour autant que je sache. Quelqu'un a-t-il des informations sur la dernière façon de procéder dans .NET 4.0 ?

De plus, lorsqu'un problème survient dans l'application, 9/10 fois c'est à cause d'une mauvaise configuration. App.config aime stocker les paramètres modifiables par l'utilisateur dans un endroit très inaccessible pour les utilisateurs qui ne sont pas familiers avec les répertoires cachés et autres. Existe-t-il un moyen d'avoir un emplacement unique pour stocker le fichier de configuration, que l'utilisateur peut facilement nous envoyer par e-mail lorsqu'un problème survient ?

Ou bien, tout cela est-il plus facile que ce dont je me souviens au début de la version 2.0 ? Si vous avez des liens ou des exemples rapides sur la façon de créer facilement des informations personnalisées dans app.config, ce serait formidable.

Voici un autre exemple, une version simplifiée de l'un des types d'objets que je veux sérialiser en tant que List<Alarm> comme la quantité de Alarm peuvent varier ou être vides. Existe-t-il un moyen analogue de stocker quelque chose comme cela dans app.config ?

[Serializable]
public class Alarm
{
    [Serializable]
    public class AlarmSetting
    {
        public enum AlarmVariables { Concentration, RSquared }
        public enum AlarmComparisons { LessThan, GreaterThan }

        [Description("Which entity is being alarmed on.")]
        public AlarmVariables Variable { get; set; }
        [Description("Method of comparing the entity to the setpoint.")]
        public AlarmComparisons Comparator { get; set; }
        [Description("Value at which to alarm.")]
        public Double Setpoint { get; set; }
    }

    public String Name { get; set; }
    public Boolean Enabled { get; set; }
    public String Parameter { get; set; }
    public List<AlarmSetting> AlarmSettings { get; set; }
    public System.Drawing.Color RowColor { get; set; }
}

Answer 1

Je suggère d'abandonner toute sorte de fichier de configuration et d'utiliser plutôt un type de base de données locale tel que sqlite ou sql server express qui est beaucoup plus résistant aux pannes d'applications.

IMHO, les paramètres de configuration ne devraient pas être un conteneur par défaut de user paramètres. Pour moi, un fichier de configuration est là pour s'assurer que l'application fonctionne dans l'environnement donné. Par exemple, définir les chaînes de connexion ou les taux d'interrogation ou des choses de cette nature.

Les paramètres de l'utilisateur, en particulier ceux qui changent souvent, nécessitent un meilleur mécanisme de stockage, comme une base de données locale. À moins, bien sûr, qu'il ne s'agisse d'une application client/serveur. Dans ce cas, ces paramètres doivent être stockés sur le serveur lui-même et ne doivent être conservés localement que si l'application doit fonctionner dans un état déconnecté.

L'exemple que vous avez donné, celui de la configuration de ce qui semble être une ou plusieurs alarmes, est un parfait exemple de ce qui doit se trouver dans une table de base de données.

Answer 2

J'utilise la sérialisation XML, similaire à ce que vous décrivez, depuis de nombreuses années sur un certain nombre de projets différents. À moins de vouloir mordre dans le SQL pour la configuration, cela semble être la meilleure solution.

À mon avis, le mécanisme app.config n'est pas meilleur que la simple sérialisation XML. Il est en fait plus difficile d'accéder à cette configuration à partir d'un certain nombre de projets différents. Si vous ne sauvegardez que l'état transitoire (options de l'utilisateur, etc.) d'une application WinForms, les paramètres de l'application peuvent être pratiques pour les types de données simples.

Il me semble que vous avez un autre problème qui cause la corruption. J'obtiens rarement une corruption de fichier avec ces fichiers XML. Lorsque c'est le cas, c'est lié à une exception qui est levée pendant la sérialisation, et non à un crash de l'application, etc. Si vous voulez vérifier ce point, vous pouvez sérialiser le flux de mémoire, puis le vider sur le disque. Vous pouvez en fait sérialiser et désérialiser le flux pour vous assurer qu'il est valide avant de vider le fichier sur le disque.

A moins que vous n'écriviez ce fichier beaucoup Je serais sceptique quant au fait que la corruption des fichiers soit due à des coupures de courant.

Answer 3

Si vous ne parvenez pas à trouver la source de l'erreur, vous ne pouvez que supposer qu'elle a un rapport avec les fichiers Xml. Il est tout à fait possible que le XmlSerializer intégré échoue par exemple, vous avez peut-être une référence circulaire quelque part, mais il est difficile de faire des commentaires sans connaître la nature de l'erreur.

Parfois, l'utilisation du sérialiseur Xml intégré n'est pas le meilleur choix, et lorsque les objets deviennent complexes, il peut être préférable d'effectuer la sérialisation et la désérialisation vous-même. Vous aurez plus de contrôle et serez en mesure de déterminer/récupérer plus précisément les données de fichiers défectueux.

XDocument doc = new XDocument(
    new XElement("attachments",
        new XElement("directory", attachmentDirectory),
        new XElement("attachment-list",
            from attached in attachedFiles
            select new XElement("file", 
                new XAttribute("name", attached.FileName), 
                new XAttribute("size", attached.FileSize))
            )
        )
    );

En dehors de cela, les fichiers de configuration servent à la configuration, pas aux données du programme. La différence est que les données de configuration ne doivent pas changer souvent, et ne sont normalement pas directement modifiables par les utilisateurs. Dans une application winforms, vous ne partagez pas de données entre utilisateurs dans un fichier de configuration. Si c'est le cas, vous devez vous demander si votre application est vraiment une application de base de données.

Answer 4

Puisque nous avons pris la décision d'abdiquer f nous ne l'avons pas regretté une seule seconde.

Jetez un coup d'oeil à ça : http://blog.aumcode.com/2013/08/aum-configuration-as-facilitated-by-nfx.html