J'examine un projet .NET, et je suis tombé sur une utilisation assez importante de fichiers .ini pour la configuration. Je préférerais de loin utiliser des fichiers app.config à la place, mais avant que je somne et en faisons un problème avec les Devs, je me demande s'il existe des raisons valables de favoriser .inini sur l'app.config?
4 Réponses :
Personnellement, je n'ai jamais utilisé de fichiers de configuration utilisateur .ini / xml à quelque chose de plus que de charger toutes les valeurs dans un singleton ou quelque chose, puis utilisez-les d'exécution comme ceci ...
Cela étant dit que je crois fermement que vous devriez examiner le type de données et l'utilisation de données. Si les données figurent dans le contexte de l'application en termes de paramètres et de configurations, je pense que le fichier app.config est le bon endroit pour contenir ces paramètres.
Si d'autre part, les données sont préoccupées par le chargement de projets, d'images ou d'autres ressources concernées par le contenu de l'application, je crois que le .ini (utilise-t-il des fichiers .ini plus? Je pense un fichier .xml pour stocker ces informations). En bref: segmenter le contenu des données stockées en fonction du domaine et du contexte.
Eh bien, en moyenne, les fichiers .ini sont probablement plus compacts et d'une manière plus lisible pour les humains. XML est un peu une douleur à lire, et son assez verbeux.
Cependant, app.config est bien sûr le mécanisme de configuration standard .NET pris en charge dans .NET et a beaucoup de crochets et de façons de faire des choses. Si vous allez avec des fichiers .inini, vous êtes essentiellement "en train de rouler le vôtre tout le chemin". Cas classique de "réinventer la roue".
Encore une fois: y a-t-il une chance que ceci est un projet qui a commencé sa vie avant .net? Ou un port d'une application de pré -.net existante dans laquelle les fichiers .ini étaient la voie à suivre?
Il n'y a rien de mal avec les fichiers .ini, je pense - ils ne sont tout simplement pas vraiment suportés dans .NET, et vous êtes seul pour les prolonger, de les manipuler, etc. Et c'est certainement un "timper" si Vous avez besoin d'apporter de l'aide extérieure à bord - à peine aucun développeur .NET n'aura été exposé à des fichiers .ini lorsque le système de configuration .NET est assez connu et compris.
Le projet est relativement nouveau, mais les fichiers .ini semblent être un mauvais Habbit reporté par certains des développeurs des projets passés. Et oui, c'est un cas classique de réinvention des roues. :) Je ne suis pas sûr d'être d'accord avec .ini étant plus lisible par l'homme. Avec des fichiers .config, VS et l'édition IntelliSense sont une brise. Et j'aimerais que l'équipe crée un joli schéma pour prendre en charge les paramètres de configuration. Merci pour votre réponse.
OK, donc si c'est juste une mauvaise habitude, j'essaierais de changer cela :-) Essayez d'établir pourquoi app.config est supérieur - meilleur support de .NET, possibilité d'écrire des groupes de section appliqués XML-schéma, etc., etc. Sera le coup de pied dans le cul Certains devs doivent enfin abandonner la technologie de plus de 10 ans et venir à quelque chose de plus récent!
Les fichiers INI sont tout à fait acceptables dans mon livre. Le problème est getprivateProfileString () et des cousins. AppCompat a tourné cela en une seule monnaie laid d'une fonction API. Récupération d'une seule valeur INI prend environ 50 millisecondes, c'est une montagne de temps sur un PC moderne.
Mais le plus gros problème est que vous ne pouvez pas contrôler le codage du fichier INI. Windows utilisera toujours la page du code système pour interpréter les chaînes. Ce qui est correct que possible tant que votre programme ne voyage pas loin de votre bureau. Si tel est le cas, il risque de produire un gibberish lorsque vous ne restreignez pas le jeu de caractères utilisé dans votre fichier INI en ASCII.
XML n'a pas ce problème, il est bien soutenu par le .NET Framework. Que ce soit en utilisant des paramètres ou de la gestion de votre configtenez-vous vous-même.
Les fichiers INI sont préférables aux applications multi-plateformes (par exemple, Linux & Windows), où le client peut occasionnellement modifier les paramètres de configuration directement, et où vous souhaitez un nom de fichier plus convivial / -reconnizable sans effort supplémentaire.
Raymond Chen possède un article intéressant sur les différences entre INI & XML config, et pourquoi INI a été initialement obsolète en faveur du registre. Voir - blogs.msdn.com/oldnewthing/archive/2007/ 11/60 / 6523907.aspx
Merci pour le lien, c'est une lecture intéressante. Et le projet susmentionné utilise également un registre des informations sur la licence! La configuration est partout. :)
Personne n'a rien déclaré sur la persistance des paramètres lors de réinstallations / pour différents utilisateurs, etc. Il convient de signaler, le fichier app.config est lié à l'application et que si vous ne gérez spécifiquement cela lors de la réinstallation / mise à jour etc vous pouvez perdre tous vos paramètres !! Les fichiers INI / XML peuvent rester non affectés ici