[C#/VS2010] Externe files gebruiken

[Kryziek]

Hallo,

ik heb een applicatie die een .ini file gebruikt om wat gegevens uit te lezen.
Om deze uit te lezen heb ik hard in de code staan waar deze zich bevindt.

C#:

IniFile ini = new IniFile(@"bin\config.ini");

Om deze app te debuggen moet er bij de .exe een mapje staan 'bin' met daarin het ini gestand. Dit is natuurlijk niet zoals het zou moeten.
Bij het installeren moet ik dus ook een mapje aanmaken in program files 'bin' met daarin de ini. Dat is opzich geen probleem maar met het debuggen is dat niet handig. Ik dacht bij mijzelf, dat moet anders kunnen, en dat kan het ook.
Op google vond ik een manier om een file aan je project toe te voegen in de solution explorer en dan zijn property 'Build Action' op 'Embedded Resource' te zetten. Het voordeel is dat het nu niet uitmaakt waar de file zich bevind en dus mijn probleem oplost.
Het ophalen van de gegevens doe ik nu dus zo:

C#:

Assembly assembly = this.GetType().Assembly;
            notifyIcon1.Icon = new Icon(assembly.GetManifestResourceStream(assembly.GetName().Name + ".phone.ico"));

Hier wordt dus een icoontje veranderd naar een icoon die ik heb toegevoegd als 'Embedded Resourse'.

Alleen bij het builden van de app zet hij de ini file dus IN de exe waardoor hij niet meer te bewerken is buiten VS.


Ik wil dus dat de ini na de installatie nog gewoon toegankelijk is en ik dus in de code geen harde paden hoef te geven.
Volgen jullie het nog?

Weten jullie een manier hoe ik dit het beste kan bereiken of kan verbeteren?

Mvg.

[kenneth]

Waarom gebruik je geen Settings.settings file? Dan staan de instellingen in je app.config en zijn ze achteraf aan te passen.

[Cloud]

Nou Embedded Resource is in elk geval voor .ini bestanden niet praktisch nee, dat is het alleen voor resources die nooit veranderen (in elk geval niet buiten een applicatie update om).

Een .ini file zou ik sowieso niet in Program Files plaatsen, omdat je er niet vanuit moet gaan dat je applicatie de rechten heeft om daar te mogen schrijven. Voor .ini files zou ik gaan kijken naar locaties als (Local)AppData. Dat zijn mappen binnen de huidige gebruiker (dus instellingen voor die gebruiker alleen) die wel schrijfbaar zijn.

Hangt er natuurlijk wel wat vanaf wat jij in die .ini stopt. Zoals kenneth ook zegt, zijn app.settings files in de praktijk voor .NET applicaties een heel stuk handiger met per-application en per-user settings. Dat zou veruit mijn voorkeur hebben boven .ini files.

[Kryziek]

Ik wist niet dat een settings file buiten VS aan te passen was. Moet ik nog maar eens beter naar kijken.

Maar hoe moet ik het dan aanpakken met een XML file waar ik data uit haal? Die wil ik niet als Embedded resource omdat het in geval van nood aan te passen moet zijn zonder mijn applicatie.
Met de installatie kan ik de XML wel in AppData stoppen maar dan moet ik in mijn code ook het pad opgeven naar de lokale AppData map. Om dan mijn applicatie te debuggen moet ik dus op mijn ontwikkelmachine ook de XML in de AppData map hebben staan. Dat probeer ik dus te ontwijken.

[Cloud]

Settings files zijn gewoon xml files met een vast opgestelde indeling. Ze zijn ideaal voor dit soort dingen en omdat ze 'gecompileerd' worden krijg je ook een strong typed referentie naar de elementen uit je settings file, bijvoorbeeld: Properties.Settings.Default.myBoolean.

Ik zou al je data bestanden gewoon naar AppData verplaatsen. Eventueel zou je voor het debuggen het pad van de XML aangepast kunnen houden, door middel van preprocessor directives. Een #if DEBUG en #endif eromheen en je kunt tijdens het debuggen een ander pad gebruiken. Dit betekent wel dat je applicaties in release-mode gecompileerd moeten worden als ze richting eindgebruiker gaan; maar dat is als het goed is al zo

Wat ook kan, maar dit hangt van jouw xml af en hoe je het gebruikt, is een standaard versie van de xml als embedded resource toevoegen. Bij aanspreken van jouw xml in de AppData map controleer je of deze bestaat, zo niet, dan kopieer je de versie uit je embedded resource naar AppData en gebruik je daarna alsnog de versie uit AppData.

Maar alles is beter dan er vanuit gaan dat \Program Files\Applicatie schrijfbaar is

[ Voor 16% gewijzigd door Cloud op 21-11-2012 09:48 ]

[Kryziek]

Bedankt voor de tips!
Bij het AppData verhaal loop ik een beetje tegen een probleempje aan. De map zit bij windows XP en Windows 7 op een andere plaats. Ik moet bij de installatie aangeven waar hij de config neerzet en kan het dus niet zeker weten. Bij de installer kun je wel de Users Application Data Folder instellen. Maar bij het uitlezen geeft hij op XP en 7 dus een ander resultaat. Uitlezen doe ik met:

code:

string appdata = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData).ToString();
                string path = appdata + @"\Batch Manager\config.ini";
                MessageBox.Show(path);
                ini = new IniFile(path);

Op XP is het: User\Local Settings\Application Data\
Op 7: User\AppData\
Dus bij de installer moet ik de map geven waar hij in moet, maar die is verschillend.

