[C# .NET 2.0] Web.config aanpassen met data van installer

[Nappa]

Voor een website project heb ik een setup gemaakt, waarin een connection string opgegeven kan worden. Het is de bedoeling om deze weg te schrijven in de Web.config van de site na het committen van de setup.

Dit probeer ik via de 'schonere' 2.0 manier te doen, dat wil zeggen met behulp van de WebConfigurationManager klasse. Het lukt me echter niet om dit voor elkaar te krijgen.
Als ik de config file open met:

C#:

Configuration config = WebConfigurationManager.OpenWebConfiguration( null );

Dan pakt hij de 'root Web.config' file; veranderingen die ik hierin doe en wegschrijf komen terecht in de windows .NET framework config directory.
Maar wanneer ik probeer de file te openen met bijvoorbeeld:

C#:

// Open web.config
string folder = Context.Parameters[ "assemblypath" ];
// remove the 'bin\xxx.dll' part;
folder = folder.Substring( 0, folder.LastIndexOf( @"\" ) );
folder = folder.Substring( 0, folder.LastIndexOf( @"\" ) );
string webConfigPath = folder +"\\web.config";
Configuration config = WebConfigurationManager.OpenWebConfiguration( webConfigPath );

Dan krijg ik een exceptie dat "C:\inetpub\wwwroot\WebconfigtesterSetup\web.config is geen geldig virtueel pad.".
Static aanroepen via

C#:

WebConfigurationManager.ConnectionStrings.Add( new System.Configuration.ConnectionStringSettings( "webconfigTestConnectionString", connectionString ) );

Levert me de exceptie op 'De configuratie is alleen-lezen.'.

Hoe kan ik er voor zorgen dat hij het wel doet? Of zie ik iets over het hoofd en is dit gewoon niet mogelijk?
Noot: het gaat me voornamelijk om het achterhalen van de fout; ik heb namelijk ondertussen wel een oplossing gemaakt op de oude manier, namelijk de Web.config openen als XmlDocument, en wijzigingen hierin maken en opslaan; maar volgens mij was de ConfigurationManager juist geïntroduceerd om handmatig gepruts met XML te voorkomen .

[Verwijderd]

dit staat echt exact beschreven in het boek 70-528 waarin ik gisteren heb zitten lezen, standaard heb
je daar geen schrijfrechten op en die moet je aanzetten (even uit mijn hoofd)

edit:
http://msdn.microsoft.com/en-us/library/ms151456.aspx


Remarks

To obtain the Configuration object for a resource, your code must have read privileges on all the configuration files from which it inherits settings. To update a configuration file, your code must additionally have write privileges for both the configuration file and the directory in which it exists.

[ Voor 51% gewijzigd door Verwijderd op 03-07-2008 15:20 ]

[Niemand_Anders]

Wij gebruiken gewoon ConfigurationManager.OpenExeConfiguration welke een path naar je .config bestand vraagt. Het maakt daarbij niet uit of dit een app.config of een web.config bestand is.

De WebConfigurationManager benaderd de web.config via IIS en heb je volgens mij extra rechten nodig. Voor een setup programma is de (System.Configuration.)ConfigurationManager gemakkelijker.

[Nappa]

Maar mijn gebruikersaccount (windows XP btw) behoort tot de groep 'Administrators' die beschreven wordt als hebbende 'volledige en onbeperkte toegang'. Of wordt een Install standaard met een beperkter aantal rechten uitgevoerd? Ik ben nog niet echt 'into' de hele .NET security. Aangezien ik de file wel kan openen en schrijven (als xml document welteverstaan) lijkt me dat ik op het file system wel de rechten heb. Is het dan de bedoeling dat ik dat stukje code in een of andere 'Role' uitvoer?

/edit: ik zal het ook eens met de OpenExeConfiguration proberen

Maar mijn gebruikersaccount (windows XP btw) behoort tot de groep 'Administrators' die beschreven wordt als hebbende 'volledige en onbeperkte toegang'. Of wordt een Install standaard met een beperkter aantal rechten uitgevoerd? Ik ben nog niet echt 'into' de hele .NET security. Aangezien ik de file wel kan openen en schrijven (als xml document welteverstaan) lijkt me dat ik op het file system wel de rechten heb. Is het dan de bedoeling dat ik dat stukje code in een of andere 'Role' uitvoer?

/edit: ik zal het ook eens met de OpenExeConfiguration proberen

/edit2: Als ik dit doe:

C#:

Configuration config = ConfigurationManager.OpenExeConfiguration( webConfigPath );
ConnectionStringsSection css = config.ConnectionStrings;
css.ConnectionStrings.Clear();
css.ConnectionStrings.Add( new ConnectionStringSettings( "webconfigTestConnectionString", connectionString ) );
config.Save( ConfigurationSaveMode.Modified );

Maakt hij bij het aanroepen van Save een nieuwe file aan in plaats van de bestaande te gebruiken. Hij slaat nu een bestand 'Web.config.config' op waarin de wijzigingen staan . (Voor de volledigheid: webConfigPath bevat bij aanroep de string "c:\Inetpub\wwwroot\WebconfigtesterSetup\").

[ Voor 58% gewijzigd door Nappa op 03-07-2008 16:40 ]

[Verwijderd]

Leuk he? Ik heb na een tijdje de moed maar opgegeven en de connection string maar gewoon in de application settings opgeslagen.

[Haan]

Bij mij gaat het wel goed hoor

Ik geef het relatieve pad aan, dit staat wel hard gecodeerd, maar dat kan, omdat mijn setup geen mogelijkheid geeft om dit te wijzigen.
Dus

C#:

Configuration config = WebConfigurationManager.OpenWebConfiguration("/testWebconfig");
//etc

[Niemand_Anders]

Nappa schreef op donderdag 03 juli 2008 @ 15:37:

C#:

Configuration config = ConfigurationManager.OpenExeConfiguration( webConfigPath );
ConnectionStringsSection css = config.ConnectionStrings;
css.ConnectionStrings.Clear();
css.ConnectionStrings.Add( new ConnectionStringSettings( "webconfigTestConnectionString", connectionString ) );
config.Save( ConfigurationSaveMode.Modified );

Maakt hij bij het aanroepen van Save een nieuwe file aan in plaats van de bestaande te gebruiken. Hij slaat nu een bestand 'Web.config.config' op waarin de wijzigingen staan . (Voor de volledigheid: webConfigPath bevat bij aanroep de string "c:\Inetpub\wwwroot\WebconfigtesterSetup\").

Bij onze installaties staat de web.config nog niet op z'n uiteindelijke plaats. Wij gebruiken de SaveAs methode welke niet als bij het openen een path accepteert.

Bij onze installaties kan de WebConfigurationManager niet worden gebruikt omdat de website nog niet in IIS is toegevoegd, dit is een security maatregel welke voorkomt dat een website al beschikbaar is op onder andere productie servers voordat alle rechten (automatisch) zijn goed gezet.

[mulder]

Zelf doen is leuk, besteed je je tijd liever anders, dan moet je eens kijken naar WiX... hoewel je dat eerst ook wel wat tijd gaat kosten

[Niemand_Anders]

Onze installaties zijn helaas tegenwoordig iets te complex voor goed gebruik van WiX. Vroeger gebruikte wij het wel. Overigens werkt onze installer ook via Mono op Linux en Mac. Na een inventarisatie bleek dat het schrijven van de custom acties voor WiX meer tijd zou kosten dan zal een installer schrijven.

TS zou eventueel ook voor een (Php)MysqlAdmin oplossing kunnen gaan. De website genereert een bestand welke je download en daarna zelf in de juiste directory zet. Maar dat is geen antwoord op zijn vraag.