InstallAware

I use the method of sample SQL Server Connection to get the information about sql server.Now I want to rewrite the file "web.config" <add>. I just want to chang the data source into what I get from the dialog.Who can help to solve this problem?

Personally, I would not embed this into your installer, and would wrap the logic to modify the web.config into an application that took parameters and carried out the rewrite. Then you can call this from your setup

neillans wrote:Personally, I would not embed this into your installer

I can't help but notice that there is an easy way to edit .ini files in IA.

What is so conceptually different with .config files? (which I've come to loathe and hate, but that is a completely different problem)

I would think that this would be right up IA's alley..?

The big problem lies with the fact there is no small, reliable XML parser that we can use to process the .config files -- everything we have investigated in R&D adds significant bloat the runtime which people always object to

It has been a few years since I tried it myself, but I seem to recall having a good experience with the NativeXML shareware component for Delphi.

Given that this problem is fairly .net centric, could you include some .net code as part of the installation package? If that is possible, you could use the standard configurationmanager assembly to get the job done.

I have only been dabbling with .net for a year, so I am still a n00b. But so far, it looks like MS are really into putting as much functionality into these .config files as possible. Personally I strongly feel their approach is a huge mistake, but many developers will follow this path, and they will need good tools that can handle .config files properly.

An example of what I consider a hairy problem: A .Net application server that uses WCF exposes a bunch of interfaces in its web.config file. It also (same file) exposes a bunch of performance related settings. If the developer adds a new interface, the installer will have to install the new config file, but ideally it should leave the performance related settings alone in case the server admin (the end user) tweaked them.

We certainly could build a .NET specific module that carried out the modifications, however, we feel that this is not a suitable fix for this. Ultimately, if someone wanted to build a .NET module to modify their own configuration files, then as you say it would be a trivial task and they would be taking the risk on their own shoulders that the end user might not have the required runtimes installed.