Mij lijkt het op dit moment gewoon makkelijker om hem toch in Program Files te zetten omdat het pad altijd hetzelfde is.

Mijn applicatie gaat op een server draaien op een administrator account. Dus hij heeft geen restricties qua rechten.

[Hydra]

Je installer kan toch gewoon ook die setting uitvragen? Dat is gewoon %appdata%. En anders (dus als je een volledig antieke installer hebt die dat niet kan) maak je een extra executable die die config voor je aan kan maken.

[Cloud]

Zoals Hydra al zegt, zou de installer dat voor je op moeten kunnen lossen. Dat moet gewoon kunnen werken Daarvoor is die Environment.SpecialFolder nu juist zo handig; dan hoef je je zelf niet druk te maken over het echte pad wat daar achter ligt.

[Kryziek]

Waar moet ik dat dan opgeven?
Ik maak nu een map aan in AppData op deze manier:

Als ik over appdata installaties zoek op google kon ik altijd op deze manier uit.

[Cloud]

Het zou kunnen dat die Target map naar Environment.SpecialFolders.ApplicationData wijst in plaats van Environment.SpecialFolders.LocalApplicationData. Wellicht dat daar het verschil vandaan komt? Ik zou de eerstgenoemde eens proberen

Zie ook: http://stackoverflow.com/...lders-point-to-in-windows

[Ellos]

T is alleen zo jammer dat xml zo lelijk en onbruikbaar is voor simpele key=value lijstjes.

[Cloud]

Dat hangt af van hoeveel handmatige wijzigingen je in zo'n bestand verwacht. Ja .ini's zijn eenvoudiger met de hand te wijzigen dan settings .xml bestanden. Maar hoe belangrijk is dat nog in een tijd dat we eigenlijk nooit meer .ini's met de hand hoeven te wijzigen? Wijzigingen zouden eigenlijk door de applicatie gedaan moeten worden.

[ Voor 13% gewijzigd door Cloud op 21-11-2012 16:45 ]

[Verwijderd]

Ellos schreef op woensdag 21 november 2012 @ 16:34:
T is alleen zo jammer dat xml zo lelijk en onbruikbaar is voor simpele key=value lijstjes.

Ja, want de settings editor is toch zo niet geoptimaliseerd voor key-value pairs

[Kryziek]

Mijn ini hoeft niet persee met de hand aanpasbaar te wezen, deze neem ik nu even als voorbeeld.
Mijn XML moet dat wel wezen.
Alleen krijg ik het nog niet voor elkaar om hem meteen in AppData te zetten. In windows 7 gaat hij alsnog in AppData\Roaming

EDIT:
Goh, wat dom van me.. De installatie zet hem inderdaad wel in een andere map maar Environment.SpecialFolders.LocalApplicationData leest hem gewoon uit, OS onafhankelijk...

[ Voor 26% gewijzigd door Kryziek op 21-11-2012 16:54 ]

[YakuzA]

Ellos schreef op woensdag 21 november 2012 @ 16:34:
T is alleen zo jammer dat xml zo lelijk en onbruikbaar is voor simpele key=value lijstjes.

mwah valt wel mee toch?

XML:

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="Path" value="lalala/daarzo"/>
    <add key="LlamaMag" value="false"/>
    <add key="DB" value="x.SDF"/>
  </appSettings>
</configuration>

[Hydra]

Ellos schreef op woensdag 21 november 2012 @ 16:34:
T is alleen zo jammer dat xml zo lelijk en onbruikbaar is voor simpele key=value lijstjes.

code:

<keys>
<key id="hostname">localhost</key>
<key id="port">1521</key>
</keys>

Nou, verschrikkelijk.

Kryziek schreef op woensdag 21 november 2012 @ 16:24:
Waar moet ik dat dan opgeven?

Geen idee. Gewoon eerst zelf eens proberen uit te zoeken hoe dat werkt. Met google. Zoals iedere dev dat doet?

[ Voor 28% gewijzigd door Hydra op 21-11-2012 17:59 ]

[Ellos]

ten opzichte van

code:

hostname=localhost
port=1521

wel ja

Mensen die even wat moeten veranderen aan instellingen in een bestand hebben het altijd een stuk gemakkelijker met een ini dan met xml, het is te verbose.

Extreme Metadata Language is dan ook een betere uitleg van de afkorting xml

Zoals jullie al merken heb ik iets tegen xml

T is prima zolang je het echt nooit hoeft te zien en het heeft ook veel voordelen, maar kan het zo zijn dat je gebruiker er eens wat in moet aanpassen, doe dan alsjeblieft json of ini

[ Voor 3% gewijzigd door Ellos op 21-11-2012 18:44 ]

[Verwijderd]

Wat is er mis met een config.ini opnemen in je project. Build action instellen op 'Copy to output folder'. en dan uitlezen met:

IniFile ini = new IniFile(@"config.ini");

of

IniFile ini = new IniFile(Path.Combine(AppDomain.CurrentDomain.BasePath, "config.ini"));

Ik zie het probleem niet zo?

overigens, zou ik voor simpele key/value settings gewoon ConfigurationManager.AppSettings gebruiken.

[ Voor 33% gewijzigd door Verwijderd op 24-11-2012 19:34 ]

[Hydra]

Ellos schreef op woensdag 21 november 2012 @ 18:43:
Zoals jullie al merken heb ik iets tegen xml

Dat is wel duidelijk ja. Maar in een topic als dit is het de bedoeling dat je het objectief houdt en niet een of andere rare 'haat' tegen XML mee laat wegen.

Ik ben ook een fan van JSON maar het boeit bijzonder weinig of een admin een XML of een JSON file aan moet passen.