24. juni 2010 - 14:01Der er
13 kommentarer og 1 løsning
Undgå at overskrive settings i xml fil ved hvert publish?
Hej Eksperter!
Jeg har lavet et lille program som holder styr på noget mssql database osv osv, og alt det virker fint.
Så har jeg lavet en fil ved navn settings.xml der ved 'publish' af mit program bliver "vedhæftet". Det virker også fint, og den sender filen med og ligger den i roden hvor programmet ligger.
Men problemer er så at jeg giver brugeren mulighed for at kunne ændre i settings, men ved næste update af programmet, sender den den gamle settings fil med, og overskriver den ændrede, sådan så i værste tilfælde at absolut ingenting vil fungerer.
Nogen der har et godt råd til hvordan jeg undgår at overskrive settings filen ved hvert publish? Hvordan gør man normalt med programmer?
i solution explorer -> højreklik på filen "settings.xml" -> properties -> "copy to output directory -> Den kan sættes til 3 forskellige (Do not copy), (copy always), (copy if newer).
Her vil "copy if newer" eller "do not copy" være en af dem du skal vælge.
Har allerede forsøgt at bruge disse, men syntes ikke rigtig at det har fungeret efter hensigten.
Hvis jeg vælger "Do not copy", så kommer den vel slet ikke med når man bruger publish overhovedet.
Ved "Copy Always", så vil den bare altid overskrive filen.
og ved "Copy if newer" burde den så overskrive clientens settings.xml fil hvis den er ældre en den nye "published" version.
Men hvis jeg sætter den til "Copy if newer", syntes den bare altid at overskrive filen alligevel. Har det noget at gøre med at den tror filen altid er ældre fordi clienten har lov til at ændre indstillinger? ;)
Jeg må indrømme at jeg ALDRIG bruger settingsfiler. Jeg bruger ALTID registreringsdatabasen til at gemme settings for mine programmer i.
1. Fordi man så kan lave settings pr. brugerprofil og samtidig lave nogle settings globale for applikationen. Det gøres ved at gemme settings 2 forskellige steder i reg. databasen.
2. Fordi det bare er sådan alle andre store applikationer gør. Registreringsdatabasen er bygget til at lave disse registreringer, så hvorfor opfinde den dybe tallerken 2 gange?
Jeg er godt klart over at VS har settings funktionen, jeg kan bare ikke se idéen med at bruge den. Det er en unødvendig ting efter min mening.
Og så ved jeg godt at der vil være nogle som mener at det er noget fis det jeg skriver, fordi man jo skal gemme SQL connection strenge osv et eller andet sted.
Ja, men jeg mener bare at disse informationer skal tastes af en bruger under installationen og ikke være gemt i en settingsfil pr default.
Ved dit programs startup ... se om "user_settigns.xml" findes, hvis ikke, så kopier "settings.xml" til "user_settings.xml".
På den måde omgår du dit nuværende problem, og du kan selv holde styr på hvis du i en senere release bliver nødt til at overskrive settings filen, og så kan du jo merge de settings fra "user_setttings.xml" med over i den nye.
> Jeg må indrømme at jeg ALDRIG bruger settingsfiler. > Jeg bruger ALTID registreringsdatabasen til at gemme > settings for mine programmer i.
Det er noget fjolleri du laver så, og dybt uprofessionelt. En af fordelen ved .NET er netop at du kan undgå at skulle bruge registeringsdatabasen, og kan nemt benytte dig af konfigurations-filer, som bliver gemt i brugeren's AppData.
@heinzdmx
De forslag der er givet indtil videre er handler omkring build, ikke publish. Publish er funktionalitet til at lave en OneClick installer for Win32 Apps, eller publisere over ftp eller fil-sti til en server for web-applikationer (via. frontpage-extensions).
Med mindre du har en rigtig god grund til at bruge publish, og det lyder ikke sådan, vil jeg anbefale at du simpelthen kopiere de nødvendige filer manuelt.
#wincape Giver dig ret i det meste, pånær at publish kun er til web-applikationer. Hvad bygger du det på(kan ske at jeg har misforsået konceptet med det, men har brugt det mange steder med stor success)? Det smarte er jo netop at du kan sikre dig at brugere af dit program altid har nyeste version på en super nem måde.
regdb eller settings filer er i min verden hip som hap. Brug hvad der passer til opgaven.
Jeg ved ikke om MS er på vej til at fase den ud, men tvivler lidt, da der ville være alt for meget som skal laves om.
Men AppData eller Regdb ... dont see that real diff. AppData kan jo bruges til det hele ... hvor regdb er vel er begrænset til små settings ...
Det er vel så mange ting der dybt uprofessionelt, men Lasse giver da sine meninger om hvorfor han gør som han gør, og der kan jeg godt følge ham. At du mener regdb er noget crap fordi .NET har nemt ved at læse settings filer ... synes jeg ikke helt holder som et argument. Du kan jo også lave den modsat ... regdb er nemt at arbejde med i .NET :-)
Men argumenterne for at registeringsdatabasen er noget rod er mangefoldige. Og når .NET nu netop tilbyder et super godt API til xml-konfiguration af en applikation, og netop anbefaler at man bruger det frem for registeringsdatabasen, bør man gøre det, frem for at benytte et dårligt API til registeringdatabasen, som desuden kun ender med at give problemer med UAC in den sidste ende.
Så jeg synes altså det er uprofessionelt at anbefale et forældet API frem for "the .NET way".
>> Det smarte er jo netop at du kan sikre dig at brugere af dit >> program altid har nyeste version på en super nem måde.
Hvis du tænker på OneClick distribution så synes jeg også det er smart. Men i så fald bør man ikke have bruger-settings sammen med applikation-settings, hvilket også løser problematikken med at filen bliver overskrevet.
Følgende artikel beskriver problemstillingen med at bruger-settings bliver overskrevet ved bruge af App.config til bruger-defineret konfigurations-værdier.
@windcape Point taken, men nu har du også skrevet, med forklarende tekst netop hvorfor det er uproff at bruge regdb, som var det jeg fiskede efter ... og den forklaring kom, det kan lasse bruge til noget ... og finde ud af om han skal skifte mening :-)
Jeg har været flittig bruger af regdb, men er også selv skiftet så kan nemt følge hvad du mener.
Ja, det er OneClick (eller ClickOnce som det vist hed tidligere) jeg tænker på. Nej, det skal selvf deles op, og nu tror jeg også spørger er blevet en del klogere. Da han nok skal diff mellem app settings og user settings.
Tak for de mange svar, og den lærerige diskussion. Har nu også lært ordene "app settings" og "user settings".
Da de settings jeg har, går ud på om programmet skal sende mails rundt, og til hvilke email adresser, må det være "user settings".
buzzzz og windcape har været inde på er det "OneClick/ClickOnce" funktionen jeg bruger. Som buzzzz var inde på, er det fordi at jeg har flere brugere på mit program, og kan derfor ikke bare lige smide en ny exe fil ud til dem, da jeg ikke ved hvem der har programmet. ;)
Windcape: Tak for linket! Det har været meget brugbart, og giver en god forståelse for tingene. :)
buzzzz: Du skrev tidligere det med settings.xml til user_settings.xml, og har selv tænkt over metoden, men var ikke helt sikkert på hvordan jeg så skulle opdaterer filen når det virkelig var nødvendigt. ;)
Så alt i alt er jeg kommet frem til at jeg skal dele filerne op, og benytte .NET værktøjerne til at lave settings. Tror jeg vil forsøge at kigge på det link igen som Windscape skrev, og forsøge at blive endnu klogere. ;)
Tak for hjælpen folkens, og da jeg har fået mest hjælp af buzzzz, og windscape kunne jeg godt tænke mig et svar fra jer 2. :) (Hvis man kan dele pointene op, for kan jeg ikke helt huske om man kan)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
